Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Project management theorists discuss the importance of the RAID log (Risks, Assumptions, Issues, Dependencies).
I have found in software development there is commonly the Issues log (which is actually the requirements log), and none of the other logs are present nor ever mentioned.
Do project managers use RAID Logs? If so why and how do you use them? Are they as critical as theory would indicate?
How could RAID logs be improved?
Absolutely keep logs and absolutely bring them to the surface and work them on a strict cadence. Especially risks. Without the logs, people will happily ignore them. There is a resistance in raising and working risks, I think because of the mantra that optimistic and can do people are more successful.
I have never maintained assumptions and dependencies logs because these are a source of risks. If an assumption is made, there is a risk that follows that and, keeping two logs, you would end up having the same exact event being tracked on two logs. Same for dependencies.
Issue and Risk logs have a very similar connection that is often missed. When you have an issue, you have downstream threats. When you log the issue, people tend to forget about the assessment of those downstream threats. And if you do the risk assessment, you could find yourself working the same business event in two logs. This is inefficient and opens the door to miscommunication.
Edit: I have found in facilitating risk working sessions that we end up in this ongoing argument as to whether an identified event is either a risk or issue. It comes down to how an individual was framing the event, either tactically or strategically.
For example, a patient presents to his doctor with high blood pressure and cholesterol, over weight, family history of heart disease, and sedentary life style. All of these are issues based on the normal definition of an issue. However, all of these are also risk factors for the risk of heart attack. The heart attack is not certain nor its severity. If this was a project, would you log the BP, cholesterol, obesity, family hx, lack of exercise in the issue log or the heart attack in the risk log...or both?
Tactically, you would treat the issues; strategically, you would mitigate the heart attack as well as plan for after the heart attack by way of contingency planning. Treating the issues and mitigating the heart attack are likely the exact same actions but, the way we approach it in projects, we have a tendency to over simplify this and attempt to treat these things separately, causing disagreement and argument and inefficiencies. We tend to lose sight of the bigger picture, I have found.
I think trying to separate risks and issues is a mistake and maybe we should approach this more as exceptional events. Sometimes we are tactical, sometimes strategic, sometimes both.
In my opinion any Project Manager that does not actively use Risks and Issues logs is not worthy of the name. Active management of risk, particularly, is the biggest part of what a project manager is and does, again, in my opinion.
I had never used Assumptions and Dependencies logs until I started working at my prior employer where I encountered them for the first time and used them on a series of projects. My conclusion after that, I'm afraid, was that they provided no real benefits though that could easily be my naiveté with their usage (for which I received no training). Sadly I got the impression they only existed to provide the 'A' and 'D' for the natty word RAID!
In terms of Risk logs, I tend to take a very pragmatic view of what should be in them... In PRINCE 2 we learnt that you should categorise and record your risk mitigation actions (Transfer, Reduce, Accept etc.) and other such things. I have never ever seen a use for that information other than to bulk out the methodology and make it seem more scientific.
What I need to know is:
And I leave it there- any more is extraneous detail to me. If it doesn't help me resolve the risk I am not interested in it.
I use Risk and Issue logs and review them on a strict, regular basis. They are essential tools both for myself as a PM, and for the wider stakeholder community within the project. Why do I say that?
I have not found many circumstances where I have used Assumption or Dependency logs, except as a way of capturing my thoughts which are then turned into risks (if necessary) once I take time to analyse them (as mentioned by David Espina in his response to this question).
I define a risk as "Something that might happen that will have an impact on the project", whereas an issue is "Something that has happened that has impacted on the project". The key is a risk MAY have an impact, where an issue has ALREADY HAD an impact.
I find it helps to try to express risks in the form: "There is a risk that (something might happen) because (something might go wrong), which may result in (a described impact on the project)". So, referring again to David Espina's answer, as long as the patient has not suffered a heart attack, I might say "There is a risk that the patient might suffer a heart attack because he has raised blood pressure and high cholesterol which might result in serious long term health problems or even death". To mitigate that risk, take whatever steps are necessary to lower blood pressure/ reduce cholesterol, and document these.
There is a similar format for issues, along the lines of "There is an issue which is (whatever has gone wrong) as a result of (whatever has caused it) which has resulted in (an impact on the project)". So back to David's example, if the patient has actually suffered a heart attack:, "There is an issue which is that the patient has suffered a heart attack as a result of high blood pressure and cholesterol which has resulted in the need for open heart surgery and long term medication".
I would actually use these forms of wording in my risk or issue register, along with mitigating actions and an assessment of the impact or likely impact, and also (for risks) the likelihood of the risk happening. There is no need for a likelihood for an issue, as it has already happened so the likelihood would be 100%.
I have worked with both Scrum and agile methodologies, so it depends upon your approach to the development.
In Scrum this issues are really nailed on the head. The Scrumaster has a scrum meeting with the team every day so the risks are looked at on a daily basis by asking each team member what they did yesterday, have they any blockers standing in their way or are there any issues and what will they do today. If there are any major obstacles, the team member is helped out with the blocker and therefore it becomes a team effort and almost always all of the issues are resolved. At the end of the sprint there is sprint review meetings to see how the team did well and where they could improve. And then there is an actionable items list that forms the focus for the team throughout the scrum. I really like this approach as it cuts down on documentation and there is a real team effort.
However, I have used scrum in conjunction with a project plan. First the customer charter is done if this is applicable. Then the Qualitative Risk Assessment is Completed.
Then the impact analysis is done. The diagram below is an example of this analyis. The probability that the risk will occur is multiplied by the impact should this happen. The diagram below gives an example
The qualitative analysis is used to look at the impact analysis and this is done by multiplying the likelihood of the probability of the problem occurring by the impact. I usually give scores out of 10 to the probability of the risk occuring and the impact with 10 being the highest. This Keeps It Simple. The results form the rank of each risk and 1 becomes the highest risk.
Finally a mitigation plan is considered for each risk. The Risk, potential cause and response are considered.
A contingency budget is then completed using the Expected Monetary Value or EMV. The probability of the risk happening is predicted with a percentage of the likelihood of that risk happening. The possible delay of the risk is then predicted and multiplied by the cost per day to give the cost impact. the cost impact of each identified risk is then multiplied by the probability to give the estimated contingency budget.
I have kept issue logs but only with live incidents and not with the development of software. I use ITIL software in Waterfall management for the live issues and Spira for bug tracking. These are really good open source software packages and avoid the need for spreadsheet hell. In a shared services project I was involved in we used an issues log which was not really suitable to the needs of the project. People were asked to update it and they never did.
In conclusion I favour scrum and agile methodologies, in conjunction with a good project plan and open source software to track the issues.
If there is any other information I can provide please let me know. i love this stuff.
Our project has been using a RAID which is a spreadsheet with one worksheet for each of the four items. Whilst I think a RAID is generally a good idea (and others have provided a critique of each part), I have encountered some major downsides with the spreadsheet:
These problems are due to the way the RAID is created rather than the concept itself, but given business’ love of spreadsheets I suspect they apply to other people as well.
I consider management of risks and issues to be critical to project success. The A and D in RAID usually stand for Assumptions and Dependencies - they become increasingly important as the size and physical separation of the project team goes up.
Crucial to their use is to be sure that everyone agrees to a common definition for "risk" and "issue". I generally stress that a "risk" is uncertain, while an "issue" is certain.
Trying to distinguish using other means I think runs into trouble. Separating by tactical vs strategic response I think is not the right way to approach it, because both risks and issues can arise at both levels. Separating by future vs present or past also runs into trouble - one can have an issue that will have certain impact in the future but hasn't happened yet, and a risk that has to do with mitigating uncertain consequences from an event in the past can also occur.
Defining a risk as something that has a probability less than 100% of having impact on the project gives you two handles for dealing with it: try to modify the probability (avoid or transfer) of impact, and try to modify the impact (mitigate or plan contingencies). With an issue, all you can really do is work on mitigating impact.
In David Espinoza's example of a patient, the known symptoms are all issues - you can treat the symptoms but cannot change the probability of the patient having them. Heart attack is a risk that can have the probability modified by treating the issues and for which contingency and mitigation planning are probably both appropriate.
