5.5. Controlling the Project Scope (PMBOK, Section 5.5)
Scope control is about protecting the project scope from change and, when change does happen, managing those changes. Ideally, all requested changes follow the scope change control system, which means that change requests must be documented. Those changes that sneak their way into the project scope are lumped into that project poison category of scope creep. Scope creep is, of course, bad, bad news.
Corrective actions—those steps taken to move the project back into alignment with the project scope—don't require formal change requests, because the project manager isn't changing the scope, but rather the work that's outside of the project scope. Corrective actions are a part of scope control because you're nudging, and sometimes shoving, work back into alignment with the project scope. The trouble with scope creep and corrective actions is that the project team is doing or fixing work that should never have entered the scope in the first place—and that means wasted time and dollars. That's one sure way for a project to be late and over budget.
Controlling the project scope is also concerned with "influencing the factors that create project scope changes." That's the PMBOK way of saying that the project manager must control the project team and the project stakeholders from doing anything, absolutely anything, that's outside of the project scope. It also means that the project management team should capture the customer's vision in planning before much of the project work begins. For example, it's always easier to make changes on a blueprint than in construction. Gathering all requirements and creating an accurate project scope statement can ward off changes during execution.
5.5.1. Using a Change Control System
While it's dreamy and ideal for requirements to be gathered completely before the work begins, change requests to the project work are still likely. Every project demands a change control system that defines and controls how changes to the project and to the product can be approved. The scope management plan defines the change control system, its procedure, and how the change decisions can be made—often with a fee just to entertain the change request. The change control system should be reviewed during the project kickoff meeting so that all of the stakeholders are aware of the process.
Change control is part of the project management information system to help control changes to the project scope. This helps automate the procedure, but doesn't necessarily make approving or denying change requests any easier. The change control system also considers integrated change control. Integrated change control examines the proposed change and how it affects all of the project's knowledge areas. For example:
How does this change affect the project scope?
What is the cost of the change?
How does this change affect the project schedule?
How does this change affect quality?
What resources are needed or affected by the change?
How does this change affect communications?
What risks does this change present?
Will procurement be affected by this change?
The change control system should do several things for the project management team:
Document all change requests
Track each change request
Document approval levels required for a scope change
Provide the status of each change request
5.5.2. Planning for Project Scope Changes
When a change is presented, part of considering the change involves additional planning. The project manager and the project team must reconvene to examine the change and how it may affect the project work and the knowledge areas discussed earlier. Changes are sometimes unapproved, such as when a project team member takes the initiative for a change and does not follow the change control procedures. In these instances, the project management team must consider the change and examine the variance to determine the response.
Consider a team member who moves the light fixtures in a kitchen construction project by two feet. The team member believes the kitchen would be better lit with the lights moved to their new position, but he didn't follow the change control process to make the change. Now there is a variance in the scope—a difference between what the specification documents called for and what the team member did. The project management team has to consider how to manage the variance. Should they redo the work or accept the change as the team member has done? If they redo the work, they may lose time and money, but they'll be in scope. If they leave the change as is, then they're out of scope.
Another consideration for all changes is the configuration management system. Configuration management documents all of the features and functions of the project's product. When a change is requested, the impact on the features and functions of the product is documented with the change request before the change is allowed to move through the integrated change control process. For example, a change to add French doors to a home construction project would need all of the features and functions of those French doors so that the true impact on the project's knowledge areas could be examined fully. Failure to accurately document the change can lead to assumptions proving false, new risks, schedule slippage, and financial costs within the project.
|
5.5.3. Approving a Change
It's a safe bet that changes to the project scope will happen during a project. Why do change requests happen? And which ones are most likely to be approved? Most change requests are a result of:
Value-added changes These are changes that will reduce costs. (This is often due to technological advances made since the time the project scope was created.)
External events These could be such things as new laws or industry requirements.
Errors or omissions Ever hear this one: "Oops! We forgot to include this feature in the product description and WBS!" Errors and omissions can happen to both the project scope, which is the work to complete the project, and the product scope, which is the features and functions of the deliverable, and typically constitute an overlooked feature or requirement.
Risk response A risk has been identified and changes to scope are needed to mitigate the risk.
When change requests are approved, the affects of that change should be documented throughout the project. The Iron Triangle of Project Management is a good example: If the project scope increases, then the project schedule and the project costs will likely need to be changed to reflect these changes. Here are all of the project components that will need to be updated to reflect any approved changes to the project:
Project scope statement
Work breakdown structure
WBS dictionary
Scope baseline
Additional requested changes
Organizational process assets
Project management plan
Change requests must always follow the change control system, or they are considered out of scope. As the project manager and the project team discover and report changes that are out of scope, the project management team must deal with the changes to remove them through corrective actions or incorporate them through the change control process. Those changes that are incorporated into the project must still be documented and then reflected in the above project components. No changes sneak by!