RAID Difficulties
One of the LinkedIn network members posted a very convincing example, illustration of RAID: Risks, Assumptions, Issues, Dependencies log.
- The risk was a dog doing its business on a lawn.
- The issue was somebody stepping into that.
- The assumption was kids playing barefoot on that lawn.
- The dependency was the dog owner cleaning the lawn (many comments pointed to this mitigation plan).
It was kind of on the edge but illustrative.
100% of project managers do understand the RAID log when you ask for a definition.
But in practice on a specific project or situation, I could see a lot of mixing of risk and issues and concerns melted all together into one bug monster log.
The very first challenge when defining risk is project team members often don't distinguish risk from an issue as they don't know if this is a problem or not yet. They simply have concerns and questions and put them on a table.
And this is OK. It is the project manager's role to make it understandable for all.
Most of those concerns are issues, not risks. They are already a valid situation. There is no question will or will not happen. They are there.
Another difficulty is that risk can turn into an issue, and this is another challenge on tracking and requalifying as the project goes on.
This requires a regular review of the log and changing it as it goes. The trick here is to keep a reasonable level of entries.
I have seen projects where the log was 500+ RAID events and it was not manageable.
More Focus on Risks
The risk log should be managed separately from other RAID elements.
Why?
Because management, sponsors are more interested in risk than any other RAID log elements.
Have You ever seen a board approving projects asking what are the issues?
Or assumptions? Yes, they could ask for assumptions.
But they will ask for risks. It is given
"Sponsors are more interested in risk than any other RAID log elements.
This is why the risk log must be managed on that level "
It is party cultural, but in most cases, they want to get confidence project leaders are ready for unknowns.
They know unknowns will come. So, is the project spending time to think about unknowns?
Do I, deciding on approving the project, have confidence it will be delivered no matter what?
Why don’t they ask for issues? They assume this is operational and under control.
In my practice management never asked about issues. They just want the project to resolve them. If the project can not resolve them, it should come with a specific issue and better have an option how to approach it.
Risk Log Management
If the risk and risk log is of interest to sponsors and management, it must be managed on that level.
What does it mean?
- First, I would not mix it into the RAID big table.
- Second, while issues, assumptions dependencies can be operationally managed by the team – with a big, shared log. The risk log rather should be managed centrally by the project manager in form of review sessions.
I am not saying other approaches are wrong, but the above one will give better results for sponsors and management.
In the end, you want to come up with a list of 10 plus risks and very clear mitigation strategies.
They should be agreed upon within the project team - not only the originator (like the issue can be).
Risk review session proves to management project spends time to foresee unknown.
Final Conclusion
Did I mention that having risks identified and recorded in the log is not enough?
There must be a mitigation plan attached to it. And better very clear one.
IF You pls to mitigate with another budget, make sure it is stored transparently within project cost forecast information.
Pricell.io is a tool that can make it easy and transparent.
