PM Foundations The Change Control Process

JUNE 16, 2011 3 COMMENTS

I recently blogged about managing changes to your project this post discussed the definition of change,
sources of change, early warning signs, the change control process, and measuring change. In this post I
am going to focus in on the change control process. The overall goal of change control is to prevent
changes from overwhelming a project or taking the project unnecessarily off track. The goal of change
control is NOT to prevent all change. The change control process enables proactive identification and
management of change, in a manner that keeps the project moving in the right direction, towards
successful completion/delivery. Effective change control processes maintains the appropriate balance
between control/discipline to manage to the baseline plan, and flexibility to adapt the plans to meet
customer expectations. In the spirit of not overcomplicating the process, the basic steps associated with
the change control process are pretty straightforward (depicted
in the graphic below).

Identify Change
Changes may be identified while updating and evaluating
schedule progress, performing project budget updates and
analysis, assessing on-going project risks, performing quality
control activities, and engaging with project stakeholders (e.g.,
project team, project sponsors) via normal project
communication channels.
Here are some examples of how you may identify change in your project:

While comparing the work results to the plan (part of monitoring and controlling project work), you
realize that testing activities are taking twice as much work effort to complete based on original
estimates.

A risk is identified that a key resource will be taking a leave of absence during a critical month of
the project.

You are updating the project budget and identify that consultant rates are consistently tracking 1012% higher than originally planned.

You are managing a project for the introduction of a new product. The company finds out that a
competitor is developing a similar new product, and something will need to be done in order to be
competitive. This is brought up at a project sponsor update meeting, and requires follow-up actions.

During load testing, the team realizes that the technology architecture is unable to handle the
necessary volume. This started as a project risk, and is now a project issue.

During the process of identifying the change, the project manager will refer to the guidelines established
in the Project Management Plan to determine if this is a change that should be managed utilize through

the formal project change control process. Factors such as the following are utilized to determine which
changes should be formally documented and managed:
The impact of the change represents a permanent change to the project baseline (not a timing

related change)
The change has a significant impact on the project baseline (above the materiality threshold

established for the project)

The change represents something that is new or different than what was utilized to establish the

baseline plan. Clarifications or more detailed definition of planning components (progressive

elaboration) generally are not handled as project changes. This is a point that is often contentious
from a customer relationship perspective.
Changes should be documented in detail using a project impact report (PIR) for each individual change.
The project impact report should include the following information based on the assessment (at a
minimum):
Change Header Information

Project Name

Project Impact Number (reference number assigned for the change)

Date (date the project impact report was created)

Project Manager

Project Sponsor (who is accountable for the project)

Description of change and how it impacts the project

Checkbox for areas impacted by the change (scope, schedule, cost, quality, risk)

Background (includes information like why or how the change was identified, reason for
change, benefits of implementing change, and/or risks associated with not implementing change)

Impact Descriptions (description of how the change impacts each of the project areas
identified as impacted in the checkbox)

All changes should be added to a change control log in order to track the status of the change. The
change control log should include the following information (at a minimum):

Unique tracking # assigned on the project impact report

Title (one line summary description of the change)

Date Created (date the change was formalized utilizing the PIR)

Cost Impact in dollars (quantification of the cost impact of the change)

Schedule Impact in days (quantification of the schedule impact of the change)

Scope Impact (quantification of the scope impact of the change)

Status indicate where the change is in the change control processes (Assess,
Approval, Approved, Implemented, Complete, Rejected)

Status Comments provide more details about the status and history moving
through the change control processes

The change control log is the place that any project team member can go to see all of the changes that
have been identified and the current status of all of those changes.

Assess Change
Once a change is identified, it needs to be assessed for impacts. The following dimensions of the project
could be impacted: scope, schedule, cost, risk and quality.

Is the current baseline scope going to be impacted and how? Is the current baseline schedule
going to be impacted? Is the current baseline budget going to be impacted? Is the agreed upon
quality of deliverables and/ or product going to be impacted? Is the change going to impact the
assessment of project risk?

The impacts could be positive or negative.

As the project manager, you are managing expectations. Establishing a baseline helps manage
expectations among stakeholders and commitments to the customer/ end users. If that baseline will
be impacted by a change, that needs to be examined.

It is important to quantify the impacts of a change. If the impacts are not clear, it is difficult to make an
appropriate decision about whether or not to approve and implement a change to the project.

When possible, impacts should be quantified by indicating cost impacts in dollars, schedule
impacts in work-days, resource impacts in hours effort, risk impact in terms of the risk assessment
(before and after implementation of the change), and quality in terms of impact on open defects /
issues.

For example, there is a change request to add functionality to a system, and development has
already been started. The assessment should identify what activities are required to add that
functionality, including the additional hours of work and cost of that labor, and the resulting schedule
impacts of doing that work. When considering what activities are required to add the functionality, you

have to consider the fact that the system requirements, system design, and test plan will all most
likely need to be revised. Also consider any re-work that may have to be done for parts of the system
that have already been developed. It may also be possible to quantify the increase in user satisfaction
by adding the functionality to the system.
It is important to involve the appropriate project team members in describing and assessing the change
so that impacts are accurately assessed and quantified. It is usually members of the core project team
that assess changes. Each core project team members should be able to speak to the impacts specific to
their area of expertise or their group. The impact of the change is documented on the project impact
report:
Impact Estimate (quantification of how the change impacts each of the project areas, including

the assumptions associated with the impact estimates)

Product Scope Number of features changed / added

Project Scope Number of deliverables changed / added

Schedule Days impact on key milestones, hours impact on resource estimates

Cost Dollar impact by cost category

Quality Change in open defects / incidents

Risk Change in risk severity or probability estimates

Approve Change
The Project Management Plan establishes the change review and approval process (you do not want to
be in a position where the process is invented in response to the first change).
The following describes the key guidelines associated with review of changes:

Generally, projects establish a regular timing for submitting / reviewing changes (e.g., change
control board meets every other Wed., and changes must be submitted by EOD Monday)

In addition, a process must be established to accommodate review/approval of rush changes.

These are the changes that have a time constraint for associated with making a decision about the
change and/or have an extremely high impact on the project.

At a minimum, the project impact report is submitted for review / approval. Some changes will
require additional supporting documentation to better describe / explain the change or impact of the
change. For higher priority or high impact changes, it is generally best to provide a face to face
explanation.

The following describes the key guidelines associated with the approval process:

The core team (or select members of the core team) approve all changes. This confirms that the
core team agrees with the assessment, and the implementation approach for the change.

The project sponsor or project steering committee approves changes that are over a specific
impact threshold (e.g., two weeks, 40 hours, $2,500, new feature).

The customers environment (compliance requirements) generally establishes the process

associated with documentation of the approval (email, collaboration tool, verbal, signed copy of the
PIR).

The timing of the approval process is established to ensure that the impact does not become
larger, due to delays in the approval process.

Note: The review / approval process should occur BEFORE the actual change has occurred, and the
corrective action has been implemented. This allows the reviewers/approvers to make decisions
associated with changes to the project, and the change implementation approach.

Implement Change
The same level of rigor is required to plan changes to the baseline plans, as were required to develop the
baseline plan originally. This is an area that many teams fall short they often behave like change is
complete at the time it is approved (contrary to popular opinion, changes do not implement themselves).
In addition, it is important to adjust the planning artifacts to reflect the most current version of the plans:

Project Management Plan Project description is updated to reflect adjustments to the product
and/or project scope

Project Schedule Deliverables, activities, dependencies, and milestones are updated to reflect
the impact of the change on the project schedule. In addition, the schedule baseline is adjusted (using
set baseline in MS Project) to reflect the impact of the approved change on the project timeline.

Project Budget Planned and forecasted amounts are adjusted to reflect the impact of the
approved change on the project budget

Risk Log Risk ratings (probability and/or impact) are adjusted based upon approval and
implementation of the change. In addition, the risk log is updated to reflect new risks introduced with
implementation of the change.

Project files Change control documents (project impact reports, and change control tracking
summary) are maintained in the project files (e.g., team collaboration site)

Communication of the approved changes is an important element of effective change control:

All core team members and key stakeholders are aware of the approved change, and the impact
of the change on the project baseline

Team members are on-board with adjustments to their assignments, based upon the
implementation of the approved change

Follow-up

The final step in the change control process is to perform follow-up on the implementation of the change:

Verify that the action items identified to implement the change (documented on the project impact
report) have been completed.

Based upon implementation of the follow-up actions, re-assess the impact of the change and
adjust the impact estimates (if required).

Update the status of the change (on the change control summary log) to reflect that it has been
fully implemented (and closed).

Change Control Best Practices

Be proactive. The cost of implementing change increases later in the project/ product lifecycle. Utilize
key metrics to monitor trends and identify potential changes.
The level of control and rigor around analyzing and approving changes should be appropriately
sized to both the organization and the project.

Project size (number activities, cost budget, number of resources), complexity (number and types
of dependencies), and risk profile (number and distribution across project activities of high priority
risks) are evaluated to adapt the change control processes to the project.

If changes often have very different impacts (e.g. much higher cost or schedule impacts) when
they are implemented, maybe there is not enough rigor involved with the change analysis process.

Projects that place more importance on schedules and/ or cost constraints tend to require more
control around analysis and approval processes.

Another consideration associated with change control processes is the visibility / strategic
importance associated with the project

Provide visibility of the change request throughout the change control process to ensure that
everyone involved with the project can easily find out the current status of any changes in the process, as
well as the reasons for approving or rejecting specific changes.
Ensuring that the change is implemented appropriately is critical because all of the effort that goes
into analyzing and making decisions does not matter if the change is not actually implemented fully and
correctly.

There should be follow-up to confirm the implementation steps have been completed.

Actual results should be captured to the planned impact of the change