Many projects fail for several reasons. One of the major reasons is “The Scope Creep”. First let me define what the scope creep is and how it can sneak in on a project.
When a project is fist defined the scope is always a high-level scope as defined in the Project Charter and the Preliminary Scope Statement. The high-level scope is often accompanied by an Order of Magnitude Estimate of the cost that has a precision of -50% to 100% of the estimated cost.
As the project goes into the planning phase the scope is defined in detail and for IT-projects it is usually established in an Enterprise Design Document (EDD). The EDD is used as a scope and cost baseline for the project. The cost estimate established as part of the EDD is usually much better than in the beginning with a precision of -10% to +15%.
So what can possibly go wrong now that the scope is well defined? More than most imagine! As the project continues into the execution phase, stakeholders change their mind about functionality, training, time lines, etc. If someone asks for changes to training requirements, functionality, and time lines, they are changing the scope of the project. When that happens it most often affects the time, cost, and scope. A good project manager must execute proper change control to the project in the form of a project change request. This request must explain how the change will affect the project in regards to cost, time, and sometimes also quality. The request must get formal approval from the project’s steering committee and a new cost and time baseline must be defined.
Does this sound formal and excessive? Maybe, but it’s the only way to control the scope. If the project manager just accepts the change as part of the existing baseline the scope just increased with no changes to the project’s time and cost baselines. That’s the definition of the scope creep.
So what if we add a few hours here and there? Does it make such a big difference? Oh yes it does. If the stakeholders know they can add functionality or make changes to the time line without any repercussions, they will continue to do it. A training session is extended or postponed. Some additional functionality is added here and there. The amount of work is slowly increased and the time line is affected more and more. The scope creep is getting bigger and bigger from all these little changes that are allowed to slip through. And the result? The project is not delivered on time nor on budget. The project failed.
So the application of change control makes all stakeholders aware that changes to the project may affect the time line and budget and in each individual case the steering committee must decide if they want to go forward with the change and also accept the change in cost and time. If they agree, they must formally accept the change request and the project manager will now calculate a new cost and time baseline that now becomes the current baseline for the project.
So can a project end up costing twice as much as originally estimated and be delivered three months later but still be on time and budget? Yes, that’s the whole point of scope management. If the steering committee accepts changes to the project including cost and time changes, they also accept a new project baseline. Thus the budget and the time line just changed for the project.
Scope Management is in my opinion one of the most important management tasks a project manager must do. Controlling the scope by applying vigorous change control and not accepting any changes to occur in the project without executive acceptance is crucial. If you ease up on this strict control you risk losing control of the entire project and failure is most likely the outcome.