Retired course

This course has been retired and is no longer supported.

About this lesson

A formal documented process for changing the project baseline.

Exercise files

Download this lesson’s related exercise files.

Project Change Exercise.docx
41.7 KB Project Change Exercise Solution.docx
41.7 KB

Quick reference

Project Change

Project change management is a formal documented process for changing the project baseline.  It often includes changes to the project boundaries.

When to use

The change process should be implemented in the following conditions:

  • Whenever there is a change to the project goals, objectives, or definition of deliverables
  • Whenever there is a change to the project boundary conditions including schedule and resource boundaries
  • Whenever there is a change to major project milestones and reporting points.
  • On projects managed with an adaptive project management methodology due to uncertainty.  I plan for a project change at each stage-gate decision point.

Instructions

For project change control to have any meaning; there must first be a project baseline.  Baselines apply to three aspects of projects:

  • There can be a baseline of the project initiation boundary conditions.  This baseline is normally embodied in the Project Charter.
  • There can be a baseline for the project plan.  This baseline should include planning elements for all three sides of the project management triangle – scope, schedule, and resources.  This baseline can be a high level plan or a very detailed plan.   
  • There can be a baseline for project deliverables that are subject to change during the lifecycle of the project.  These are usually documents such as drawings and specifications, contracts, and procedures.

The original baseline is approved by those with authority to do so.  This could be senior management, other stakeholders, project team members, or organizations whose responsibility is to manage baselines.  This is usually dictated by organizational procedures

When a change to a project baseline is requested, normally the project team assesses the impact of the change on the project plan and project benefits.  The change is presented to the appropriate approval authorities.  If the change is approved, the project documents and baselines are revised and the revised documents and baselines are distributed.  If the change is rejects, the requestor should be notified.

A major challenge with change management on projects is to keep everyone informed of the change and to update all appropriate documentation and communication.  On large complex projects, this is a major integration challenge and I have seen projects assign a full-time team member role to managing the coordination and implementation of change.

Definitions

Change: “A modification to any formally controlled deliverable, project management plan component or project document.”  PMBOK® Guide

Change Control: “A process whereby modifications to documents, deliverables, or baselines associated with the project are identified,  documented, approved or rejected.”  PMBOK® Guide

Configuration Management System: “A collection of procedures used to track project artifacts and monitor and control changes to those artifacts.”  PMBOK® Guide

These definitions are taken from the Glossary of the Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Sixth Edition, Project Management Institute, Inc., 2017.

Login to download
  • 00:04 Hi, I'm Ray Sheen.
  • 00:06 Let's talk about another vital element of project control and
  • 00:09 that is Project Change Management.
  • 00:11 The project management body of knowledge, the PMBOK guide,
  • 00:14 defines change control as a process whereby modifications to documents,
  • 00:19 deliverables or baselines associated with the project, are identified,
  • 00:23 documented, approved or rejected.
  • 00:26 Let me tell you what that means in practical terms.
  • 00:30 First, that means that we use the change management process to keep
  • 00:33 everyone honest.
  • 00:35 Through this process, we maintain the integrity of the project plan.
  • 00:38 Everyone knows what is in the project and what is not.
  • 00:41 Also, through this process, we help the project team.
  • 00:44 The change management process allows a core team member
  • 00:47 to say no to a request from a stakeholder.
  • 00:50 The core team member is not allowed to change the scope deliverable of a project
  • 00:54 without an approved change.
  • 00:56 A core team member does not have the authority to change it on their own.
  • 01:00 The request from the stakeholder must go through the change management process.
  • 01:04 The change management process is also an excellent communication tool for
  • 01:08 the time when the project is undergoing major changes.
  • 01:12 Instead of rumor being used to communicate the project goals and
  • 01:15 objectives, the change management project makes it clear what has been approved.
  • 01:20 Organizations work with a mature project management methodology,
  • 01:23 often keep project records for past projects, so
  • 01:26 the project teams can use these for reference when planning their own project.
  • 01:30 A change management system is a documented method for
  • 01:32 explaining what changed on a project and why.
  • 01:35 On some projects,
  • 01:36 it might not be the project team wanting to know what changes were made and why.
  • 01:40 If you're working at a regulated industry, your project may be subject to audit and
  • 01:44 a smooth working change management system will help to keep the records clean.
  • 01:49 Finally, a smoothly working change management system makes it clear to
  • 01:53 the project team what they should be doing and how success would be measured.
  • 01:57 I never want my team members to come walking in to work in the morning
  • 02:00 and asking.
  • 02:01 Do I do what the stakeholders are expecting on this project?
  • 02:04 Or should I do what's in the project plan?
  • 02:07 I always want those to be the same.
  • 02:09 So now, let's take a moment to explain what we mean by a change.
  • 02:13 The Project Management Body of Knowledge, the PMBOK guide,
  • 02:15 defines change as a modification to any formally controlled deliverable,
  • 02:20 project management plan component, or project document.
  • 02:23 The change management process is tightly coupled with project knowledge management
  • 02:28 process.
  • 02:29 Any controlled document or deliverable can only be modified by a formal change
  • 02:33 after it's been released to the system.
  • 02:36 This supplies to submissions to outside bodies,
  • 02:38 in addition to internal reports and analysis.
  • 02:41 This ensures the project knowledge is maintained and not tampered or lost.
  • 02:46 In addition, change applies to the project management baseline.
  • 02:49 The scope baseline of deliverables, the schedule baseline of milestones, and
  • 02:53 the resource baseline of total budget.
  • 02:55 Here, it's important for
  • 02:56 the project leader to have chosen wisely the level of detail in the baseline.
  • 03:00 Too much detail and
  • 03:02 every little work around and trade off requires a project change.
  • 03:05 But not enough detail and
  • 03:07 changes that are significant impacts to the project are not captured.
  • 03:11 One other category of documents that should be controlled for
  • 03:13 changes are external documents.
  • 03:16 These are reference in the project providing customer requirements or
  • 03:19 standards for compliance.
  • 03:21 When these are modified, a formal change needs to be processed to ensure that team
  • 03:25 and stakeholders understand the implications.
  • 03:28 Where do these change request come from?
  • 03:30 One source is external effects acting on the project.
  • 03:33 The customer changes the requirements document, or
  • 03:36 a problem on another project creates a problem for you.
  • 03:39 I had a project one time,
  • 03:40 where we had to implement a change on my project because another project
  • 03:44 accidentally blew up the laboratory where we were intending to do our testing.
  • 03:49 Some of the changes would be generated by project team members in order to do
  • 03:53 something that they believe will improve the overall project performance.
  • 03:57 I want to encourage these changes, of course,
  • 03:59 we need to validate the benefits but these are ones we like.
  • 04:02 This will include a change associated with implementing a risk contingency plan
  • 04:07 based upon a risk opportunity being triggered.
  • 04:10 Or it may include incorporating a lesson learned from another project to
  • 04:13 avoid a risk or to follow our best practice.
  • 04:16 But sometimes, the team wants to make a change because things went wrong.
  • 04:20 A major delay will force them to miss a scheduled boundary milestone.
  • 04:25 Or under-performance on an activity means that they need to repeat
  • 04:28 phase three of the project with cost and schedule implications.
  • 04:31 These are usually big problems, but there were little issues the core team would
  • 04:35 have implemented to work around, then project change would not be required.
  • 04:39 But they're usually big deals and they're often are viewed as a project failure.
  • 04:44 If your change is in this category,
  • 04:46 come to your change approval authorities with options and a recommendation.
  • 04:50 Don't come crying about the problem and drop it in their lap.
  • 04:54 So let's wrap up with a quick discussion about configuration management.
  • 04:58 The Project Management Body of Knowledge, the PMBOK guide, defines configuration
  • 05:01 management as a collection of procedures used to track project artifacts and
  • 05:07 monitoring control changes to these artifacts.
  • 05:09 The system is often used for
  • 05:11 controlling technical documentation such as deliverables.
  • 05:14 If your organization has one, you'll need to follow its procedures.
  • 05:18 In some organizations, the system works smoothly and keeps things under control.
  • 05:22 But in some organizations, it's a bottle-neck.
  • 05:25 They will delay a change by weeks or even months due to bureaucracy.
  • 05:28 The elements of a good configuration management system are first,
  • 05:33 that it is clear what is the item that is being controlled.
  • 05:36 Second, that the changes are recorded and the current status of each change,
  • 05:40 whether it's implemented, pending, or rejected is clear.
  • 05:44 And third, the records keeping mechanism of the system are adequate to allow for
  • 05:48 audits of the process.
  • 05:52 While the specifics of change management are always unique to the organization and
  • 05:56 the methodology used for managing projects, the best practice is to
  • 06:00 use a formal, structured process for controlling project baselines.

Lesson notes are only available for subscribers.

PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.

Gift this course