RAID Analysis is an acronym for Risks, Assumptions, Issues, and Dependencies. All projects large and small have risks, issues, dependencies, and assumptions. Managing them is one of the most time-consuming activities but done well, the effort is paid off by fewer delays and cost over-runs, better-informed stakeholders, more support for the project, and better delivery of benefit. This technique has been borrowed from the domain of traditional (waterfall) project management, which typically calls for the creation of a deliverable such as a “RAID log.” This retrospective technique borrows the four facets without the overhead of maintaining an ongoing RAID log.
During Sprint or Release Planning it is useful to capture any Risks, Assumptions, Issues, and Dependencies that we identify during the planning, that might impact the successful execution of the plan. A RAID diagram is useful for this.
| Risks | Events that will have an adverse impact on your project if they occur. Risk refers to the combined likelihood the event will occur and the impact on the project if it does occur. If the likelihood of the event happening and impact to the project are both high, you identify the event as a risk. The log includes descriptions of each risk, full analysis and a plan to mitigate them. Examples: There is a transport strike looming for the next number of weeks, so it will be difficult for people to get to the office. Peter is doing maintenance on another high priority project; he might get pulled on a regular basis from this project if there are issues for the customer. |
| Assumptions | Any factors that you are assuming to be in the place that will contribute to the successful result of your project. The log includes details of the assumption, the reason it is assumed, and the action needed to confirm whether the assumption is valid. Examples: To cause the least disruption, 21:30 is when we think we have the least number of users online so it’s the best time to upgrade our system daily. |
| Issues | Something that is going wrong on your project and needs managing. Failure to manage issues may result in a poor delivery or even complete failure. The log includes descriptions of each issue, its impact, its seriousness and actions needed to contain and remove it. Examples: We have scalability problem after 10, 000 connections to the database. Mary, the principal tester, is going on 2 months extended leave for July and August. |
| Dependencies | Any event or work that are either dependent on the result of your project, or on which your project will be dependent. The log captures whom you are dependent on, what they should deliver and when. It may also include who is dependent on you. Example: We are using a beta version of our platform for development, and it’s due to be officially released 6 weeks before we go live. |
Used properly, RAID management helps you:
- Deal with potential problems before they happen
- Understand when you need to escalate for more senior assistance
- Ensure everyone understands what you’re dependent on, and that’s dependent on you
- Inform all stakeholders of the planning and delivery dependencies, and assumptions you’ve made for the project
Executing RAID Analysis Sprint/Release Planning
- Prepare the RAID canvas with the following four areas: Risks, Assumptions, Issues and Dependencies
- Ask the participants to write down their notes on an individual post-it for each of the four areas.
- Consider using cards of a different color to represent each type (R, A, I, or D), respectively.
- A note might belong to more than one quadrant. In such cases, write more than one note; each note specifically to the quadrant.
- Conversation and action items about the notes
Few key items to be considered during this exercise
- Resource availability & continuity
- Environmental Risks, Technical Risk
- Quality considerations
- Regulatory, Governance
- Logistics risk
- Outbound dependencies, where your project is dependent on something happening in another team before you can complete a task/deliverable
- Inbound dependencies where other teams are dependent on you delivering before they can complete a task or deliverable
Setting up in Kanban board
For RAID board, set up 4 lists that look like this. Think of this as a workflow. Items will be moved from the backlog across the screen from left to the lists on the right as you deal with each item.
RAID backlog – this is the intake list. When new items are discovered, a card is created here and a label is put on it to indicate if it’s a risk, action, issue or decision. Cards can be sorted by priority by simply dragging the card up and down on the list. Everything starts here and then is moved by dragging the card to the next list.
In Progress – when an item is being worked on, it is moved into the “In Progress” list. The most pressing issues are sorted to the top and team members can work on and update these cards directly. These items have been assigned an owner and they are working on it.
Resolved – when an item has been resolved, it is moved into this list. Unless it’s a decision where you would then move into the “Approved decisions” list.
Approved Decisions – when a decision is made, it can be added to this list to capture an ongoing log of all of the decisions.
Managing in Kanban board
It’s much easier to manage RAID log via Kanban Board instead of a spreadsheet. With Kanban boards, you can:
- Visually see work in progress
- Instantly understand impediments (things causing you to delay) and take steps to remove them
- Improve communication between yourself and others on your team
- Empower teams to self-manage visual processes and workflows