What's In a RAID log and how do I make one?

Published April 12, 2025 • 4 min read

Updated April 17, 2025

Author James Nicholls

What's In a RAID log and how do I make one?

RAID stands for Risks, (Assumptions/Actions), Issues, and (Dependencies/Decisions) displayed as RAID logs. These dynamic documents are updated as the project progresses and serve as a later-stage reference. Does that happen, and should this facility be added to FinStarty? Alternatively, are our project management tools already covering the issues RAID addresses?

Each item in a project needs to be assigned to a person or team responsible for addressing it and capturing any related information. This can create an administrative overhead that could become more prominent than the project itself if not done in a way that aligns with an existing workflow. Before considering adding the features to FinStarty, I must be convinced of its use.

Risks

Any potential problem that could negatively affect the project could be posted in a comments section, marked as a risk, and notified of by the team. A discussion could occur, and a response could be marked as mitigation.

The existing comments section could have a toggle whereby a comment is marked as a risk statement. This, in turn, would require a mitigation statement in the form of a sub-comment. The team would have to agree upon this. I think you would also need the option of rejecting the risk.

Acknowledging risk should be done at the start of the project. This will mean that stakeholders can be informed beforehand that certain scenarios will impact the project. It could make it easier for senior stakeholders to help mitigate risks, such as other projects taking resources or changing business situations. Still, it's unlikely they will have time for project details and need a summary of the delay. For those closer to the project, the risks could be more detail-oriented, a miscalculation of usage requirements on a piece of software, or a particular use case hasn't been accounted for.

Whatever the risk, mitigation will lessen the impact when things happen. This shouldn't be a rewrite of the plan, the mitigation response should be proportionate to the risk.

Feature development is recommended for FinStarty.

Assumption or Actions

Actions are tasks or sub-projects of an open project. These are assigned to individuals from the project page, you can also assign a team from the organisation. Sub-projects are clearly defined, with estimated times set for the primary project.

Assumptions are used to progress a project when information is unavailable or unclear. The team could also assume event outcomes based on their experience. These could be risks if an assumption turns out to be wrong, a delivery time not being met, or a machine not produce something as quickly as before is a risk. Previous experience is a guide, not a prediction.

Assumptions should be minimised, and clarifications should be sought to de-risk projects. Used in conjunction with scenario planning assumptions, they are a useful addition to your project management toolkit.

This requires additional tooling in FinStarty. Logging the assumption, if the wrong scenario response and clarification. These could be separated texts, making them three distinguishable statements: the assumption, the if wrong, and clarification. Finally, an elapsed time so you don't keep chasing clarification.

Issues

Recording unexpected problems that arise as the project progresses, anything that causes delays, or complications. Unexpected resource requirements or decisions being changed are common issues.

A simple statement that outlines the issue and its effect is sufficient for minors. However, more details should be provided if it causes significant delays. Quantifiable elements like "days" or "costs" can be separated and easily made identifiable during the project.

Decisions or Dependencies

Dependencies are already handled and are a requirement of the GANT chart tool.

Decisions should be jointly agreed upon by the stakeholders and should not be lightly undone, as many actions will likely result from them. First, you need to frame a decision, then you could have proposals and then a final decision statement.

Trails of changed decisions could be useful in keeping stakeholders informed of developments when they are not in the room. Tools for recording decisions also inform all concerned parties, the immediate team and those working on sub-projects and dependencies who could be affected.

FinStarty Development

A New tool on the project page where the comments are is likely to be the place framing them in something that users are familiar with should help adoption. Giving people the option to make a standard comment and the option to add to the RAID log should make the adoption of the tool easier.

About the Author

Author Avatar

James Nicholls

Digital Marketer, Ecommerce Specialist who knows a little about making a websites work for businesses

View LinkedIn Profile →

Share This Post

Related Articles