RAID Log, Every Project should have one

RAID Log, Every Project should have one

A record of all project Risks, Assumptions, Issues, Dependencies should be made for just about every project, including software development projects.

This article is a sister blog to my earlier one about Key Design Decision documents. Despite people thinking that working in an Agile way means doing without unnecessary documentation the Agile Manifesto does not mention this (https://agilemanifesto.org/principles.html). I would argue that the RAID log is an important communication tool which should not be ignored. Some might call it a ‘Project Management’ tool but as a software architect I recommend them every time. My IT architecture designs are heavily dependent on this sort of document and my designs react to changes in them. For instance if a particular risk occurs or a dependency fails then we might change the chosen option in a design and use a different technology. This is easier if it was thought about in advance. 

Format and content 

So what is the format of a RAID Log? As before with Key Design Decision documents there is no universal format. Typically you use a spreadsheet with four sub worksheets to describe and enumerate all the currently known Risks, Issues, Assumptions and Dependencies. Of course you might just put this in one spreadsheet and have the “type” as a drop down list, but I think that is a mistake because you deal with these things in different ways.  

There is some significant overlap between key design decisions because those often involve assumptions which helped the team make those decisions, and there is often a risk that the decision made was incorrect.  

So what are the overarching things you need to record? 

  1. Have a number for each entry. You will need to refer to them later on and just giving them a name can be confusing and inconsistent.  
  1. You want an easily read explanation of what the problem is right now. What might go wrong (The Risk), what is currently going wrong (An Issue), what do we believe to be true (An Assumption), what do we rely on other people for (A Dependency). I sometimes refer to this as the “bad thing happening” though the bad thing may be that the assumption is false, or the dependency fails.  
  1. What is the effect of that thing on us or our project. Will it cause us to lose money, fail, recruit more staff, produce wrong results, whatever? 
  1. Is that a Major problem for us, or less of a worry. 
  1. Is the bad thing likely to happen, or is it just a remote chance. (Issues are already happening though, so does not apply to them) 
  1. How are we mitigating against the bad thing happening now? 
  1. How will we cope with the bad thing happening when it happens? 
  1. Who recorded the entry, and when was it last reviewed and updated. 
  1. Who owns the problem? 
  1. What is its current status? (Hopefully you want them closed as no longer risks or issues) 

Templates

A swift google search reveals a bunch of possible templates for free. I would not worry about getting the most perfect template or filling in all the columns. Figure out what will actually get used by your team.  

Conclusion

RAID Logs may seem like project management fluff, but in reality they can be a life saver for anyone doing a project or programme.  

If you want more structure to your IT or business architecture then get in touch for a no obligation chat about your problems and how we might be able to help.  

Author

Alex McLintock has over 25 years in the IT industry. Alex runs Alephant which helps companies in London to design new systems for Big Data Analytics and Data Science. He has written several articles here.

Photo Credit: John Moeses Bauan on Unsplash

Discussion

If you want to comment on this blog please do so on my LinkedIn profiile