Creeping, Crawling and Standing in the Headlights

November 2002

I have been watching the progression of the replacement for Wembley Stadium from a£150m to a £750m development. I'm sure, sitting behind the scenes, there is a frustrated Project Manager saying 'what do they expect if they keep adding new bits like a running track - who said they wanted a running track when they started?' He would most certainly refer to this as 'scope creep' or a continual change in the requirements. To follow the football analogy through - 'moving the goalposts'.

In Project Management terms, scope creep is usually associated with negativity and perceived loss of control. In IT, however, the most successful implementations are those that are developed on an iterative basis when you keep re-defining the scope as you go down through the detail. In this sense the targets and objectives don't scuttle along the floor by themselves, but evolve as a clearer understanding of what you really want develops. As IT should be bound together within the discipline of good Project Management practise, is scope creep the enemy, or an intrinsic part of a well developed plan of campaign?

Certainly, one danger of trying to fix what you want up front, is that you use familiar points of reference rather than developing new models - it's easier to stay in your 'comfort zone'. If you develop a billing system, for example, and pre-define the scope, you are certain to create a derivative of every other billing system that you have had experience of - in essence you apply 'conceptual legacy' baggage to the next generation of development. This can mean that you will incorporate some of the bad things along with the good, and you may miss some of the new developments or integrations in the field.

Maximising your intellectual capital and experience is essential, as is 'fitness for purpose'. However, the pace of development of technically related business models means that sometimes it is better to start from a blank piece of paper rather than pre-suppose anything. Consider all the other uses of the word 'Scope' where there is an association with instruments that are used to enhance vision - telescope and periscope as examples. To draw an analogy, the laying out of the plan in broad terms gives the larger perspective to the vision of what you want to do, but the ability to zoom in and explore the detail as you go along is fundamental to the development of your view about where you should go next.

What this really boils down to is that, in a constructive and progressive environment, scope creep is not a specific beast to be feared, but a natural part of the process that should be embraced. The delivery of an item should not preclude the ability to adapt while in development to constantly improve the applicability and relevance of the deliverable benefits. To restrict this approach of 'adaptive benefits delivery' is to put constraints on the outcome that may increase the probability of not getting what you really want or need. The issue is not really change, but the manner in which the change process is dealt with and the expectations management around this.

The success of any project, but particularly an IT one, is in the value represented to the business when it is actually applied in use. To best illustrate this consider the amount of scoping documents that specify that a system should be 'easy to use' - who determines what that means? Usually, designers and high level user representatives but it is the most technically challenged of the people who will actually use the system that will determine if it is really usable. The people who define a fixed scope and those who define its measure of success are very rarely the same people, so trying to align them at the end of the process is doomed to failure. In the UK Public Sector, for example, there an understandable focus on value of money and quantification of this value in terms of not deviating from the original set objectives. This can have the effect of wringing all the flexibility out of the system which in turn has a tendency to result in delivery of inapplicable systems, not because of poor conception, but rather because their path, good or bad, is fixed from the start.

Changes NEED to happen along the way and what really successful project management is really about is not defending the boundaries of a project from all comers, but embracing and managing change in a manner that minimises dynamic risk and, above all, in a way where all parties see the value proposition of change. This is the management of expectation, the building of trust that means that all parties go into the process accepting that fact that they don't know the full outcome but will work together to get the best and most cost effective result based on iterative and reviewable 'Fairy Steps' rather than 'Giant Strides' that have a tendency to overstep the mark before direction can be changed and budget reallocated. Far from defending things like budget, giant scoped strides can be a very effective means of hitting the proverbial brick wall with wads of cash in your hands.

'Scope Creep is Bad?' If it is a fundamental part of your thinking then you may already be caught in the lure of the headlights with the car bearing down on you. Change is good, healthy, and at the core of real and motivational success, but it has to be expertly managed in an environment where there is an initial responsibility to represent the need for flexibility and change to adapt to increasing layers of understanding as the project progresses. Beware of any process that claims to have all of the answers up front - it probably means that people are not asking enough questions - 'In the Valley of the Blind the one eyed man is King' - but how do they know he has one eye?.