Monday, 3 June 2013

How to use a RAID log

Most of the projects I work on use some form of RAID log.

RAID stands for Risks, Actions, Issues and Decisions. The RAID log is a simple tool to keep track of all of these, which can be very useful in regular project meetings as well as for audit purposes.

  • Risks represent those things that could go wrong, either in the execution of the project (project risks) or in the underlying business being changed or created (business risks). For each risk we normally estimate the probability and impact of it happening, and also any actions we are taking to mitigate against it. We also normally assign an owner, who is responsible for monitoring and mitigating against the risks, and set a future review date on which it will next be assessed.
  • Actions represent all the things that need to be done. These are typically actions that arise during project meetings and don't necessarily include all of the actions already on the project plan. Each action should have an owner, a due date, and eventually a date on which the action was completed. Each project meeting should review actions, to mark off those completed and review progress against those not yet completed.
  • Issues are known problems within the project or the business being changed or created. Many people think of issues are risks which have already happened. Issues are typically notified up the management chain, for example to a project steering committee or business executive team. For each issue, you should identify what you intend to do about it, who should do this, and when it should next be reviewed. Issues should be marked as resolved once the problem is sorted out or the project moves past or around the obstacle.
  • Decisions are simply a list of decisions made in a project. They are simply listed as a record of decisions made. You can also record when the decision was made, and by whom it was made.

The secret to a good RAID log is to record the right risks, issues and decisions at the right level of detail. Too many and in too much detail simply creates unnecessary bureaucracy. Too few in too little details does not provide a sufficient record of the state and progress of the business. For example, I have often seen risk logs populated with boilerplate risks: these are generic project risks, such as 'we may not get sufficient executive sponsorship' which don't really add any insight to the project. (If you genuinely think that is a risk, you be better of identifying the underlying reasons which might cause this, and then expressing the risk in those terms.)

RAID logs are an excellent governance mechanism, and worth keeping even if for no other reason than so that you have all of the information to hand if the internal audit department or some other stakeholder decides to audit your project. But don't forget that projects are fundamentally about doing things. So identifying risks and issues without also identifying actions to mitigate them, and making decisions to resolve them will not get you very far.

Resources: You can create and manage your own RAID logs with your team in our secure and collaborative online tool at StratNavApp.com - simply register and select "Control".