Five rules to reduce scope creep in your projects
Reducing Scope Creep
Scope creep remains the biggest cause of projects failing to deliver within their baseline constraints. This isn't news, it has been regularly reported since the mid-1970s and probably earlier. But why, if we all know about it, do we keep making the same mistake? Why do attempts at reducing scope creep not seem to work?
Some of the answer lies in the fact that changes do occur. Just as no man is an island no project is either. The market, strategic context, technology, environment and many other factors that bear on the project can alter. If the project doesn't respond it will inevitably fail. Response in this sense nearly always means amend the scope in some way. For example a competitor launches a new product with features that prove to be very attractive to the market; would we really launch our product without such features or, better still, those features taken to the next stage of their evolution?
Perfectionism and 'gold plating' may play a part too. Technologists when not innovating earn their corn by improving. Since nearly everything can be improved there is no shortage of opportunity for scope creep - you wanted a simple ice cream cone and you ended up with a double 99 with hundreds and thousands and strawberry sauce. Can we resist the appeal of all those features? Wouldn't the world be dull if we all simply had a single scoop vanilla cone? But do we find them a worthwhile investment or would we have had the primary need satisfied by the simpler, cheaper and less risky alternative.
Some, if not most, of the answer lies in the fact that we are not clear from the outset what the scope needs to be. The demands to 'get going' can be very forcible. There is that sense of frustration when we know that we need to run a project but initiation and stakeholder alignment seems to take so long. Aren't we better just getting started and sorting out the detail later? Sponsors tend to have limited patience too. Understandable when a competitive market place and short-term commercial imperatives dominate their horizon. Even the very schedule itself is a driver that hurries us into development; deliberating about every aspect of the scope of the project for a new product whilst a competitor launches their version of the same thing and hoovers up the market is clearly counter-productive.
The list could go on and on but already we should be asking the question 'is it realistic to be able to contain the scope of a project to a completely pre-determined list of things at a specified level of quality and never have that change?' If the answer to that question is no we are walking into projects expecting, if not inviting, scope creep. How to deal with it is the question? Perhaps what we should do is formulate a set of principles or rules that allow us to contain scope creep to acceptable levels.
Here is a 'starter for ten' on what might constitute a reasonable set of rules and an explanation of why.
Rule one - clarify the business problem and the value of solving it before defining scope or constraints. Because humans are essentially solution orientated it is very easy to get 'carried away' with the development of the products. Because these products represent the project's scope, getting 'carried away' translates into scope creep. However the value of the scope arises from its ability to adequately address the problem. Pareto's rule comes into effect here. A 100% solution for all of the problems will see a diminishing rate of return on the cost. Put another way, 20% of the problem's resolution will likely give rise to about 80% of the value. Would you then want to build the solution to the other 80% of the problem to capture 20% of the value? If we are clear on the problem and how the value arises from its resolution we can limit scope to addressing those areas.
Rule two - focus on the value of any change before focusing on its cost and risk. Impact assessments in change control processes all too often look primarily at the cost and schedule impact of accepting the change. A scope and project-delivery centric view of the world. This is clearly the wrong way round, before looking at the achievability of any course of action (including sanctioning scope creep) we should examine the desirability of it. Desirability here is the additional pay-back that we will see in the long-term benefits that will arise from the broadened scope. If these are not significant and highly plausible then it simply isn't worth the effort of investing time and money on taking the impact assessment any further. We don't need to work out the cost and risk (both of which are likely to be substantial) if we can't see a significantly larger return on their investment.
Rule three - evaluate not only cost but also risk arising from scope changes. It is blindingly obvious that we have to factor the cost of the increased scope into the project budget. Equally obviously, especially in light of rule two, the figure for costs should be significantly out-shadowed by the enhanced benefits. What frequently gets overlooked is the risk component. By this we are not talking about the technical risk/s related to the products in the increased scope (although we must consider that too). Rather we are looking at the threat to the schedule, the critical path, the resource impacts on peer projects and the wider portfolio as well as the potential delay to the onset of benefits. Clearly as we add scope and therefore cost, additional tasks and time to the project it becomes significantly riskier and this must be reflected in our decisions.
Rule four - ensure the 'hidden' costs are factored into the evaluation. Even organisations adept at establishing the whole life-cost and change related costs of introducing the scope of the project into their business as usual activities can be tripped up by the 'hidden' costs. Opportunity cost is an important concept in project selection processes. There are always more good ideas for projects than resources available to deliver them. This means that the selection of any given project will exclude the delivery of a different one. However scope creep can easily represent a 'stealth' version of opportunity cost. Perhaps it is because, as far as the project is concerned, it is only a marginal increase in cost/resources required. However if organisations were to gross the total of change requests costs and resource impacts they would probably find that they are missing the opportunity to sponsors some significant and highly valuable initiatives. Other examples of 'hidden' costs might be over-runs on other pieces of work starved of resource or messed up 'cash flow' projections and consequent capital financing costs.
Rule five - review the balance of the business case in light of the change before accepting or rejecting it. Business cases are, all too frequently, a device for securing the investment funds and have 'outlived their usefulness' once the major investment has been committed. Nothing should be further from the truth. The business case should represent a 'living, breathing' document that contains the rationale and ongoing validation for the project's existence. To achieve this it must, as accurately as is reasonably possible, represent an appropriate balance of desirability against achievability. In short it must balance benefits against cost and risk to the extent that the organisation is prepared to support the gamble that the project represents. Changing scope, particularly in light of rules three and four, must represent a significant shift in this balance. This shift needs to be seen and evaluated by the sponsor and the rest of the governance structure and validated before a decision as to which way to go can be made. No live business case equates to no sensible investment decisions.
The golden rule!
Get hold of the key stakeholders and discuss, and agree, the expected outcomes and value of the project with them before determining the scope - never do it the other way around!
If you do you will end up with the tail wagging the dog and, worse, unpredictable and chronic scope creep.
Nick Dobson
Managing Consultant
Share this?
