What is one of the most useful tools that you can use to keep your project organised? A RAID log records risks, actions, issues and decisions and is one of the top tools for keeping a record of everything happening on the project. It's very useful because you can store all the relevant information and activity that is happening on your project in one place.
Introduction to RAID Logs
Over the next few weeks I will be looking at all the different elements of the RAID log but today I want to introduce the concept.
A RAID log covers 4 elements:
- Risks
- Actions
- Issues
- Decisions
And as you can see, it is from these four words that it gets its name.
The best format for a RAID log is to use a spreadsheet. Using a spreadsheet means you can have 4 tabs, one for each of the lists: risks, actions, issues, and decisions. While this is the order from which we get the RAID acronym, it is not necessary to have the tabs on your spreadsheet in this order. In fact, most people find that having the action list at the front makes the most sense as this is the worksheet that gets used the most.
Version Control
A RAID log can be updated daily and sometimes several people will have access to it and the ability to make their update directly into the document. This means that the traditional methods of version control are very difficult and far too time consuming.
The best way I have found to version control my RAID log is to give each version of the file a name that includes the date that it was updated.
The most effective way to name documents including the date is to do so in the year, month, day format. The document then becomes something like ‘RAID Log 20110714.xls’. When you use Windows Explorer to search for a document and have the files in a folder ordered by name, the most recent version will be at the bottom of the list. This makes it a lot easier to find. If you used the day, month, year format there could be several files each starting with ‘01’ and you would have to order the files by date last updated to easily see which is the most recent version. I’m sure you will find a naming convention that works for you, but this is what I’ve found useful over the years.
Over the next few weeks I will be looking at the different elements that go into the RAID log, starting next week with risks. I’ll also be sharing some screenshots of what the worksheets can look like so that you can use these as a starting point for preparing your own project RAID logs.
RAID logs: The Risk element
Last week I looked at what a RAID log is. As we saw, RAID stands for risks, actions, issues and decisions. Today I want to share with you some do’s and don'ts for using a risk log as part of this format.
This is what a risk log can look like. Click the image to see a larger size.
DO:
Do log every risk. Even the small ones. Make sure that your log is as comprehensive as it can be.
Do categorise risks if that is useful to you. For example, you may want to categorise project risks by the workstream they came from or the department they will impact the most. Alternatively, your Project Management Office may use standard risk categories like contractual, technical, operational, legal and strategic. Find out if your PMO has a list and if it doesn’t (and you’d like to categorise risks this way), make one up. Categorisation by theme like this can be helpful as you can ask someone to be responsible for all the technical risk, or all the legal risk.
Do use the standard way of ‘measuring’ risk by inputting values for likelihood/probability and impact. If you can, get the person who raised the risk to give you the values for this as they are likely to understand the implications far better than you or other project team members at a monthly risk review meeting.
Do give every risk on the log an identifying number. It is much easier to talk about Risk 8 than ‘that risk about not getting the servers on time.' Using the numbers to refer to risks makes it easier for everyone to know what is being discussed.
Do involve everyone in identifying risks. Use a tool like DropMind to capture everything that is raised during the first risk review meeting.
Do allocate a timescale or proximity to the risk. Even a low risk that is potentially going to happen in the next 3 weeks could require greater management attention right now than a high risk that won’t have any impact until next year.
Don’t:
Don't allocate risk mitigation actions to somebody during a meeting when they are not present. Don’t expect them to look at the log later and work out that they are now responsible for dealing with that action. Instead, allocate the mitigation action to someone at the risk review meeting. Their action could be simply to tell another person that they are now tasked with the responsibility for managing that risk mitigation action!
Don't leave the owner of the risk blank on the spreadsheet. Always allocate an owner, even if that person then changes once further discussions have been had.
Don't assume your risk log is perfect. You won’t be able to identify all the risks that are likely to affect your project, and even if you do, risks interact with each other. A book that discusses how risks interact and how to better manage risk is Tame, Messy and Wicked Risk Leadership by David Hancock.
Don't leave risks on the log that have actually materialised and have now become issues. Don’t delete them completely from the log, but do change the status of the risk to closed and note that it has been transferred to the issue log as it materialized.
RAID logs: The Actions element
As you no doubt know by now, RAID stands for risks, actions, issues and decisions. In this section, I want to share with you some do’s and don'ts for using an action log as part of this format.
This is what an action log could look like. Click the image for a larger picture.
DO:
Do use the log to consolidate all the actions from various meetings. Copy actions from the different types of meetings you have – Project Boards, Steering Groups, team meetings, technical meetings, risk reviews – and log them all here.
Do review the log weekly. Use it as a standing agenda item during your project team meetings.
Do allocate actions to individual people. This makes people accountable and you can scan down the list and see at a glance who is doing what.
Do give every action on the log an identifying number. This makes it much easier to talk about: everyone knows what action is being referred to if you refer to them by numbers.
Do allocate a target completion date to the actions. This gives the action owners a sense of when the work needs to be completed by (or better still, a reminder of when they have committed to have the work completed by).
Do add some kind of reminder to each action, like the date it was raised, or the meeting it was raised in. Making a note of this can help if you forget where it came up.
Don't:
Don't allocate actions to somebody during a meeting when they are not present. You can’t reasonably expect them to review the action log later and see their name against a piece of work, take instant ownership of it and complete the task. This is not a good strategy and risks alienating your team members and stakeholders.
Don't try to make the log too complicated. A simple spreadsheet will do. This gives you the opportunity to filter on action owner, so you can instantly see which tasks are down to you. Filtering in a spreadsheet also makes it easier for team members to send you updates, especially when the list gets long.
Don't log every tiny thing. Especially not actions like “distribute that presentation,” when these are completed during the meeting or very soon after it. You don’t need a historical log of everything anyone on the project ever did. Make a judgement about whether you want to record a task, but don’t worry about noting everything.
Don’t forget to close actions when they have been completed. If you are using a spreadsheet, you can also apply a filter to only show you the tasks with a status of Open. This reduces the likelihood of chasing someone for a task that they have already completed, which is very annoying for them!
RAID Logs: the Issues element
In this section about RAID (that stands for risks, actions, issues and decisions, in case you don’t remember) logs I’ll be looking at the ‘I’ element: issues. I’ll share with you some do’s and don'ts for using an issues log as part of this format.
Here is an example of what an issues log could look like. Click the image to see a larger version.
Do:
Do use the issues log to record as many issues as possible. Try to get a comprehensive list. Use a tool like Dropmind to help you when brainstorming all the different issues impacting the project, and then transfer the ideas into the log.
Do review the log regularly. Weekly might be too much: it depends on how quickly your project is moving. Try to use the log as a working document, so as something changes, update it. This means it always shows the latest picture. If you have monthly risk and issue review sessions, use it as a standing agenda item during these.
Do allocate owners to issues. While that person might not be the one to do all the work, each issue needs a single point of contact to coordinate the issue response actions. Using the spreadsheet format also means that project team members can filter on their own name and quickly see what they are responsible for. This is handy when they are preparing for meetings.
Do give every issue an identifying number. This is a recurring theme with the RAID log. Everything on it should be numerically identified. It makes discussing the issues and recording actions easier if they link back to a unique issue number.
Don't:
Don’t forget to close issues when they have either been dealt with or the problem has passed. You can shade the spreadsheet cells in grey to show that the issue is no longer active. You can also change the status to ‘Closed’ so that you can apply a filter and only show the Open items during review meetings. This also means that you have a history of what issues arose and how they were dealt with, which is useful, and much better than simply deleting the line.
Don’t duplicate actions: if you record an action in the issues log to manage an issue that the project is facing, don’t copy it on to the action log as well. That just means that you have two places to update the status. Use the RAID log as one master document, so you review all the elements regularly to pick up those actions not specifically on the action log.
Don’t worry about downgrading issues. Sometimes (not very often, but sometimes) issues stop being a problem and become a risk. If that happens, copy and paste the issue history into the risk log. Open a new risk, referencing the issue. Then close the issue. This is why having all the elements in one spreadsheet is useful.
Don’t forget to follow up! Issues are problems. You have to do something about them. There’s no point constructing an issue log if you don’t use it, so remember to regularly review the issues, add on new ones and chase the relevant actions so that those issues are properly dealt with.
RAID Logs: the Decisions element
The final part of my series about RAID logs is the 'D' element: decisions. Below are some do’s and don'ts for using a decisions log as part of this format.
This is an example of what a decisions log could look like. Click the image to see a larger version.
Do:
Do use the decisions log to record the decisions made in all the project-related meetings, not just your project team meetings. You can also use it to capture decisions made ‘on the fly’ in corridor chats or via email. This makes the decisions log a useful record of everything significant that has been agreed.
Do review the decisions log regularly. While it is mainly a place to capture significant decisions, it doesn’t hurt to review it with the team and remind yourself of what decisions were taken and why. This will ensure that you don’t inadvertently do something that goes against an earlier decision.
Do note down who made the decision. Record all the parties if it was agreed jointly. You don’t always need to include the names. For example, in the image above, you can see that one of the decisions was made by the Project Board. The minutes of the Project Board meeting for that day probably have more information about the rationale behind this decision. You don’t need to include the names of everyone who attended the Project Board meeting.
Do give every decision an identifying number. Yes, you have to do this for all the elements of the RAID log. As with the previous elements, everything on the decisions log should be numerically identified. You probably won’t refer back to the decisions log as often as you do the other elements but it is good housekeeping to give each decision a unique issue number.
Do include as much information about the decision as possible. What was taken into account? Where were the people when the decision was made? Why was the decision taken? Record the rationale as well as the actual decision. This will help you justify and remember the details about that decision when you look back at it in six months and can’t recall the logic behind it.
Don’t:
Don’t delete decisions from the log if they have been revoked. Sometimes decisions are made on a project that are good at the time, but with more information or a change of leadership, the decision is actually reversed. Keep the decision on the log but shade the spreadsheet cells in grey to show that the decision is no longer ‘live’. You can see an example of this in the image above.
Don’t try to record every decision. The fact that you decided to hold a Christmas project team dinner is not a decision for the log. Record things that have a material or significant impact on the outcome of the project or the project processes you are using. If you try to record everything, the log will become unmanageable and people will stop referring to it.
Don’t forget to circulate the log! Remind people what they decided. Sometimes on big projects people forget what they agreed to a few months ago. The log provides a way to remind them. You could even add a column that links to supporting documentation or information like emails or project team minutes.