Many project managers get to a point in their career where they are so trusted at achieving results that they are called in as “Cleaners” to sort things out when a project goes wrong. Think of Winston Wolf from Pulp Fiction, but with a PMP instead of a bow tie.
Having had this role myself and having seen many of my colleagues do the same, I can say from experience that there is absolutely no better tool to get a problem project under control than a RAID log. Nothing. I can also say that I have never had to rescue a project that had an up to date RAID log.
The RAID log story I share in the introduction and conclusion of this book is a perfect example how to use a RAID log to get a problem project under control. Here’s a brief summary of the process I use.
- Show me your RAID log. Once you land and get an understanding of who the stakeholders are and what the situation is, one of your first tactical questions should be, “Can you show me your RAID log?” First, it establishes that you know what you are doing. If the project is that bad off, odds are they don’t have one or even know what a RAID log is. Secondly, it puts responsibility back on the team – if they had a RAID log and had been managing to it, they wouldn’t need you right now.
- You will almost always find that there is no existing RAID log. If there is, it probably hasn’t been touched in months and is worthless, so don’t use it. Start a new log from scratch and don’t transfer anything over from the old one.
- Start with Issues, as identified by your stakeholders. The most important thing when getting your hands around a broken project is understanding all the current issues and their impacts. Take time to listen to each of the key stakeholders and understand each issue. Focus on being a good listener and let your stakeholders express all their frustrations. Drill down into the specific impacts of each issue, being careful to understand what feedback is driven by emotion and what is driven by the real impacts of the issue. We’re not in problem solving mode right now – you just need to capture all the issues and understand them before you can prioritize and act on them.
- Now, review the issues as your team sees them. Like with the stakeholders, give them a chance to talk through their frustrations, and be careful to separate fact from emotion, while giving them room to be angry or frustrated. They are probably pretty beat-up by the time the “Cleaner” got called in.
- Now, Risks. Things have gone wrong and you may be in the middle of a crisis. But however bad things are, they can always get worse. Get clarity on the things that can still go wrong and make the current situation worse, and get them into your Risk log.
- At this point, it’s time for some tough conversations around Decisions. The first decision in the project was to do the project, which was made with assumptions about how the project would be executed. If our project is in major trouble, you should have the sponsor revisit that initial decision and confirm if the project is still worth saving, or if they should make a decision to end the project. Ending a troubled project is never an easy decision, but it is the right decision much more often than it actually happens.
- Action Items. Throughout this process, you have undoubtedly had a lot of action items come up which you’ve tracked in your RAID log. But now, to rescue this project, you need to transcend mere to-do items. You will need to lay out an action plan, a “Go to Green” plan. Tactically, this can be part of your Action Item log or it may even warrant another new tab specifically to manage your “Go to Green” plan.
TIP: Use the process of building your RAID log as a structured way to perform discovery and engage the team and stakeholders in the discussion
Now, stay on top of all those items on a daily basis and your communication, and you will have the best possible chance of the best resolution.
Mercy killing
Sometimes, the best resolution is to not save a troubled project, but to kill it off. Killing a project that is doomed to fail is not a failure. Letting a doomed project continue to burn resources and cash is the real failure. Terminating a doomed project early enough can save millions in investment, uncounted hours of resource time, and free up the organization to focus on initiatives that can succeed. But even in this circumstance, don’t forget your RAID log. You will want to plan, manage, and document the decision to terminate the project in your Decision log, just as you would any other critical decision.
