RAID is an acronym for Risks, Assumptions, Issues, and Decisions. Some use the «D» for dependencies instead of decisions, and some use the «A» for actions instead of assumptions. I personally track dependencies on my assumption list (because that is what dependencies are) and I have no need for a separate action list since I track actions in a separate column of each of the other lists.
Although I speak from four lists you can use one tool to maintain them and filter on type when necessary. This is actually advisable since items will move from one list to another on a regular basis, but we will come back to that later.
Often the terms risks, assumptions, and issues cause confusion. Their definitions are similar but applied differently in different context or areas of work.
Risks
Risks are made up of two parts: the probability of something going wrong, and the negative consequences if it does, often called impact. Caution, risk is not the same as uncertainty. Risk and uncertainty are different terms, but most people think they are the same and ignore them. Managing risk is easier because you can identify risks and develop a response plan in advance based on your past experience. However, managing uncertainty is very difficult as previous information is not available, too many parameters are involved, and you cannot predict the outcome. See Risk Management is Project Management for Adults.
Assumptions
Assumptions are hypotheses about necessary conditions, both internal and external, identified in a design to ensure that the presumed cause-effect relationships function as expected and that planned activities will produce expected results. In other words, an assumption is an event, condition or fact that we need to happen or stay the same in order to assure project success.
Issues
Issues are a current problem – something that is happening now. Issues can be either something that was not predicted or a risk that has materialized. It can take the form of an unresolved decision, situation or problem that will significantly impact the project.
We could explain these terms with the following simple expressions
Risk: «What if?»
Assumption: «We need that it happens/stays this way».
Issue: «Oh, damn!».
If you have predicted the issue and treated it as a risk, you would already have a response plan, and the expression would be: «Hmm, that was to be expected. Let’s handle it as discussed».
Even though risk, assumption, and issue have different definitions, they are deeply connected. An assumption might have a response plan if it doesn’t happen or change, a risk will become an issue at the moment it happens, and an (unpredicted) issue must be included in the risk list once we identify it (and there is a chance that it will happen again).
Decisions
Decisions have NOT been made until people know:
> the name of the person accountable for carrying it out;
> the deadline;
> the names of the people who will be affected by the decision and therefore have to know about, understand, and approve it—or at least not be strongly opposed to it; and
> the names of the people who have to be informed of the decision, even if they are not directly affected by it.
An extraordinary number of organizational decisions run into trouble because these bases aren’t covered. The answers to these questions you should put in a list and act accordingly. It’s just as important to review decisions periodically—at a time that’s been agreed on in advance—as it is to make them carefully in the first place. That way, a poor decision can be corrected before it does real damage. These reviews can cover anything from the results to the assumptions underlying the decision. Such a review is especially important for the most crucial and most difficult of all decisions, the ones about hiring, firing and promoting people.
Closing Thoughts
The secret to good RAID lists is to record the right risks, assumptions, issues, and decisions at the right level of detail. Too many and in too much detail simply create unnecessary bureaucracy. Too few in too little details does not provide actionable insights. For example, I have often seen risk lists 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 are better off identifying the underlying reasons which might cause this, and then express the risk in those terms.
For me, these four lists are the base for proactive instead of reactive project management.
Proactive behavior involves acting in advance of a future situation, rather than just reacting. It means taking control and making things happen rather than just adjusting to a situation or waiting for something to happen.
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.
In a nutshell: Your RAID lists are the base for proactive instead of reactive project management.