Locked lesson.

Upgrade

About this lesson

A formal documented modification to the project baseline, boundaries, or an artifact.

Exercise files

Download this lesson’s related exercise files.

Project Change Exercise.docx
60.1 KB Project Change Exercise Solution.docx
60 KB

Quick reference

Project Change

A formal documented modification to the project baseline, boundaries, or an artifact.

When to use

The change process should be implemented in the following conditions:
 

  • Whenever external forces request a change to the project goals, milestones, objectives, or deliverables
  • Whenever the project team recommends a change to incorporate a best practice, take advantage of an opportunity, or respond to a risk trigger.
  • Whenever the project team or stakeholders recommend a change in order to recover from an unplanned difficulty.

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 the 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 or project requirements.

When a change to a project baseline or baseline document 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 are revised and the revised documents are distributed.  If the change is rejected, 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. A configuration management system is often used to communicate the status of project changes.

Definitions

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

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

Configuration Management System:  “A collection of procedures used to track project artifacts and monitor and control changes to these 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) – Seventh Edition, Project Management Institute, Inc., 2021.

Hints & tips

  • If your change control system is slow, controlled documents should be at a very high level with no detail.  Otherwise, detailed changes will clog the change management system and you will lose control of the baselines.
  • Leverage existing systems to as great a degree as possible to minimize duplication of overhead.
Login to download
  • 00:04 Hi, I'm Ray Sheen.
  • 00:05 Let's talk about another vital element of project control, and
  • 00:08 that is project change management.
  • 00:10 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:24 documented, approved or rejected.
  • 00:26 Let me tell you what that means in practical terms.
  • 00:29 First, that means that we use the change management process to keep everyone
  • 00:34 honest.
  • 00:34 Throughout this process we maintain the integrity of the project plan.
  • 00:38 Everyone knows what is in the project and what is not.
  • 00:42 Also, through this process, we help the project team.
  • 00:45 The change management process allows core team members to say no to
  • 00:49 requests from stakeholders.
  • 00:51 The core team member is not allowed to change the scope or
  • 00:53 deliverables of a project without an approved change.
  • 00:56 A core team member does not have the authority.
  • 00:59 The requests from the stakeholder must go through the process.
  • 01:02 The change management process is also an excellent communication tool for
  • 01:06 the times when the project is undergoing major changes.
  • 01:09 Instead of rumors being used to communicate changes to goals or
  • 01:13 objectives, the change management process makes it clear what has been approved.
  • 01:17 Organizations with a mature project management methodology often keep project
  • 01:22 records from past projects, so that project teams can use them for
  • 01:25 reference when planning their own project.
  • 01:28 A change management system is a documented method for
  • 01:31 explaining what changed and why.
  • 01:33 On some projects,
  • 01:34 it may not be the project teams wanting to know what changes were made and why.
  • 01:38 If you're in a regulated industry, your project may be subject to audit.
  • 01:41 And a smoothly working change management system will help to keep
  • 01:45 the records clean.
  • 01:47 Finally, a smoothly working change management system makes it clear to
  • 01:50 the project team what they should be doing, and how success will be measured.
  • 01:54 I never want my project team members coming to work in the morning and asking,
  • 01:58 well, do I do what's in the project plan, or do I do what's actually expected for
  • 02:02 us to do on this project?
  • 02:03 I always want those to be the same.
  • 02:07 So now let's take a moment to explain what we mean by a change.
  • 02:11 The Project Management Body of Knowledge, the PMBOK Guide,
  • 02:14 defines project change as a modification to any formally controlled deliverable,
  • 02:18 project management planning component, or project document.
  • 02:22 The change management process is tightly coupled with the overall project
  • 02:26 management.
  • 02:27 Any control document that's been delivered can only be modified by a formal change
  • 02:31 after it has been released into the system.
  • 02:34 And that applies to documents that were delivered to outside bodies,
  • 02:38 in addition to internal reports and analyses.
  • 02:40 This ensures that the project deliverables are maintained, and not tampered or lost.
  • 02:46 In addition changes apply to the project management baselines.
  • 02:50 The scope baseline of deliverables, the schedule baseline or milestones, and
  • 02:54 the resource baseline or total budget.
  • 02:56 Here's important for
  • 02:58 the project leader to have chosen wisely the level of detail in the baselines.
  • 03:02 Too much detail and every little workaround and
  • 03:05 trade off becomes a project change.
  • 03:07 But not enough detail, and
  • 03:08 changes that significantly impact aspects of the project are not captured.
  • 03:13 One other category of documents that should be controlled for
  • 03:16 changes are external documents that are referenced within the project to provide
  • 03:20 customer requirements or standards for compliance.
  • 03:23 When these are modified, a formal change needs to be processed to ensure
  • 03:28 that the team and stakeholders understand the implications.
  • 03:32 Where did the change requests come from?
  • 03:35 One source is external effects upon the project.
  • 03:37 The customer changes the requirements document.
  • 03:40 Or a problem on another project creates a problem for your project.
  • 03:44 I had a project one time where I had to process a change to our baseline plan.
  • 03:48 Because a different project blew up the laboratory in which we were
  • 03:53 planning to do our testing.
  • 03:55 Some of the changes may be generated by the project team members in order to do
  • 03:59 something that they believe will improve the overall project performance.
  • 04:03 I want to encourage these changes.
  • 04:05 Of course, we need to validate the benefit.
  • 04:08 But these are the changes we like.
  • 04:10 This would include changes associated with implementing a risk contingency plan,
  • 04:14 based upon a risk being triggered.
  • 04:17 We proactively implement the change, rather than waiting for an issue to arise.
  • 04:22 It may include incorporating lessons learned from another project to avoid
  • 04:26 risks or follow a best practice.
  • 04:29 But sometimes the team wants to make a change because things went wrong.
  • 04:34 Major delay forces them to miss a schedule boundary milestone, or
  • 04:38 underperform on an activity.
  • 04:40 And that means that they need to repeat phase three of the project with cost and
  • 04:44 schedule implications.
  • 04:46 These are usually big problems.
  • 04:48 If they were little issues,
  • 04:49 the core team would have been able to implement it a workaround.
  • 04:52 And project change would not be required.
  • 04:55 But they are usually big deals, and they often are viewed as a project failure.
  • 05:00 If your change is in this category,
  • 05:01 come to your change approval authorities with options and a recommendation.
  • 05:06 Don't come crying about the problem and drop it in their lap.
  • 05:10 So let's wrap this up with a quick discussion about configuration management.
  • 05:14 The Project Management Body of Knowledge, the PMBOK Guide, defines configuration
  • 05:19 management as a collection of procedures used to track project artifacts and
  • 05:23 monitor and control changes to these artifacts.
  • 05:27 The system is often used for controlling technical documents and deliverables.
  • 05:31 If your organization has one, you will need to follow its procedures.
  • 05:35 In some organizations the system works smoothly and keeps things under control.
  • 05:39 In some organizations it's a bottleneck that will delay a change by weeks,
  • 05:44 or potentially even months, due to bureaucracy.
  • 05:48 The elements of good configuration management system are, first,
  • 05:51 that it is clear what the item is that is being controlled.
  • 05:55 Second, that all changes are recorded, and the current status of each change,
  • 05:59 whether it's implemented, pending, or rejected is clear.
  • 06:03 And third, the records keeping mechanism of the systems are adequate to allow for
  • 06:09 auditing of the process.
  • 06:11 While the specifics of change management are always unique to the organization and
  • 06:16 the methodology used for managing projects, the best practice is to use
  • 06:21 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