Project Scope Management: What It Is and How to Do It?
Every project has a scope. It defines what is to be produced. It is set out by the client in a business case document, in a formal statement of requirements as a project, charter agreed between the client and the project team, and as a work program, setting out the project timings and costs of delivery in a project plan prepared by the project team.
Management of project scope has increased in complexity in recent times. Digital tools support the management of projects over a variety of different communications media. Without management of the various inputs and outputs, the Project Scope can move out of control. Hence the need for an effective scope management system. Change the project scope, and the project costs and timescales will also change. The ultimate deliverable will also be affected.
Some projects have a formal scope statement set out in a project document, and others use the Work Breakdown Structure (“WBS”) of the project plan. Either way, tasks included in the scope statement are in scope. Everything else is out of scope.
For the larger projects, PMBok has set out a multiple-step process. Smaller projects will also use this approach, with some steps collapsed together.
The steps involved in creating an effective scope management program will include:
1. Create a Formal Scope Management Plan.
In effect, this is a three-step process:
a. Scope Planning
This process establishes the scope management environment, and is developed from project documentation and agreed with project stakeholders. With change management, scope management will link directly with the change management plan.
b. Requirements Collection
Requirements Collection is a detailed interaction with all stakeholders to find out what their needs and expectations are. It is an iterative process. The output documentation should also set out for the management of their expectations.
c. Scope Definition
When you have planned the scope and defined the project deliverables, you are now in a position to document precisely what is, and what is not in scope. This statement will become the project bible, referred to throughout the project to determine if an activity is in scope or not.
2. Create a Work Breakdown Structure (WBS)
At this stage, the WBS can now is with the tasks, resources, and costs needed to deliver the deliverables. The agreed and signed off WBS will, in effect, define the project scope.
3. Project Validation
Having defined the project deliverables, the project scope, and how the project is to be managed through its lifetime, it is now time to validate those statements and assumptions.
- Have the project documentation approved and signed off by the stakeholders. This fixes the scope and prevents any comeback later. The WBS may need to be revised.
2. I agree with the approval process. Completed tasks are signed off as such. Stakeholders need to sign off milestones. This is particularly important if external contractors are to be paid based on delivery.
4. Change Control
Changes to scope inevitably follow changes in requirements. This will be part of the overall scope management environment and is developed from project documentation and input from stakeholders.
It is vital to involve stakeholders in this exercise if only to have them understand that once defined and signed-off, the project scope cannot be changed outside of formal procedures. If they do need changes, they will understand how to request them and what follows after submission of their request.
However, like a business’s annual report, the defined project scope is a snapshot of what was wanted when the project was first agreed. Life goes on, and the basis on which the project was built will change. Changes will happen, intended and unintended. They change the project scope, and that is where scope management comes in.
Changes can come from the stakeholders in response to changing business requirements. Sometimes they have a change of mind when they see the practical implementation of the project as it proceeds. In an IT project, they may want changes to the layout and text on user screens, despite having agreed to them at an earlier stage.
Changes may come from external sources. For example, in our building example, changes in Health and Safety regulations may force changes in how tasks are executed.
Often in a project, individuals apply small incremental out of scope changes to the project, each with little or no effect on the project critical path. Still, cumulatively they may do so, and one task change may have an unintended effect on another task.
Implementation of unauthorized changes gives rise to a term familiar to most PMs – Scope Creep, and it is the prime function of scope management to limit scope creep.
Scope Creep has Several Effects:
1. The project does not meet its original design objectives. To use an old analogy, what was initially designed to be a horse is delivered as a camel.
2. The target timescale and budget are not achieved.
3. The client is not happy with the product delivered as the project proceeds and will resist any requests for further time or money.
That means there is a need to manage Project Scope. You need to understand that Scope Management is a bit of black art, in that there is no authoritative way to do it. It requires diplomacy, pragmatism and a full understanding of the big picture.
There are three basic approaches to Scope Management and Scope Creep:
1. No Changes to the scope are allowed.
2. Changes are allowed but only after approval by Change Control.
3. All changes, unauthorized and authorized are allowed.
1. No Changes
This is ideal and is rarely if ever, achieved.
No Changes imply that the project scope as set out in the project documentation is the project bible and will not be changed. Any out of scope changes submitted to the PM is either discarded or put in a pending file for consideration after the project is complete.
There is no change control because no scope changes are expected or entertained.
The difficulty here is generally the management of the project team and management of the client.
There is a tendency for small changes to slip through when the client asks a team member directly. The excuse is that it is only a small change and will take no additional time or cost. The team member implements the requested change to keep the client happy. The danger is the law of unintended consequences.
Without looking at the effect of the small change, it could be that it affects another task in the project, and cumulative changes could affect the project itself. This small change might conflict with another small change.
Either way, project quality is compromised, and perhaps some of the project budgets are spent on unauthorized activities.
In an environment of no changes allowed, it must be made clear to both project team members and the client that no changes will be entertained. Hold them in a pending file by all means, and they will be considered at a later stage.
There is no escape, unauthorized changes will be found. Quality audits in which deliverables are measured against the project scope will highlight the small changes.
However, this approach is often considered too inflexible, and there are times when an urgent or forced business requirement causes changes to the project that must be implemented.
2. Change Control
As we have already discussed, scope changes are sometimes necessary, and a mechanism is needed to manage them. The Change Control mechanism is a first step in controlling scope creep.
To put it simply, the change is requested, it is then considered by an appropriate body, usually a Change Control Committee, and either authorized, rejected or held pending.
The Committee may ask for further information and analysis to help their decision. They need to know the effects on timescales and budgets and perhaps peripheral issues relating to the implementation of the change.
Managing Scope Creep in this way will move from a technical exercise to one of people management. Some client staff will expect that their requests are carried out without question, and will not be best pleased if they are rejected or pended by the Change Control Committee.
A savvy PM will know when it is better to give way in consideration of the bigger project picture, even though under other circumstances the request would be pended or rejected.
The use of the Change Control Committee will provide some protection to the PM, but some ruffled feathers can be expected from time to time.
3. All Changes Implemented
It is fair to say that the uncontrolled application of changes is a PM’s nightmare and a recipe for disaster. That may not be entirely true for small projects, but the project landscape is littered with the skeletons of failed projects where scope creep was not controlled.
At the very least, project timescales and budgets will not be met, and the PM will walk a difficult path in justifying project delays and additional costs. You will have an uncontrolled and probably uncontrollable project.
The client and team members will become disillusioned and unhappy with the frequent changes in the work program and deliverables.
The project deliverable may not be as originally envisaged, and the client will be unhappy with it. It may well be that the project moves to a state where it will never finish.
Bottom line, this is not the right place to be.