This is the first of a five-part ‘short story’ series regarding the RAID log.
Many folks hear RAID and they run for the hills—some because they believe it is a real raid, and others because they think a RAID log is antiquated, outdated, old fashioned and totally not hip nor Agile/Lean. In fact, RAID is ‘raise the roof’ awesome.
Program/project managers’ key responsibility is ensuring the right people have the right information at the right time to ensure appropriate decisions are made. Think of Macgyver and always having or making the right tool in every crisis.
Program managers are like the Internet, they get requests all day from executives, stakeholders, team members, product owners, finance, communication teams and multiple business individuals. Balancing the output of answers, they are taking in information throughout the day: key product, business and technical decisions; updates to mitigating actions for risks; actions that have been completed; dependencies that are going to be late; pivot points executed; risks realized into issues and tracking against the overall roadmap.
Yeah, no way to deny—that is a massive amount of data to track, validate, analyze and make decision upon—especially in a timely fashion. How can a mere mortal do this? The answer’s simple: RAID. With RAID you get:
Risks: Identify risk, root cause, trigger date, risk response plan, risk mitigating activities, rating.
Actions: Those items you are tracking which must be completed usually by the core team.
Issues: Risks that have been realized and now tracking as issue: owner, eta solution, root, daily, hourly updates, lesson learned.
Dependencies: matrix identifying cross stream dependencies, due dates, status, owners, recipients.
Actually, in some cases you might see the 'D' described as 'Decisions'. There's certainly value in having a log of all technical and non-technical decisions identifying decision makers, date, venue, so sometimes we include that in our Dependencies category too.
Other components often included:
Meet the RAID log
“Well, if it is not in her RAID log, I am 99.99% sure it is not happening.” So said one exec to the rest of the executive steering committee. That is the power of a well-maintained RAID log. It brings confidence to your key stakeholders and executives.Many folks hear RAID and they run for the hills—some because they believe it is a real raid, and others because they think a RAID log is antiquated, outdated, old fashioned and totally not hip nor Agile/Lean. In fact, RAID is ‘raise the roof’ awesome.
RAID logs are one of the key tools that a program or project manager uses to keep themselves sane.
They are not meant to replace any of the agile and lean tools, rather they allow the program manager to be effective, transparent, and efficient.Program/project managers’ key responsibility is ensuring the right people have the right information at the right time to ensure appropriate decisions are made. Think of Macgyver and always having or making the right tool in every crisis.
Program managers are like the Internet, they get requests all day from executives, stakeholders, team members, product owners, finance, communication teams and multiple business individuals. Balancing the output of answers, they are taking in information throughout the day: key product, business and technical decisions; updates to mitigating actions for risks; actions that have been completed; dependencies that are going to be late; pivot points executed; risks realized into issues and tracking against the overall roadmap.
Yeah, no way to deny—that is a massive amount of data to track, validate, analyze and make decision upon—especially in a timely fashion. How can a mere mortal do this? The answer’s simple: RAID. With RAID you get:
- Knowledge. RAID builds confidence in stakeholders because you have the information 24/7—decisions need to be made quickly often, you, the Program Manager, can provide the data and options at a moment’s notice.
- Efficiency. You don’t need to schedule multiple meetings and workshops to come up with answers for information regarding ‘where are we’, when is something is going to be done, how far off our tolerance are we, what percent success criteria is expected.
- Trust. Executives rely on the program manager to have accurate information in a timely fashion. The RAID log can also point to whom you need to contact for deeper details.
- Success. Increases the probability of success dramatically. There are no dropped balls, missed dependencies, nor unmanaged risks. You will still have risks realized, but it won’t be a surprise and team members will know the risk response plan ahead of time.
What is RAID?
The RAID log is a spreadsheet with multiple tabs. It contains:Risks: Identify risk, root cause, trigger date, risk response plan, risk mitigating activities, rating.
Actions: Those items you are tracking which must be completed usually by the core team.
Issues: Risks that have been realized and now tracking as issue: owner, eta solution, root, daily, hourly updates, lesson learned.
Dependencies: matrix identifying cross stream dependencies, due dates, status, owners, recipients.
Actually, in some cases you might see the 'D' described as 'Decisions'. There's certainly value in having a log of all technical and non-technical decisions identifying decision makers, date, venue, so sometimes we include that in our Dependencies category too.
Other components often included:
- Team (listing of team members and concise stakeholder analysis of each).
- Communication plan matrix.
- Meeting cadence.
- Success criteria, gate criteria, experiment results.
- Go no-go checklist.
- Release checklist.
