Hello and welcome to a Parallel Project Training podcast. This episode aligns with the APM PMQ syllabus for exams starting in September 2024. My name is Ruth Phillips, and I’m here with my colleague and senior project trainer, Lisa Regan, to discuss change control. Welcome to the podcast.
Happy to talk about change. It’s a topic project managers should be fairly comfortable with, although it must be managed carefully in our projects, don’t you think?
Absolutely. The only constant is change, as they say! Let’s take a look at the syllabus. The learning objective is to understand change control as the ability to manage variations and change requests in a structured way. Control is key because, while change is inevitable, managing it within a project is essential. There are five learning outcomes for this syllabus topic, all focused on the change control process. We’ll cover each one as we go through the stages of a typical change control process.
The first outcome is understanding the purpose and importance of each stage in the change control process. Could you give a high-level overview of what a change control process looks like? Then we’ll dive into each stage, starting from the top, when someone makes a change request.
Certainly. First, someone submits a change request. We’ll cover what that involves, and then the project manager conducts an initial evaluation to see if the change is even worth considering. At this point, you might decide it’s not. If it is, then we move on to a detailed evaluation, looking at what might be impacted. This often involves consulting subject matter experts.
After gathering all this information, you consult the sponsor and make a recommendation—approving, rejecting, or deferring the change. If it’s approved, you update your plans accordingly, ensuring everything is configured to support the change. Then you implement it and communicate the update to everyone involved.
Great! That’s the overall process. Now, let’s look at each step in detail. The first step is requesting a change, and one of our learning outcomes focuses on understanding what should be captured in a change request. Can anyone on the project request a change?
I think so; there should be a formal way to capture change requests, which often filters out requests that aren’t fully thought through. Requiring a completed form for each request means people have to consider why the change is needed and outline potential impacts. They need to record details like the reason, areas likely to be affected, the date, and a description of the change.
Agreed. There’s a balance in making the form user-friendly so that people comply but detailed enough to ensure they’ve considered the implications. How often have we heard “Could you just…?” on projects? This step helps prevent those casual, unchecked requests that lead to scope creep.
Exactly. The next step is the initial evaluation. Here, we consider if the change is worth pursuing. Sometimes, you can see straight away that it’s too costly, risky, or time-consuming. It’s a necessary filter, and if we reject it, we need to communicate the reasons to the person who requested it.
Yes, communicating that decision is important. If we don’t, they might assume the change is going ahead or try to circumvent the project manager. This is also the stage where we might identify duplicate requests.
Right. Now, if the change passes the initial evaluation, we conduct a detailed evaluation. Here, we assess the change’s broader implications, consulting subject matter experts as needed. We look at how the change affects the project’s time, cost, quality, risks, benefits, and stakeholders.
Exactly. And the timing of the request matters. If it’s early in the project, the impact might be minimal, but late-stage changes can be very disruptive. After assessing everything, we make a recommendation, either to accept, reject, or defer the change. Rejections should be communicated as we discussed, and sometimes we might defer a change to the next phase or project cycle.
Yes, and if we decide to accept the change, we consider how to justify it, keeping time, cost, and quality impacts in mind. It’s like a mini business case for the change. Sometimes, changes are actually positive and can improve efficiency or reduce risks, which we need to factor into our evaluation.
I agree; sometimes changes enhance the project outcome. Next, we have to update our plans and schedules to reflect and communicate the change. This step ensures team members and stakeholders have the latest information, which is crucial for maintaining confidence and keeping everything on track.
Precisely. This prevents chaos and maintains stakeholders’ confidence in the project. Finally, the implementation step is simple: we carry out the updated plan, ensuring that all relevant team members and stakeholders are informed.
Great, and lastly, the syllabus asks us to understand how the change control process might differ for linear and iterative lifecycles. With a linear lifecycle, the scope is agreed upon upfront, so change control is a formal process to manage deviations. In an iterative lifecycle, change is inherent, as each iteration incorporates feedback and new insights. This flexibility allows changes to be absorbed as part of the process.
Yes, in an iterative lifecycle, change is expected, not restricted. The steps we’ve outlined may still happen, but they’re embedded in the ways of working, making formal change control less necessary.
That’s a good perspective. In iterative lifecycles, changes aren’t seen as deviations but rather as integral to the process of reaching the best solution. It’s a different way of controlling change—by embracing it.
Absolutely. Change is seen as an opportunity for improvement, not a disruption.
Well, that’s been a fantastic discussion on change control. Thanks so much for joining me.
Thank you. Bye-bye!
