Sections of this topic
A few weeks ago I was assisting a project manager with a troubled project. We reviewed the documentation from the beginning, starting with the usual suspects: project charter, WBS, schedule. They all seemed fairly straightforward and understandable. Once we got to his status reporting though, confusion started. This project’s status reports were spreadsheets about 10 pages long. Every week the team was only able to discuss only about 3 pages’ worth of information, and they were mostly risks.
“Why is this so long, what’s in it?” I asked him. He answered that it was his RAID Log, which he used to run Status Meetings. He wanted to be certain not to miss anything, so he was careful to include every item related to the project and classify it as R (risk); A (action); I (issue) or D (dependency) in this giant spreadsheet. As the first section was ‘Risks’ they were certainly addressed. So most of the discussion in his weekly status meeting was about events that had not even happened.
To be sure, used appropriately, a ‘RAID’ log is a great tool to help Project Managers keep projects on track. It lists, in one easily accessible place, almost any present or future turn of events that could impact their project. A few difficulties can arise though, which diminish the usefulness of a RAID log.
Frequency
In an average project, risks may not need review each week, but in a high-risk project the risk log may need to be reviewed more often even than action items. Each project has a different makeup, which should dictate the frequency with which each category in a RAID log needs to be considered.
Importance
Four categories (R,A,I,D) can generate many items. That is why in each category there should be a way to prioritize which the team, in fact, follows. This means that high priority issues or actions can be discussed in the status review meeting, whereas low priority items can be pursued by the project manager after the meeting, and as time permits.
Management Approach
Finally, the items in each of these categories require a different follow-up approach. For example: ‘Issues’ are problems. Small or large, they are discrepancies or disagreements which have taken place within the project and must be resolved. They may require conflict handling, negotiations or management involvement. On the other hand, ‘Risks’ are events which may or may not occur. Arriving at risk mitigation requires brainstorming alternative approaches, yes, but may never even have to be deployed.
For these reasons, think carefully about keeping one RAID log, or keeping separate Risk, Issue, Action and Dependency logs to be monitored at different times.
