July 2000

Manage Scope and Compete on Internet Time
Scope Creep is the Leading Cause of Project Failure
By Alan I. Zucker

Scope creep is the insidious growth and/or change of project requirements. Scope creep happens because mortals cannot always anticipate and identify all requirements ‘up front’—systems are too complex and the business and technical environments change too quickly.

ALREADY A SUBSCRIBER? Log on to read the complete issue. NOT A SUBSCRIBER? Become an ESI Horizons subscriber today and gain immediate access to current and past issues of ESI's premier project management newsletter. It's free.

Scope creep is an evil that we created for ourselves. It is a function of our past. In the old days, systems were large and based on sequential processing rules. Common wisdom was, if the requirements were not clearly defined “up front”, then the cost of changes would be high.

So, we got caught into the scope creep trap. We wanted to make it perfect with the first release, because we knew scope creep was “bad.” The fact of the matter was, we crept the scope and had subsequent releases in order to get it right. 

What is project scope?

• Scope is what a project manager commits to delivering
• It is never defined at the start of a project
• Generally it is not even fully defined midway through development
• Sometimes it is still up for debate during testing

Releasing Projects with Internet Speed
To effectively manage projects on "Internet Time," we need to radically change our thinking about scope. First, we need to realize we are in a new age and time. The pace of business and technological change is rapid. The Internet, N-tier architectures, object-oriented development environments and relational databases free us from the shackles of the past. 

Second, we need to recognize effective "Internet Time" projects are managed as a series of mini-releases that support an overall business objective. These objectives are broad visions that adapt to the changing business environment. They cannot be reduced to a rigid requirements document. 

Managing projects in "Internet Time" requires 
us to adopt new and different approaches 
to managing project scope.

Releasing Projects in Phases
We must scope projects into mini-releases. Establishing scope for a mini-release requires balancing the demands of timing and functionality. The mini-release should contain enough functionality to provide sufficient business value. However, the duration should be short enough to react to the changing business conditions. Congruently, we must schedule our mini-releases so that they flow almost seamlessly from one to another. 

Time Keeps on Slipping
In addition, we must explicitly include time constraints when defining the mini-release scope. In other words, we should set the duration of the mini-release, and then determine scope based on what can be completed in that timeframe. Requirements that cannot be completed in that release should be automatically scheduled for future releases. 

Set Achievable Goals
When constraining the duration of the release, we should not expect that our development teams will create more functionality faster than they currently do. The lessons of the “Mythical Man Month” still apply to "Internet Time" projects. Another lesson from the past is that good developers will commit to more than they can deliver; particularly on an exciting project. Therefore, it is critical to set clear, achievable goals for our project scope.

Defining Priorities
Third, to help manage the scope of "Internet Time" projects we need to perform requirements prioritization, risk analysis and contingency planning in the project planning process. By applying these tools together it is possible to identify potential hurdles and opportunities that would not be evident if the tools were applied in a linear fashion. 

The prioritization step is necessary to separate the project requirements into the absolutely necessary, the important and the optional. Even though most project managers use some form of requirements prioritization, they are generally not rigorous enough to force trade-offs. 

Risk Analysis
Risk analysis and contingency planning are complimentary activities. For each requirement, we must ask what is the risk of the requirement not being fulfilled, the probability of this event and its impact. For those requirements with a high risk of not being fulfilled and a high-impact to the project, we should develop contingency plans or alternatives for fulfilling them. 

Project managers who learn to effectively manage scope and who find creative solutions to the changing requirements that put their projects at risk, will be able to compete in "Internet Time." 

The business world has changed and with it, the measurement of time has changed. In order for projects to compete and be successful the management of scope must adapt to the world on “Internet Time.”