veryard projects home page
scope creep - the band
In praise of Scope Creep
Richard Veryard, May 2001You must know the story of Jack and the Beanstalk. Jack and mother poor, cow to market, Jack swaps cow for five beans, mother furious, beans thrown out of window, beanstalk grows, Jack climbs, giant wakes, fee-fi-fo-fum, goose lays, golden eggs, harp sings, beanstalk chopped down, giant dead, Jack rich.
But did you ever hear the story
about Jack’s uncle, the IT manager. He’s still out there in the garden,
looking for the other four beans.
An important aspect of project/programme management is scoping – the separation between what is included and what is excluded. Honest project managers rightly want to control costs and timescales of engineering activities, and they often do this by attacking a common devil known as Scope-Creep. Meanwhile, some dishonest project managers welcome Scope-Creep as an ally.
Scope-Creep has many other names. When he fiddles with the problem, he is called Requirements-Creep; when he fiddles with the solution he is called Feature-Creep; when he tries to engage extra stakeholders he is called Log-Roller; and when he tries to seduce stakeholders by promising extra benefits he is called Benefits-Scrounger.
But hold on, you might say. By condemning Scope-Creep
as a devil, are we not being unfair to the poor old chap. Of course,
there may always be some tediously narrow-minded project managers who are
incapable of seeing him in a positive light, but he has a heart of pure
gold. He has many close friends, who help him at all times, and I’m
sure they will be happy to speak up for him.
Scoping and Scope Creepveryard projects > project management > scope creep > scoping
Scoping includes both defining where the separation line is drawn (planning, design) and maintaining / enforcing the separation (management, governance, control).
Scope creep occurs when the line is moved - usually outwards. Thus what was excluded is now included, making something (such as a project) larger.
Scope Creep in Project Managementveryard projects > project management > scope creep > project management
Honest project managers enact these charms and rituals with great seriousness. The project scope is guarded defensively, and any interaction with the outside world – whether incoming or outgoing – is regarded with some suspicion, lest it introduce additional responsibilities and obligations onto the project.
Dishonest project managers are often covertly in league with Scope-Creep, and enact the same charms and rituals cynically and corruptly. For them, a key tactic is to pass off legitimate requirements as manifestations of Scope-Creep, and they accumulate them as bargaining tokens in order to improve their resource–responsibility ratio. Nothing delights them more than an opportunity to grab extra budget while simultaneously stacking up excuses for failure. They make extravagant promises, and then rely on Scope-Creep to get them off the hook.
Government departments are often seriously ripped off by large contractors, who can use Scope-Creep as a way of escalating the size of the project and escaping from penalty clauses. Meanwhile, the contractors themselves see strict change control and contract adherence as a way of protecting themselves against Scope-Creep.
But hold on, you might say. By condemning Scope-Creep as a devil, are we not being unfair to the poor old chap. Of course, there may always be some tediously narrow-minded project managers who are incapable of seeing him in a positive light, but he has a heart of pure gold. He has many close friends, who help him at all times, and I’m sure they will be happy to speak up for him.
Scope-Creep has the soul of a true engineer. He is always trying to improve things, to perfect things. But unlike many engineers, he is also strongly committed to meeting the user’s requirements. Whenever a project gets out of alignment with the requirements, Scope-Creep appears as if by magic, earnestly determined to put things right.
In a dynamic situation, aligning a project with the business requirements demands a degree of change. If the project manager tries to eliminate Scope Creep from a project, this amounts to a suppression of change, and a refusal to align with the business. In some cases, an inordinate amount of energy is devoted to resisting Scope-Creep, thereby undoing much of the bridge-building and rapport with users that was painstakingly established at the start of the project.
Although the project manager can prevent this consuming scheduled project time, she cannot always prevent it leaking commitment, as well as reducing the efficiency and quality of project-user interactions.
Indeed, our cynical project manager may use change control disciplines in order to increase misalignment and prevent the project doing anything useful. This is because a genuinely useful project usually generates a lot of criticism – firstly from the people who want it to succeed, and will crawl over every deliverable to make sure that it’s all going to work properly; and secondly from the people who don’t think it should have been done in the first place, and will be looking for reasons to get the project cancelled. If the project is obviously going to produce something of little value, whose relevance to the business has been significantly eroded by change, then nobody’s going to bother much with the details, and the project team is left to get on with it.
Scope Creep in Process Improvementveryard projects > project management > scope creep > process improvement
The project manager sits on the boundary of a project, protecting the activity inside the boundary, making demands from people outside the boundary, managing communications across the boundary, and resisting all attempts to move the boundary. From the project manager’s perspective, the boundary is an interface of a particular kind, which she perceives in a particular way.
As a consultant, I may want to support the project manager, but I don’t do this by accepting without question the project manager’s view of the world. And this includes the project manager’s focus on scope. There are other important aspects of the project boundary besides scope, and it is often useful for the consultant to focus on these aspects instead, to provide a view that is complementary to the project manager’s view.
As the project manager perceives it, what the consultant has proposed is usually to add something to the project, in order to make the whole thing smaller and/or more effective. To the sceptical project manager, this seems implausible if not paradoxical. Meanwhile, the consultant may not perceive the suggestion as adding anything at all. How can we account for this difference in perception?
What the consultant sometimes hears is: We’re too busy to get things right first time. And the consultant then responds: So when are you going to have time to repeat it until it’s right? But of course, that’s not necessarily what the project manager thought she said. This is a fairly common pattern of misunderstanding between consultant and project manager. One way of viewing this misunderstanding is to hypothesize that the consultant simply doesn’t see the boundary of the project in the same way as the project manager does. (This hypothesis, of course, takes a perspective outside both project manager and consultant. Whose perspective is this?)
After all, we consultants have an agenda too: we usually want to add value in some way to a project, preferably in a way that is visible to all concerned. And it isn’t always only the project manager that we’re trying to please or impress.
Scope Creep and Scope Trading in Programme Managementveryard projects > project management > scope creep > programme management
Even honest project managers do this – not out of mischief but sometimes out of confusion, and sometimes in the belief that shifting material from one project to another benefits the whole programme. Each project team has a vision of its scope, and perhaps a vision for the whole programme from its own viewpoint – leading it to draw conclusions about the “proper” place for this or that material. Even when two neighbouring projects agree about the boundary between them, a system architect with a different perspective over the whole programme may wish to overrule them.
In risk management, it is the risks falling into the no-mans-land between the projects that often cause the greatest trouble. Here again, Scope Creep is at work, encouraging the risks to creep across the project boundaries like weeds encroaching your garden. This phenomenon might seem to give project managers some incentive to manage these risks collaboratively.
Programme management is therefore sometimes called upon to play a policing
role – patrolling the boundaries to make sure the architect’s vision is
respected, and is not undermined or corrupted by scope-trading.
|For more about interfaces and alignment, see Chapter 4 of my latest book. Richard Veryard. Component-Based Business: Plug and Play. Springer London, 2001.|
Scope and Identityveryard projects > project management > scope creep > scope and identity
Requirements engineering is often dominated by a conceptual legacy. People are often influenced by the names of legacy systems - they interpret the name of a given system as a sign that this system ought to be the right place for a given requirement. Because this system is called the Billing System, it ought to handle everything that we regard as Billing. This conceptual legacy strongly affects the scoping of the Billing System and its boundaries with other systems. It may even affect the very integrity and survival of an entity called The Billing System - in other words, its identity.
Furthermore, scoping is usually based on some notion of clustering strongly related requirements together. But that depends what we perceive as strongly related - and these perceptions change over time. Many systems engineers find it easier to perceive new connections - new forms of relationship - than to forget old ones.
If our notion of the identity and scope of the Billing System gets broader and more complex over time, this can be regarded as a form of conceptual Scope Creep - perhaps even Vision Creep. Are our ideas becoming confused and bloated? Or are they expanding, growing, evolving, becoming enriched? That depends on your point of view.
Users' mental models of legacy systems and other artefacts are important in another way as well. The actual use of a system by actual users depends on their mental models of the system. The users often don't use all the features of the legacy software, and engineers may sometimes be pleased to discover that a new requirement can be satisfied by switching on an existing feature and retraining the users, with no need to restructure the legacy code. This could be seen as changing the socio- part of a sociotechnical legacy system, and leaving the technical part the same.
The engineers responsible for developing a system often try to anticipate undesired usages of "their" system by wayward users. Sometimes the system is heavily optimized towards a particular notion of its use, and alternative notions must be discouraged or banned, to avoid troublesome performance. (For example, complex online enquiries may be banned, because they would absorb too much network resources.)
But the users generally spend much longer using the system than the engineers spend designing it. And the users are generally more ingenious and determined than the engineers give them credit for. So they often find ways around the barriers, forcing the system to do what they want after all, albeit inefficiently.
Thus Scope Creep appears here in the form of Usage Drift - as new modes
of using the artefact diffuse across a community of users. In general,
all manifestations of Scope Creep - including Requirements Creep, Feature
Creep and Usage Drift - can be understood as forms of diffusion. So how
are we to position ourselves in relation to this diffusion - as passive
recipients or as actors in some network?
|For more about diffusion and value, see my paper on the Diffusions of Components (pdf).|
Instruments of Scopeveryard projects > project management > scope creep > instruments
It is no accident that SCOPE is used to designate various instruments supposed to enhance vision - telescope, microscope, periscope. Even with the best lenses, these instruments are imperfect, unreliable, with false or double images at the margins. And in requirements engineering also, scoping follows the logic of the visual field - it is based on drawing meaningful distinctions and regions across an image or mirror of the requirements (usually known as a model). Zooming in on a crisp line reveals it as a blurred region demanding further analysis - and this can be repeated ad infinitum, fractal style. Zooming out reveals separate regions and shapes and patterns that are not clearly visible in close-up. The tools and techniques of requirements engineering and project management are (imperfect) instruments for creating and viewing these images.
This leads to the conclusion that Scope Creep is an imaginary creature. Scope Creep can only be viewed through these instruments, may be a useful fiction, but has no independent real existence. We may project our problems onto this imaginary creature - but after all what would we be without such projections?