Protecting the Scope from Change

---

When it comes to project management, the one constant thing is change. Changes happen, or try to happen, all the time in projects. The project manager must have a reliable system to track, monitor, manage, and review changes to the project scope. Change control focuses on three things:

• Facilitates scope changes to determine that changes are agreed upon.

• Determines if a scope change has happened.

• Manages the scope changes when, and if, they happen.

Table 5-3 shows the inputs, tools and techniques, and outputs of scope change control.

Table 5-3: The Inputs, Tools and Techniques, and Outputs of Scope Change Control.

Inputs	Tools and Techniques	Outputs
Work breakdown structure	Scope change control system	Scope changes
Performance reports	Performance measurement	Corrective actions
Change requests	Additional planning	Lessons learned
Scope management plan		Adjusted baseline

Examining the Inputs to Scope Change Control

Throughout a project's life, the need and desire for change will come from project team members, the sponsor, management, customers, and other stakeholders. All of these change requests must be coupled with supporting evidence to determine the need of the change, the change's impact on the project scope (and usually on other processes as well), and the required planning, schedule, and budget to account for the changes.

Using the WBS

Your favorite project management tool, the WBS, serves as an input to the scope change control. It represents the sum of the components, and ultimately the project work, that make up the project scope. It characterizes the project scope baseline. The change requests may be for additional components in the project deliverables, changes to product attributes, or changes to different procedures to create the product. The WBS is referenced to determine which work packages would be affected by the change, and which may be added or removed as a result of the change.

Evaluating Performance Reports

The Communications Management Plan, which we'll cover in Chapter 10, includes specific requirements on the need for performance reports. Performance reports indicate how the project is going-good or bad. Performance reports can lead to change requests. How? When a project is going bad, operating beyond its budget, or off schedule, changes may be made to reduce the project scope, add corrective actions, or add quality activities to ensure the product is correct.

Considering Change Requests

Some project managers despise change requests. Change requests can mean additional work, adjustments to the project, or a reduction in scope. They mean additional planning for the project manager, time for consideration, and can be seen as a distraction from the project execution and control. Change requests, however, are a very real and expected part of project management. They can come in several modalities:

• Oral or written

• Direct or indirect

• Internal or external

• Legally mandated or optional

Why do change requests happen? And which ones are most likely to be approved? Most change requests are a result of:

• Value-added The change will reduce costs (this is often due to technological advances 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, 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.

Relying on the Scope Management Plan

Remember this plan earlier in the chapter? It's an output of scope planning and controls how the project scope can be changed. The scope management plan also defines the likelihood of the scope to change, how often the scope may change, and how much it may change. You don't have to be a mind reader to determine how often the project scope may change-and by how much; you just have to rely on your level of confidence in the scope, the variables within the project, and the conditions the project must operate under. The scope management plan also details the process of how changes to the project scope will be documented and classified throughout the project life cycle.

Implementing a Scope Change Control System

The most prominent tool applied with scope change control is the Scope Change Control System. Because changes are likely to happen within any project, there must be order to process, document, and manage the changes. The Scope Change Control System is the answer. This system includes:

• Cataloging the documented requests and paperwork

• Tracking the requests through the system

• Determining the required approval levels for varying changes

• Supporting the integrated change control policies of the project

• In instances when the project is performed through a contractual relationship, the scope change control system must map to the requirements of the contract.

On the Job 

The Scope Change Control System is likely to be computer-driven, automated to some extent, and provide workflow to route change requests to appropriate stakeholders and decision makers within the project.

Revisiting Performance Measurement

Performance Reports are inputs to scope change control-the contents of these reports, the actual measurements of the project-are evaluated to determine what the needed changes may be. The reports are not meant to expose variances as much as they are done to drive root cause analysis of the variances. Project variances happen for a reason: the correct actions required to eliminate the variances may require changes to project scope.

There is a distinct difference between performance reports and performance measurement, as shown in Table 5-4:

Table 5-4: Performance Reports vs. Performance Measurement

Performance Reports	Performance Measurement
Signal an inconsistency	Evaluates the degree of inconsistency
Serve as an output of performance reporting	Defines expected and experienced performance levels
Serve as an input to change control	Measures current performance against what was planned

Completing Additional Planning

Planning is iterative. As change requests are presented, evidence of change exists, or corrective actions are needed within the project-the project manager and the project team will need to revisit the planning processes. Change within the project may require alternative identification, study of the change impact, risks introduced by the change, and solutions to problems within the project execution. Changes made as part of this planning could cause the project plan, project WBS, and the project baselines to be revised.

Updating the Project Scope

When changes to the project scope have been approved, the documented project scope must be updated to reflect these new changes. The stakeholders affected by the scope changes must be notified. The WBS must also be updated to reflect the components added, or removed, from the project. Scope changes can include cost updates, schedule updates, quality updates, or changes to the project deliverables.

When the project scope is to be changed, the new requirements must pass through the planning processes. The changes must be evaluated for cost and time estimates, risk, work considerations, product specification, and technical specification.

Correcting the Project

Often the reason for change is due to faulty deliverables, quality problems, or poor performance of the project deliverables. Corrective actions are activities that will make an effort to bring the project back in alignment with the project plan. Errors and omissions in the product specifications are scope changes, not corrective action changes.

Updating the Lessons Learned

The lessons learned documentation should be updated as an output of scope change control. The project manager should document reasons why changes were approved, corrective actions were taken, components were added or removed from the scope-and the reasoning behind these decisions. Lessons learned will serve as future historical information and help guide other project managers.

Adjusting the Project Baselines

When changes are made, the project baselines will need to be adjusted to reflect these changes. Such changes can affect time, cost, schedule, and scope. The changes that affect the appropriate baseline should be updated to reflect the new project scope. The new baselines serve as a point of reference for the remainder of the project (assuming there are no additional changes). Should other changes occur, the baseline should be updated-enabling the project to continue.

---