Agile project management methodologies such as Scrum go a long way towards reducing risks through frequent releases, and reducing assumptions through learning from these releases. Nevertheless, there are [many reasons](https://www.fluxonomy.com/blog/why-should-i-keep-a-raid-log) why a project manager may want to maintain a RAID log.

The good news is that RAID logs and Scrum are not mutually exclusive - the two can work well side by side to meet the needs of your team. As always with agile methods, the processes should be continuously reviewed and refined to work for your specific team and circumstances, but we’ve outlined some suggestions below:

## Stand ups

The stand up is a short daily meeting (traditionally run with all team members standing up) for the team to discuss and plan the day's work. As a part of this, typically team members will raise any blockers: impediments or challenges that may prevent them from achieving their goals for the day. Keeping an ear out for these blockers is a great way of identifying dependencies that could be worth recording on your RAID log - sometimes team members won't recognise dependencies until they are actively blocking them.

## Retrospectives

Retrospectives are the team's opportunity to reflect the sprint that just finished, and discuss what did and did not go well. Areas for improvement are raised, with the team discussing how these improvements can be implemented in the following sprint.
Similar to how stand ups can identify dependencies, retrospectives can help spot risks or issues that are relevant to the wider project context and worth recording on the RAID log.

## Using the backlog

The Product Backlog is the list of work needed to be done on the product by the Scrum team, ordered in priority order. The Scrum methodology says that the backlog is the single source of this work, and so when work items arise from the RAID log that need to be carried out by the team, it's a good idea to put these onto the backlog. By keeping integrated with the Scrum processes in this way, the work items can be prioritised alongside other work and carried out in the relevant sprint as a result of its place in the priority order. Examples of backlog items we've seen coming out of RAID logs are:
- Work needed to mitigate a risk
- Action points to address an ongoing issue
- Migration tasks to move away from a dependency that is jeopardising the project

<hr />

Developing software in an agile way helps to reduce risk, but that doesn't mean it's not worth documenting those risks clearly. It's important to note that the fast paced and changing nature of an agile project, means it's paramount that the RAID log is diligently kept up to date to ensure that entries are still relevant given new information, requirements, or a pivot in approach.


You're aware of RAID logs as a tool for managing Risks, Assumptions, Issues and Dependencies in your project, but you may be wondering: are they worth the time investment needed to keep them up to date?

In project management landscape where agile practices and frameworks are all the rage, some may think of RAID logs as an outdated tool, but in fact they can help ensure the success of your project, and don't need to be an enormous time sink. In this post we'll be diving in to some of the reasons you may want to keep a RAID log.

## Build confidence and trust

A project will typically have a large number of stakeholders who all want reassurance that the project is on track and won't be derailed by any problems, present or future. These include executives, team members, product owners, finance; all of whom can come to you with questions and concerns about the project.

A well-maintained RAID log puts the you as project manager in a good place to be able to address these accurately, which builds trust that you're on top of managing threats to the project, and confidence that the project is likely to succeed, which is all important for ensuring the project stays backed (and funded) by your key stakeholders.

## Reporting

A well maintained RAID log can make reporting the project status back to senior stakeholders a much easier task. It provides a consistent and clear way of laying out each aspect of the RAID acronym, demonstrating where progress has been made in reducing impact and likelihood of risks, implementing mitigations, overcoming issues: your log can succinctly portray through visuals and graphs how the work that the team has done has made a tangible difference to the success of the project.

## Centralised documentation

A RAID log acts as a central place to store and track the status of your project, providing documentation that can be referenced by team members, and keep track of all actions that are being taken to mitigate factors that threaten the success of the project.

Communication with the project team is just as important as communication with other stakeholders. Using the RAID log as a single place for team members to refer to provides context to inform their decisions, and may inspire other team members to raise their own entries for the log.

## A todo list

Documenting risks and issues is only useful if actions are taken to address and mitigate them. A RAID log is a means of keeping on top of who is doing what, chasing actions that need to be taken, and tracking who has ownership of a certain entry.

By enforcing consistency with how issues are recorded and ranked, the RAID log also ensures there is a clear system for deciding which entries are considered highest priority. Paired with the collaborative nature of a shared central document, the log makes clear which items are top of the list and documents why, giving stakeholders visibility over the biggest problems and allowing them to step in and influence the ordering.

## Time-travel with assumptions

Decisions made in a project are only understandable when the context at the time the decision was made is available to you. By documenting the set of assumptions you’re making about your project means that team members don't have to rely on memory as to why a certain path was taken, and allows them to change approach confidently if circumstances change.

## Disaster plan

It’s a fact of a project that things will go wrong  - assumptions end up being invalid, dependencies let you down, risks develop into issues, issues grow due to being unchecked. By documenting mitigations and actions against your entries, you can be prepared for when the project goes awry and have a plan to bring it back on course.

A RAID log demonstrates to stakeholders that you’re prepared for the worst, and give them confidence that everything is under control.

<hr />

A RAID log adds structure to managing your risks, assumptions, issues and dependencies, and doesn’t need to be a chore. Even a lightweight spreadsheet can go a long way to towards increasing stakeholder trust and ensuring the success of your project, provided it is well-maintained.


Blog

Insights on RAID logs and risk management from the Fluxonomy team

Managing RAID logs with Scrum

Why should I keep a RAID log?