There are many different ways to manage something and the methodologies of PRINCE2®, Agile, SCRUM and ITIL® help. In this post our expert John A G Smith explains how a system or 2 can keep our world spinning on the correct axis!
It’s all about systems. Whether you’re looking at something as small as an individual business task or as large as a whole company, they’re all systems. We’re surrounded by the things. We live on a planet within the solar system. Our shower is supplied by a hot water system. I’m writing this on a computer system. Indeed we are each our own individual system: the human body.
So what, I hear you say, is a system? And what qualifies each mentioned above as one of them?
It is generally accepted that a system has five components: Inputs, outputs, processes, stores and a boundary.
Inputs, outputs, processes, stores and a boundary.
An input is the ‘raw material’ of the system. It’s data to an information system, fuel to a heating system or food and air for a human body. It comes from outside the system: the environment.
An output is what is required from the system: information, heat or, in the case of people, work.
Processes are the transformations that change the inputs into the required outputs: calculating, sorting and validating data, burning fuel to heat water, converting food and oxygen into energy.
Every system needs stores, otherwise the invoicing department would need to contact the tax authorities to find the VAT rate for every single invoice produced. The human would need to eat constantly in just the right quantities to produce the energy needed for the task in hand … no more and no less.
Then there’s the boundary. On physical systems, such as the heating systems or the human body, there is a physical boundary. But with business systems there is a problem. Let’s look at, for example, a stock control system (SCS).
Would we want our SCS to know how much stock we have in hand? – it’s reasonable to assume we would.
Would we want our SCS to warn us when stock levels are low? – again, it’s reasonable to assume we would.
Would we want our SCS to reorder stock that is low? – highly likely.
Ensure that stock delivered matches stock ordered? Certainly.
Check that the invoice for delivered stock is for the stock delivered? Absolutely.
… and pays the invoice? No? Why not?
There are obvious security and antifraud reasons why a company would want to separate the department that orders materials from the one that pays for it. But logically there is no system reason for the separation and the reason why Ordering and Paying are placed under different heads is a purely business decision. So the boundary of a business system may well be said to be purely arbitrary: a senior manager has decided that one thing is in whereas something else is out.
But that leads to another problem. If the boundary is defined, effectively on the whim of the manager, then another whim can just as easily move it.
The ‘Topsy’ project
Most people involved in systems development have encountered the ‘Topsy’ project: the one that grows … and grows … and grows. Because if the boundary of the system is decided by people, then they can move that boundary to include further requirements. But it is very rare that anybody ever asks to remove functionality … i.e. move the boundary ‘in’.
Project Managers are governed by ‘the triple constraint’, to deliver the requirements, on time and within budget. Figures indicate that of all large projects, 45% go over budget and 7% go over time. Yet, if the boundary is fluid and there is no control on additional functionality, the reason for these failings becomes obvious.
 McKinsey & Company in conjunction with the University of Oxford
What can be done?
There are actually three mechanisms that will help.
Firstly, good requirements analysis. The business analyst must do more than just list what the business users say they want. They must understand the business objectives, determine the underlying causes of problems and suggest solutions that match one with the other. Analysts must be trained in the use of the tools, techniques and diagramming conventions of their trade.
Secondly, there must be a company specific acceptance mechanism. Once the analyst has created the proposed solution this must be agreed by the business. This is far from easy as business staff will not necessarily understand the very diagrams proposed previously so there needs to be a communication tool that works for both the technical and the business staff. There are two major mechanisms to overcome this. One is the Structured Walkthrough, which involves a set of techniques and roles to ensure user understanding and buy in. An alternative, and somewhat more controversial, approach is full time user participation in projects. This is becoming more common with the use of Agile Methods but many organisations resist this because it means losing the services of, sometimes vital, members of business staff.
Thirdly, a rigorous change control process will ensure that any proposed change is justified, fully costed, assessed for impact and aligned with the business case.
These last two can be partially resolved by the use of a good project management method such as PRINCE2® but advice on the constitution and running of a Change Advisory Board is better found in ITIL®.
Too often we hear advocates of one ‘methodology’ or another suggesting that theirs is the universal panacea. They will say that project managers need PRINCE2®, analysts need SCRUM for example, IT service managers need ITIL®. But, in truth, we see that these all interact and each provides one facet of the knowledge or techniques needed to ensure a successful outcome because, there was one more statistic in the survey: 17% of business critical projects go so badly wrong that they threaten the very existence of the company.
If that’s your project it’s certainly going to play havoc with your next pay rise.
Have you had a problem with the boundary of a project? Let us know about it.