RAID Log-An extension to Risk Management by Jolito Ortizo Padilla

Programme and projects are structured activities that seek to create effective change. A major part of structuring the work is in breaking it down into double chunks in a hierarchical plan that defines who does what and when, at a level of detail that can be effectively managed.

If all that was needed was to make a plan and then watch it all unfold as expected, then programme and project management would be an easy task. However, the best laid plans of mice and men often go astray as unexpected things happen. In fact, the reason programmes and projects often deliver late is not because they are badly planned. These can easily double the amount of time that is needed.

The RAID log is a simple extension to traditional risk management that supplements the programme, or project plan, to help manage the overall workload. RAID stands to risks, assumptions, issues and decisions. A simple way to manage the logging of these four factors is in  spreadsheet , with one tab being devoted to each element. The RAID log should be updated in the same way that the main plan is managed.

Risks
Risks are a classic and well known aspect of programme and project management. They are "bad things that could happen" and can lead to delays as well as cost-and quality related problems. Risks are managed by seeking mitigating actions that reduce the chance of either the risk happening or the impact of the risk should it occur. Contingency actions may also be prepared in case of this.

At the very least, a risk log should include a description of the risk, an analysis of it and a list of actions that need to take place. Risk logs often have significant supporting detail, such as before-and-after mitigation assessments, owners and traffic light indicators of seriousness.

Assumptions
When planning something new, many assumptions may be made and some of these may be significant enough perhaps, uncertain enough to be worth capturing. Captured assumptions may then be deliberately tested at the appropriate time as information is gained for this purpose.

The assumption log may include details of the assumption itself, the rationale for why this it   has been assumed and the action to be taken or otherwise that the assumption is or is not valid.

Issues
Issues are, in effect, risks that have happened. If your risk planning has been completed well, then they will not be a surprise and you will have the contingency actions on hand to handle them. Whether or not they are a surprise, issues are not usually found on the programme or project plan and so the issue log is the place where they are captured and tracked.

Issue logs may include various details about the issues. Key items will cover a description of the issue, the effect it is having (including how serious it is) and the actions that are required to contain and remove the issue.

Decisions
In projects and programmes, decisions are sometimes made that can have a significant effect, but with a limited understanding of the impact they may have, for example, in the extra work created. Decisions made along the way can also cause confusion , where people misunderstand them or simply do  not know they have been made.

The decision log should capture the decision, the rationale behind it, the name of whoever made the decision and any consequent work. This helps to ensure teh decision does not destabilize the plan and also gives a useful reference when someone asks, "Why did we decide that?"