In my first blog post, “Don’t Bring Me Problems!”, I addressed the issue of how some managers deal with whiners. Rather than shutting down communication, I recommended the maintenance of a RAID (Risks Assumptions Issues Dependencies) log as part of the solution. While I understand that RAID logs may not be an exciting leading edge project management subject, I do find it to be critical to healthy project management. Therefore, I would like to delve a bit more deeply into this subject.

Whether you are using a waterfall or agile approach, the RAID log enables managers to bring into focus project matters that should be at the stakeholders’ top of mind. In addition, it documents assumptions and decisions that are made during the execution process. To understand this a bit better, let’s look at a RAID log.

Typically, a RAID log is maintained in a spreadsheet with a worksheet for each of the four subject areas; risk, assumptions, issues, and dependencies. The following defines each of these subject areas;

• Risk – A risk is a problem that could possibly This is forward looking where the team anticipates issues. We want to focus on risks that are relatively likely to occur and will have a noticeable impact on the project. Risks will be prioritized by two parameters; severity and probability of occurrence.
• Assumptions – Assumptions document something which is accepted as true possibly without proof. This communicates to the stakeholders any expectations of the team, reducing the likelihood of any miscommunications or misunderstanding. Note that there are general project assumptions that are made during the initiation of the project; the availability of stakeholders, for example. It is best to document these assumptions elsewhere such as in the project charter. The assumptions that should be the focus here, are those things which have been uncovered during the execution phase, or a sprint.
• Issues – Issue is a polite word for problem. Here we list any current problems with which the project is dealing. In a perfect world, an issue has been identified as a risk prior to its occurrence. In such instances, the team has anticipated the issue defining mitigation strategies.
• Decisions – These are the decisions that are made during the implementation. It is helpful to record in addition to a description of the decision, the basis for why it was made and any possible contingencies related to the decision.

The RAID log should be available for review by any of the project stakeholders, but can be edited only by the project manager who is the owner of the document. It is also important to maintain version control of the log. I have used several different methods such as embedding the date of the revision in the name of the log file, i.e. RAID13MAR17.xlsx. Another method, that is much easier to maintain, is to simply have SharePoint do version control for you.

The frequency that the RAID log is reviewed is dependent on the project and the management approach. I have seen project managers meet on a daily basis to review and update the log with tech leads. These meetings, surprisingly, were held to a half hour or less. Once a week, typically prior to the weekly status meeting, the top priority items were reviewed with the stakeholders. I have worked other projects where I would review the RAID log once a week with my sponsor then include the most critical items as part of the weekly status report. In either case, during the status meeting the high priority items in each of the subject areas are brought to the attention of the stakeholders.

There are two guiding principles concerning entries into the RAID log that may seem a bit contradictory. First, we need to be a bit judicious in what is entered into the log. Listing every possible risk, most of which have a low possibility of occurring, diminishes the ability of the RAID log to focus attention on critical issues. At the same time, we need to balance this concern with making sure that every voice on the team is heard. During a RAID review, individuals should be encouraged to raise topics for entry into the log. Items that have either a low probability of occurring or minor impact on the project could be delegated to team members who address the items in subgroups offline.

I strongly feel that the RAID log is a powerful communication vehicle for project managers. I will go into more detail on each of the subject areas in future posts.