This episode, we talk about an old stand-by in the PM world, the RAID Log. RAID Logs (Risks, Actions, Issues and Decisions) are an essential tool that every PM needs in their toolbox. Heck, you can effectively run an entire project from one!

If you have never heard of a RAID log before, you need to check in? whether you have a small project or a major program, RAID logs can save your bacon. And if you’ve used them in the past, tune in for some tips to be super effective with them.

FREE RAID LOG!

Why not download a copy of our free RAID log? Go get it at https://pmhappyhour.com/raidlog

JOIN TODAY, AND GET IMMEDIATE ACCESS TO TAKE THE QUIZ!

Members get unlimited access to take the quizzes for our podcasts. Not only, that, but you also get a certificate, we’ll upload your PDU’s to PMI, and you get lots of other great benefits – click here for details on becoming a member.  

JOIN US FOR HAPPY HOUR!

Come by and say “hey!” in our PM Happy Hour FB Page at https://www.facebook.com/pmhappyhour/

Show Notes

RAID Basics [7:57]

For many project managers, a RAID log – RAID stands for (Risks, Actions, Issues, Decisions) is a familiar tool. For others, it may be new.

RAID log is a tactical management tool that is updated and monitored frequently, often on a daily basis. It is used to be on top of what is currently going on with your project. However, it is not a replacement for planning tools, such as project schedules or WBS. Instead, a RAID log is a means for managing those plans, and making sure nothing falls through the cracks.

In its simplest form, A RAID log is typically a Microsoft Excel workbook, with a tab each for Risks, Actions, Issues, and Decisions.

The simplicity, portability, and efficacy of a basic RAID log make it a valuable tool for all project managers to keep in their arsenal. It is the ultimate fall-back tool.

Let’s start the deep dive!

R – Risks [10:20]

The first RAID Log tab is the Risk tab. This is a basic risk log, listing all your identified risks, scoring each for likelihood and probable impact. Each risk should have a running log of mitigating actions. There are also columns for risk owner, status, and any trigger dates that may be pertinent.

We use the Risk log to capture things that will let you say “I told you so” in Project Manager speak. Risks should be the things you hear your team say and your project management gut goes “oh no, red flag”.

In true Stephen Covey fashion, we want to begin ‘with the end in mind’ when it comes to risks.

If this risk comes to fruition as an issue, you want to have this documentation in your back pocket that lets you say “Risk 23: resource constraints over the holidays make impact delivery – has come to fruition”

While it is nice to have a detailed list of all your risks, it is useless unless you do something about them.

In tracking risks, we suggest keeping a running log in the Mitigation column. This includes a date and comment for each update, including each time the risk is escalated or communicated, and to whom. We also find it easier to put the latest comment on the top.

But please note that Risks differ from Issues. If you read the PMBOK – you better be too! A RISK is something that hasn’t happened yet while an issue is a realized risk (or an unforeseen risk you need to action on).

A – Action (Items) [14:12]

However detailed your project schedule or WBS, you will always have unplanned action items come up – follow up items, actions items from meetings, etc. So, you’ll need a ‘task bucket’ of some kind to capture and track these items.

There are many tools for logging and tracking tasks: Outlook tasks, SharePoint, OneNote, etc. These have nice features, but having tasks in locations different than your Risks can be cumbersome and inefficient.

Keep your Action log simple. Task ID, Name, running update, owner, date created and status are probably all you need. You may also want to use Excel’s auto-filters to easily hide completed items, or filter for a particular person’s task for follow-up.

It is IMPORTANT to have ownership of actions accounted for somewhere, and it’s in no better place than your capable PM hands.

If it’s not written down, it will be hard to hold someone accountable. Also, if you are running a daily stand up in some way on a particular track, nothing’s more motivating than a public shame session of continually not delivering on an action.

Often we have action items that have multiple steps. When you have a lot going on like a big list of Action items, it can be beneficial to have a separate column entitled, “Next Action,” which describes the next physical action that needs to take place for that item.

If this approach is new to you, we recommend that you get a copy of “Getting Things Done” by David Allen. It’s a great book.

I – Issues [17:11]

Risk is something that could go wrong while an Issue is something that has gone wrong.

Wrong, meaning a deviation from the approved scope, baselined schedule, approved budget, or quality standards.

Many PM’s prefer to keep their Issues on the same list as their Risks. This is a matter of preference. We like to keep them separate. Because at the end of your project (and likely well before then), you will need to explain any and all deviations from plan, and explain their cause and impact.

This may be needed to support project change orders, communicate better with project sponsors, etc. While you could sort or filter these out of a combined Risk / Issue list, we find that keeping a separate list keeps them clear.

D – Decisions [19:19]

The Decision log is best filled out in the forum where the decision is made. If possible, put the log on a projector or Webex or LiveMeeting session, and type out the decision, justification, expected impact and parties involved.

Decisions are taken much more seriously if the ‘deciders’ watch you type it in the project record- the Decision log- and put their names down next to it. This can help enforce decision commitment.

Here are five scenarios where it’s critical to document decisions:

1. Any time “Options” are involved

When you are developing your plans for the project, there are always options! You could build your product in the cloud, or in your datacenter, use in-house staff, hire contractors, or hire high dollar expertise. 

For us, the most important time to document decisions is when you decide on a path from a variety of choices. And we would document it in this format:

Decision: Project will use internal resources rather than a source from partner A.

Justification: Internal resources currently at 50% capacity and have allocation for project. Project should complete within expected schedule with current resources.

Impact: Funding for external resources not included in budget

Deciders: Project Sponsor Darth Vadar

2. Decisions which are not yet made

Sometimes we need to flag decisions which are not yet made so we can be reminded that we need to go back to them. This may include decisions on a design or on how to handle an issue.

Tracking them will allow you to escalate them if needed or manage them upward so you can get the support you need to drive change in your project.

3. Anytime something is prioritized up, down, or descoped

Sometimes you got five things to get done in scope and somebody decided to set it aside. This needs to be part of your integrated change control, and it must be documented on your RAID log.

4. Decisions on pushing non-critical path dates

When something has float and we made a conscious choice to push out the schedule, this has to be called out in a decision log. The tasks in question shouldn’t push out the overall project scope, but you never know when a risk could become an issue. Having changes like this documented allow us to not squabble about why we let something slide, when in reality, it was a choice to push the tasks 2 months into the future, because we had 5 months of float.

5. Formalizing the decision

To make the decision real, we need to document it on the RAID log with the name of who made the decision. Putting the decision into writing with the name of the person who called out for it gives them a bigger accountability and ownership.

Other Tabs [29:24]

We can throw in additional letters to RAID depending on the nature of the project. In some instances, we put another D (so that’s RAIDD) for Dependency tab. This works when your project or program has a lot of external dependencies (like with a client, or other projects, or partners) and you need to keep those under control. You could (and maybe should) have these on your RISKs tab, or you could just add these to your Action tab, but sometimes it’s nice to just have one place where you have all your dependencies.

It’s also nice to create a tab for contact lists with everybody’s name on the project. Additionally, you can have an integrated change request tab or something for the conversion of timezone in case you’re working on projects overseas.

Tips and Tricks

• Keep it simple. Once you get comfortable with your RAID Log, it is tempting to progressively add to it – charts, macros, buttons, etc. There is nothing wrong with this, but we encourage you to keep it simple. This is a tool that is useful because of its simplicity, not an avenue to impress your friends and colleagues with your Excel skills.
• Keep ownership. No matter how big the project, own it. Owning the RAID log keeps your head in the game.
• Keep it current. Take it seriously if you want others to take it seriously. The RAID log starts to lose value if you don’t keep it current. And if you aren’t keeping current on your project’s risks, action items, issues, and decisions – what are you doing?

• Make it accessible. Whether it is stored on a file share, collaboration portal like SharePoint, Google Docs or Skynet, or if you just email it out to the team regularly, use it as a communication tool for the team.
• Use it in Programs to control Projects or Workstreams. This ensures consistent management of the workstreams and will allow you to communicate and document more efficiently. It’s also nice to be able to ask your PM’s to walk their RAID log as an ad-hoc or recurring checkpoint.

Key Probing Questions:

• Do we feel like this is a decision we’re making?
• Have I identified every possible way this project can go wrong and have I put it in the RAID log?
• You should not have a question on where things are – they should be on your RAID log.

You may be in trouble if:

• You don’t have a RAID log at all! Get one! We’ll include a template on the site. Go now!
• You’re not using your RAID log on a daily basis. This can keep you focused on all the loose ends, and let you assure you’re tracking the risks and issues.
• Your decisions log is light. There ARE important decisions being made all the times, and as stewards of the project, it’s our job to help every team member (and sponsor) understand that these decisions have weight.
• You aren’t making a big deal of it and putting people’s names by the decisions.