Scope creep, changes to requirements after they presumably have been settled, is surely the biggest reason projects overrun budgets and schedules, yet still fail to deliver desired results.
This isn’t news. It’s been known for a long time. Lots of explanations and solutions have been offered over the same period, but scope continues to creep.
I find our scope creep dilemma is due largely to what I call “conventional we’s dumb” reflecting widespread but nonetheless mistaken understanding of scope creep’s REAL causes and the ineffective solutions which inevitably result.
For example, perhaps the most typical responses to scope creep are to blame change control procedures for not preventing changes and the project manager for “poorly managing the project.” Adding further procedural overhead mainly creates resistance, and a project manager who has been beaten up may learn how to hide things better but probably continues to have the same kinds of creep. Their supposedly better-managing successors also almost certainly suffer similar or worse creep. The blame game cycle repeats and projects persist in failing. Sound familiar?
Scope Creeps Because …
My analysis indicates that the overwhelming reason the scope creeps is that the scope was not defined correctly in the first place. Thus, the scope is not creeping, or at least not as probably presumed. Rather, what’s changing is awareness of what the scope should have been all along.
The negative impact of incorrectly-defined scope grows geometrically when the organization’s processes and procedures first fail to recognize this fundamental cause of creep, and then especially when they tend to impose all manner of counterproductive reactive behaviors, such as inquisitions to punish project managers and.often-mindless mechanical administrative restrictions on the changes they actually desperately need.
In Turn, Because …
I’ve found three main frequently-interrelated reasons why defined project scope so often is either wrong or at least not right.
1. Defined in Inappropriate Terms
Most projects I encounter have a one- or two-sentence scope statement which generally consists of objectives or desired benefits. Objectives indeed are essential for project success. In fact, success means achieving the objectives. However, scope defined in terms of objectives cannot help but creep because nobody knows what they’ll get. Each person has his idea of what will achieve the objectives, and there’s a good chance their idea doesn’t match someone else’s, but nobody recognizes it.
Alternatively, some project scope is defined in terms of tasks to be performed. Vendors who have succeeded in business use this method. Because the vendor can control the tasks they perform, defining project scope as tasks enables the vendor to be sure they can satisfy contractual commitments—regardless whether the client’s needs have been met. Ironically, if/when the client’s needs are not satisfied, it creates an opportunity for the vendor to propose follow-on work doing additional tasks which presumably will meet the client’s needs. If the vendor does the promised added tasks but still does not meet the client’s needs, round and round it can go again.
2. Defined (Often Dictated) Prematurely
I find that many projects are destined to fail because the scope is set, typically in concrete, prematurely. Scope definition is premature when it’s not based on adequate information. Many projects are initiated by executive pronouncements which too often dictate project triple constraints—scope, budget, and schedule–without sufficient understanding of what’s needed or what it will take to accomplish it. Executives tend to presume mistakenly that their position alone imbues them with the necessary knowledge. It doesn’t.
Some organizations have formal project initiation procedures to assure project decisions, in fact, are based on suitable information and reliable decision making. Such procedures usually are called “feasibility analysis” or something similar and typically include formal cost/benefit Return on Investment (ROI) financial analysis.
While these analyses can be done effectively, too often, they are all-form-and-no-content expensive window dressing that gives only the illusion of well-supported decision making. Cutting through the rigmarole frequently reveals only findings to support the result that the advocating executive wanted to dictate all along.
Organizations that consider themselves Agile may not be defining the scope explicitly at all. They may simply leave it up to the Product Owner to decide what goes into the backlog, which some may consider defining the scope. Also, Agile projects would seem highly unlikely to have formal project initiation procedures. Recognize though that these Agile actions actually may reflect informal, implicit decisions that are equally premature. Thus, the backlog may include only stories that fit the Product Owner’s possibly fuzzy impression of what is in scope; and that impression could constantly change, though perhaps without awareness or thoughtful consideration.
3. Predicated on Presumed Product
Especially, but by no means only, Agile projects generally define their project and thus its scope based on the product/system/software they expect the project to produce. That’s all well and good unless the product is not right—which happens far more frequently and to a far greater degree than ordinarily is recognized.
REAL Business Versus Product Requirements
There’s another even more important but seldom-recognized fundamental problem with focusing first on the product, and this problem is a major reason presumed products turn out to be wrong. Products do not themselves provide value.
A product provides value only to the extent that it satisfies what I call REAL Business Requirements—business deliverable whats that provide value when satisfied by some product/system/software how.
Creep largely occurs when the presumed product feature hows fail to satisfy the REAL Business Requirements whats, usually because the REAL Business Requirements whats have not been defined adequately, in turn typically because “conventional we’s dumb” mistakenly says the product features hows are the requirements.
Scope doesn’t creep nearly so much when the scope is defined as high-level REAL Business Requirements deliverable whats that provide value by achieving objectives when satisfied. Moreover, when the scope is defined in business terms everyone can understand reasonably the same, misunderstandings, miscommunications, and creep drop dramatically.
Recognize, though, following an appropriate model is only the starting point. It takes time for informed, skilled, integrated data discovery and analysis to identify the right REAL Business Requirements right. Often they are not evident or as presumed. As discovery and analysis proceed, the scope can and should adjust as understandings improve; but when done right, such adjustments will be far less and far less disruptive than conventional creep.
