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?

  • I'm still a project management newbie so I won't post this as an answer: Yes, keeping track of Risks at the least and the list of issues in a separate document is a really good idea no matter if you're already using project management tools like JIRA or MS Project. You can tell an experiment project manager by the way they keep track of risks; inexperienced managers (and developers) think only an issue log is worthwhile.
    – user27307
    Commented Feb 15, 2017 at 14:45

6 Answers 6


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.

  • 3
    A Decision log is another valuable and critical tool. If you don't track when decisions are made, you tend to revisit the same decisions over and over. Commented Jun 12, 2015 at 17:34
  • I agree with that, Joel! Commented Jun 12, 2015 at 17:35
  • 2
    Mmm, I have mixed views on Decision Logs... All the decisions I get are done in meetings so I record the decisions in the minutes. Can never see a need to write the minutes up and also record the same decision in a log. On the other hand I am sure it depends on the size of the project- multiple delivery teams and/or separate locations would surely need a central log- it's just that I never get that big with my projects :)
    – Marv Mills
    Commented Jun 12, 2015 at 19:24
  • I, too, hate doing things in duplicate. But what I like about a log is searching and finding the decision. I have had to search minutes before and it's awful. On my current gig, we're using TFS and, while not the best tool, it truly helps when we have a dispute and I can quickly find a documented key decision. Commented Jun 12, 2015 at 19:36

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:

  • What is the Risk and the Consequence
  • Its status - Open or Closed
  • What is the likelihood of it happening
  • What is the severity of the impact if it happens
  • Sometimes its proximity in time, but not always
  • When it was raised and by whom
  • Who currently "owns" it
  • What the current status of the mitigating action is, so I keep a log of comments showing how it evolves over time (just more info in a spreadsheet cell)

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?

  • For myself, they give me focus to ensure that I address whatever could derail the project, and they make me think hard about the actions to mitigate the risks or deal with the issues, then they help me to track progress against these. So in that respect, the log is much more than just the statement of the risk or issue: it is a tool to capture the wider circumstances of the risk or issue.
  • For the wider stakeholders, it gives confidence that the project is under control and that they can see what is being tracked and actioned, beyond just normal progress. It also - and this is crucial - allows me to engage with them to ask for their help where necessary, as they can often deal with the risks and issues and do whatever it takes to mitigate the risks or address the issues.

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.

Qualitative Risk Assessment

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.

Impact Analysis Example

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.

  • The way the data is represented looks like overkill, I keep a simple spreadsheet where I log all risks one by long and rank according to priority.
    – bobo2000
    Commented Feb 16, 2017 at 15:15

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:

  1. The items aren’t linked in any way to the schedule. In many cases a RAID item arises due to something going wrong when people are trying to do a schedule task. I’d much prefer to use some software that tracks tasks and their issues are linked together.
  2. Because each RAID category is on a separate worksheet, it’s difficult to link related items together. For example: a risk is logged, it later becomes an issue. Do you cut the original risk and paste into the issue sheet? Do you duplicate the information and write “refers to risk 123”?
  3. Because it’s a spreadsheet, no automatic way to find duplicates (it would be nice to have something like stackexchange does when you’re creating a new question – suggest if similar ones already exist)

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.