PM Foundations – The Change Control Process

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 10-12% 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 customer’s 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
Advertisements

About Steve Hart
Practice Manager responsible for project leadership & delivery services for the Cardinal Solutions Group in the RTP area. I am a PMP with 25 years of project management and technical leadership roles, have developed an extensive practical knowledge that spans a wide variety of industries, and project delivery approaches. As a practicing PMP, I am a member of the North Carolina PMI chapter. I am an avid sports fan, particularly the Miami RedHawks, Cleveland Indians, Cleveland Browns, and most recently the NC State Wolfpack.

3 Responses to PM Foundations – The Change Control Process

  1. Pingback: Change « Better learning & teaching projects

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s