June 6, 2024

Why ‘Change Requests’ are a critical part of your RAID log

RAID logs are a key part of an effective project lead’s toolkit. While they aren’t the project ‘plan’ themselves, RAID logs are the tool you use to keep the plan on track and course-correct when it starts to go off track. So, it makes sense to have Risks and Issues, Decisions, and Action items in our RAID logs. Maybe even Dependencies.   

But what’s the point of adding Change Requests? There’s no “C” in RAID! 


Taking the “Iron” out of the Iron Triangle 

When PMs baseline our projects, we are committing to a plan for what we are going to do and deliver with this project (Scope), how long it’s going to take (Schedule), and the money & resources (Budget) it will require to accomplish. These are the three main constraints of our project, which are often called the “Iron Triangle.” We then spend the remainder of project delivery trying to manage our project to these constraints. We say “manage,” but sometimes it can feel more like we are in a desperate battle to “defend” our three-sided fort.  



But the reality is, things change. The world around us changes, our organizations change, our teams change, and our projects change. And let’s always remember that nobody knows less about the project than the day it starts. So for our projects to stay relevant as our understanding of our project and the world it exists in changes, our projects need to change, too.   


Change is not bad. Uncontrolled change is. 

I’m as guilty as most PMs of falling into the trap that feeling like a change to our project is some kind of failure; that a change means we didn’t manage our triple constraints well enough.   

On the contrary, being able to proactively identify potential changes and manage them through an integrated change process is a healthy part of the project lifecycle. This kind of agility can help ensure our project stays aligned with our organization’s evolving needs and delivers relevant value, which is the real end-game. It does nobody any good to finish a project within the triple constraints only to find that our originally planned deliverables are no longer relevant or useful.  

To help us better manage change, it can be useful to have a tool that’s in front of us all the time, helping us stay mindful of the fact that change isn’t bad – it’s uncontrolled change that causes problems.  


Adding “CR” to RAID 

That’s why having a Change Request tab in your RAID log is so valuable. It’s a place where we can easily capture things in the project which feel like a change so we can document them and respond to them with intentionality. If RAID helps us keep our project on track, adding “CR” to our RAID log gives us the flexibility to maneuver that track when needed. 


Capturing potential changes can help us manage our projects in a number of ways:  

  1. Simply writing a request down in the Change Request log helps us, our teams and sponsors acknowledge that a request is, or may be, a change from what is in the plan, and that it wasn’t included in the current baseline plan. 
  2. By documenting a potential change as soon as it is identified, we can then follow a more structured approach of evaluating the change’s impact. That’s the “integrated” part of PMI’s “Integrated Change Management. This involves evaluating the change impacts before moving ahead with it, and gaining the proper approvals. Just because we capture a Change Request in the log doesn’t mean that it will be approved.  
  3. Logging a potential change “de-creeps” it. Scope Creep and Gold Plating are uncontrolled kinds of change that can sneak into our projects when we aren’t paying attention. By ensuring potential changes are logged and put through a process, we help ensure that any changes we make are done so with knowledge of their impacts to the project constraints. 
  4. Even if we don’t agree with the change or don’t think the change will be approved, the mere act of capturing a requested change from a sponsor or stakeholder pays respect to the request an can help build trust. 

This is why we added a new Change Request tab to RAIDLOG! Watch below to see how it works.



Tips on Managing Change

  1. Always remember – change isn’t bad. Uncontrolled change is.  
  2. As soon as you identify a potential change – log it in the Change Request log. Even if it isn’t approved yet, capture it and tag it as a potential change.  
  3. From a portfolio level, make sure you are reporting on open, approved, and rejected change requests, and the subsequent budgetary & schedule impacts to your portfolio as a whole. Also, track the causes of change to understand trends in your portfolio 
  4. If your Risk response, Issue resolution, or Decision outcome results in a Change, then log that as a related Change Request in RAIDLOG. Our tool lets you build networks of related items so you can understand potential follow-on effects. 

Together, we can run or rescue any project