In my last article “Building Systems is Difficult” I discussed the “3 Evils” of Systems Engineering, namely:
- Complexity,
- A lack of understanding, and
- Poor Communication.
There were lots of great comments on this, but one which stood out for me as something which required further discussion was this from James McHugh who added (as an additional evil and potential solution):
Scope creep. Have sign-offs at every stage.
What is Scope Creep?
The SEBoK (Systems Engineering Body of Knowledge) includes the following definitions for scope:
- The behaviour that system is expected to exhibit. (ISO/IEC/IEEE 24765 2010)
- The goals, processes, resources, facilities, activities, outputs and outcomes an organization is responsible for. (Created for SEBoK)
Wikipedia includes the following in its definition of Scope Creep:
Uncontrolled changes or continuous growth in a project’s scope.
Why is it a problem?
Scope Creep, or more precisely, an uncontrolled change in scope, is undesirable because it results in an uncontrolled increase in cost, a delay in project delivery, or more often than not, both. This is because of the “Iron Triangle” which states that it’s impossible to alter any one side without also adjusting at least one of the other two.
Put simply:
If you’re building a house and half way through you decide to add some extra rooms, it will take you longer and you’ll need more bricks!
Obviously that’s an oversimplification. You would probably need to reapply for planning permission and do lots of other things too. In fact, whenever a change is requested, it usually turns out to be harder than first imagined because of the “3 Evils”.
There are other factors that come into play here such as “Quality” and “Productivity” but for now lets assume we’re working as fast as we can to an agreed acceptable standard.
Less, Less, Less!
But it’s not just requests for additional functionality that cause problems. Any proposed change in the structure or behaviour of the systems can give us a headache.
Take the example of the Mauser BK-27 cannon fitted to the Eurofighter Typhoon. Initially, in order to save costs, and because it wasn’t required for any of its mission profiles, the UK Ministry of Defence (MOD) decided the UK variant (unlike those for Germany, Italy and Spain) wasn’t going to have a cannon fitted. Less is cheaper, right? But that would have changed the aircraft’s weight distribution and required UK only changes to the avionics software. Having different software just for the UK would have been costly to create and maintain. The hunt was therefore on to find something cheeper and of the same weight to replace the cannon. Nothing suitable could be found, and so the pragmatic solution was taken that the RAF Typhoon would have the cannon installed, but that the RAF wouldn’t load it or train the pilots how to use it. Ironically the UK’s experience in Afghanistan made the MOD rethink this decision and so the cannon (which had been there all along) was promoted to a usable weapon by the RAF.
It would be easy to view this episode in hindsight as a series of poor decision, but that would be, in my opinion, an unfair and inaccurate analysis. Many of the challenges encountered were due to the “3 Evils”. The important lesson is that any change, even if it is intended to reduce overall cost as this did, has some implementation cost of its own. In this case the cost of either developing a separate software branch or finding a cheaper way to mimic the weight of the cannon. In the end, when it was decided no design changes were required, the time and effort spent investigating the proposal still resulted in an additional cost.
Why does it happen?
A flippant answer, sometimes given by battle weary engineers is:
Because the customer keeps changing their mind!
Well OK, this can happen, but for the kinds of projects where Systems Engineering is generally employed, the “Customer” is an organisation and there are very few (if any) aspects which are determined by the personal preferences of the individuals. So what are the real reasons?
External Changes
Sometimes there are Political, Economic, Social, Technological, Legal and/or Environmental (PESTLE) changes, external to the project. This is especially true in Systems Engineering projects which have long development, manufacturing (construction) and/or in-service (maintenance) phases. The world changes, and if your system isn’t going to enter service for another 5, 10, 15 or even 20 years then it’s pretty difficult (some would say impossible) to predict what the future will look like then.
Because of the “3 Evils”
At every lifecycle stage, what the Customer or the Supplier knows about the problem, solution or project spaces is shaped by the “3 Evils”. The UK MOD believed that by removing the Typhoon’s cannon (or rather not including it in the ones built for the RAF) it would reduced the aircraft’s cost. This illustrated a lack of understanding. The reason removing the cannon would potentially increase cost, or at least not provided the savings expected, was due to the complexity of the system – removing the cannon changed the weight distribution, changing the weight distribution required a change in the software. The reason the idea was able to progress so far was due to poor communication – the people who were driving the change and the people who understood the complexity were not communicating as well as hindsight suggests they might.
Does it matter when in the lifecycle the change happens?
Indeed it does. As we know, the cost of fixing defects goes up by a scale of magnitude (various figures are quoted, but the important thing to note is that it is always more expensive) the later in the development lifecycle they are identified. The same is true for implementing change. In the early stages the concept is still fluid and change can be adopted easily. As we progress into design, the system complexity becomes important and we have to asses how changes in one area of the design may have an effect on the design elsewhere. From production onwards we have to additionally consider if or how we will modify the systems, subsystems or components we have already produced.
Why are some changes more difficult to accommodate than others?
Going back to the (overly used) analogy of building a house – Imagine we’ve built the shell, done the first fix (added the plumbing and electrics) and we’ve plastered the walls. We may have already decided which kitchen cupboards, their number and configuration we would like, but when we go to the shop to order them we discover they are no longer available. That’s an external change out of our control. If we then choose a different kitchen design, providing it is the same physical dimensions and configuration as the ones in our original plan we won’t have to make any additional changes. If however the new design requires a different configuration we may have to move some of the appliances which could result in us being required to alter the previously installed plumbing and electrical supplies. In the extreme case the new kitchen design could include additional cupboards thus increasing the size. This could require us to move some of the walls – probably making it economically unviable. The reason these different changes have different impacts is because they each have different levels of Architectural Significance.
In this example:
- Changing the style of the cupboards has no Architectural Significance and can be a like-for-like replacement. There are no changes to any of the interfaces.
- Changing the configuration of the cupboards (but remaining within the original footprint) changes the shape of the structure and potentially changes the points at which the appliances interface with the utilities. This has some Architectural Significance.
- Changing (increasing) the number of cupboards increases the size of the structure potentially requiring a change to the containing structure (the kitchen). This is very Architecturally Significant.
How to manage it
So know that we understand what Scope Creep is and what effects it can have, how do we go about managing it?
Firstly, understand the Lifecycle and the System Architecture
As we have seen, the impact of change is dependent on where we are within the Lifecycle and how Architecturally Significant the change is. This means we need two things:
- A lifecycle aware change process. That is, a process which requires more rigour as the lifecycle progresses through its different phases.
- A System Architecture description which allows proposed changes to be assessed for their Architectural Significance and an impact assessment made.
Sign-off at every stage?
James McHugh suggested that one possible management strategy is to “have sign-offs at every stage”. This implies a stage-gate process – a series of process phases, each of which can only be exited/entered via the successful navigation of a “gate”, usually a formal agreement that all the exit and entry criteria have been met (or that anything carried forward is acceptable).
Sign-off is the process by which the Customer agrees that the current problem description and/or solution specification correctly represents their understanding and needs. Traditionally, and in its most formal implementation, this involves the Customer signing a declaration on the relevant documents, hence its name. The advantage of this approach is that it aligns perfectly with the legal framework required for a contractual agreement. Also, because we know there is an inevitable cost to any change, it can also be used to help determine to which party (the Customer or the Supplier) those cost should be charged. There are however some disadvantages:
- Because of the “3 Evils” it may be very difficult for the Customer to confidently sign-off at any stage. This can result in a “Mexican Standoff” and unwelcome project delays.
- Once achieved it can place an inequitable relationship on the Customer which can make them reluctant to communicate future changes, thus resulting in the development of a sub-optimum solution.
- While it provides some guidance (albeit biased towards the supplier) on who should carry the additional cost of change, it doesn’t really help when it comes to changes due to missing detail, or problems such as a mutual lack of understanding due to poor communication.
Obviously some form of agreement is required, but a more effective method is based around a “consensual approach” rather than a stricter “contractual one”.
A better way?
Approaches like Model-Based Systems Engineering offer some advantages here:
- The model is a description of the System Architecture, thus allowing us to defer Architecturally Insignificant details until later, rather than specify all the details up-front.
- The use of a model shared between the Customer and the Supplier helps combat the “3 Evils” of Complexity, a lack of Understanding and Poor Communication.
- By ensuring the model covers not only the Solution, but also the Problem and Project spaces we can approach each stage-gate with a greater degree of confidence on both sides. The Supplier can better understands the problem and the Customer can better understands the process.
Addendum
I’ve found a paper here from Integrated Management Systems, Inc. (IMSI) which discusses the problem of Scope Creep from a general project management perspective.
