The importance of risk management in projects can not be emphasized enough. This seems obvious, but unfortunately most project managers or agile teams have not yet recognized this. In recent years, the ROAM Risk Model has become established in agile projects at team level, but also at higher levels in scaled frameworks, e.g. in SAFe. I have many years of experience in risk management in projects and got to know the ROAM model several months ago. But I have to say, it doesn’t convince me! Would you like to know why? Read on and find out why.
What Is the ROAM Risk Model?
Before I go into the negative points of ROAM at the end of this article, you will first receive a detailed description of this model.
The ROAM risk model is a collaborative lightweight risk management approach to help and agile projects identify and deal with risks appropriately. The SAFe (Scaled Agile Framework) framework has popularized ROAM with its usage during PI Planning.
ROAM is an acronym for Resolve, Own, Accept, and Mitigate. These are the four statuses into which the risks are categorized in order to manage them. The ROAM model encourages collaboration on every level, as the entire Agile organization is called to help identify and prioritize risks. Further, the ROAM model creates a system of accountability for risk management that saves time, effort, money, and stress. Implementing a simple risk management model like ROAM to manage risks proactively could be the difference between success and failure for an entire organization.
What Does ROAM Stand For?
ROAM is an acronym for Resolve, Own, Accept, and Mitigate. Here is a detailed explanation of all four letters:
1. Resolved: The identified risk isn’t a threat anymore. No action is required.
This state is applicable if the team has taken action to eliminate the risk, or it could be because it was verified that the level of risk is non-existent. Either way, resolved indicates that there are no remaining concerns.
2. Owned: The owned status indicates that someone has accepted responsibility for managing the risk.
Owned is the only status that means the risk still needs to be handled. The other three statuses are all variations of “done.” Ideally, the team has discussed already the mitigation plan for Owned risks. The owner accepts responsibility for executing the plan; therefore, he owns the risk. If there is no defined mitigation plan, as the owner will work collaboratively to develop one and monitor the risks until its is no longer necessary.
3. Accepted: An accepted risk is one that we’ve acknowledged and chose to take no action to resolve. When it happens, it happens!
This decision might be appropriate when the effort to mitigate the risk costs more than allowing the risk to transpire.
Accepting risk is also an appropriate response in situations where we have no options for mitigation or resolution. If there is nothing we can do to prevent the problem, we document that we’re aware of it and move on.
4. Mitigated: A mitigated risk is reduced but not eliminated.
The mitigated status is used when all is done to manage the risk. The team cannot eliminate the risk entirely because, for example, the measures required for complete elimination are too costly. It is considered that a threat is mitigated when the probability or impact of the risk is reduced, but the team intends to take no further steps toward resolution.
The status Resolved and Mitigated is often conflated. The main difference between these two is that resolved means there is no more risk; it’s essentially been eliminated. Mitigated means we’ve done everything in our power to reduce the risk, but some element of risk remains.
The ROAM Board
Below is an example of a ROAM board. with the four quadrants (Resolved / Owned / Accepted / Mitigated) and a ‘New’ column where new risks are placed that the team has not yet discussed. After discussion of the new risks, there card will be transferred to the appropriate spot on the board based on the conversation’s outcome.
If the team agrees that no action could or should be taken, the card will transition to the accepted column. If the team could not manage the risk in the immediate discussion, the card would transition to the owned quadrant once an individual had accepted accountability for its management.
ROAM in the SAFe PI-Planning
In an agile planning session, e.g. in the SAFe PI-Planning (quarterly planning), the identified and discussed risks are organized during the planning session into the ROAM categories. Then a confidence vote is used to decide on the prioritization of the risks to be worked on..
If a risk is Resolved, Accepted, or Mitigated, it is effectively dealt with during the course of the PI planning session—and the time thereafter. The only exception to this is Owned, which requires further action by the “owner” of that risk. It’s important to have procedures in place to follow up on any risks that fall into the “Owned” category, to make sure that the action for these risks are effectively planned and executed and monitored.
Your Agile organization may already use an enterprise Kanban solution to visualize and manage its work, then consider visualizing your risk management efforts in the same place. For the PI-Planning it makes more sense to use the ROAM Board, where you brainstorm and categorize risks. Then, move any outstanding risk management-related tasks to the appropriate execution boards so that they are visualized.
ROAM Risk Management at Every Level
The ROAM model can be used on any level of a scaled agile framework like SAFe or Scrum@Scale. Most practitioners agree that team-level risks should be handled at the team level, ideally during PI planning. But risks that could affect the whole Agile Release Train (ART) should be escalated to the ART Level.
Having effective escalation practices in place means that teams don’t have to worry about facing or managing the same risk more than once. It also means that mitigation practices for higher-level risks are more likely to be successful, because they’ll take the entire scope of the risk into account.
What Are the Benefits of the ROAM Risk Model?
What promoters of the ROAM risk model say: The ROAM model is flexible and agile: It aligns well with Agile principles by promoting adaptability and responsiveness to changing risk factors. It encourages collaboration on every level, as the entire Agile organization is called to help identify and prioritize risks. Further, the ROAM model creates a system of accountability for risk management that saves time, effort, money, and stress. Implementing a simple risk management model like ROAM to manage risks proactively could be the difference between success and failure for an entire organization.
With my experience in Risk Management, I see some problems with the ROAM risk management model. Read on and find out which ones.
The Problems with the ROAM Risk Model
The agile way of managing risk with the ROAM risk model has many disadvantages compared to the traditional risk management approaches. Here you will find the most obvious problems and suitable solutions.
- Simplicity: ROAM focuses on categorizing risks into four categories (Resolve, Own, Accept, Mitigate), which oversimplifies risk assessment compared to more comprehensive risk management frameworks. However, it lacks the depth needed for complex projects or situations.
- Limited Risk Identification and Analysis: ROAM does not encourage a thorough identification and analysis of risks because often only a little time is spent for it. It identifies and categorizes risks quickly but might overlook critical details or potential impacts that a more exhaustive risk management approach might identify.
- Overemphasis on Acceptance: With the fast, agile ROAM approach, there is a tendency to accept risks fast without appropriate analysis, leading to potential and unexpected problems down the line.
- Risks are Underestimated: Actions are only defined for critical risks. The other risks are classified as non-critical with a low probability of occurrence and are, without detailed analysis, quickly moved to the resolved, accepted or mitigated squares of the ROAM Board. This is efficient but in my view also “irresponsible”.
- Lack of Formal Documentation: ROAM encourages collaborative discussions but doesn’t emphasize formal documentation of risks. In larger projects, insufficient or undocumented risks can lead to confusion, miscommunication and can also cause problems during audits.
- No Regular Review and Reassessment: Agile teams should periodically reassess and review risks identified through the ROAM model. This ensures that risks are continuously evaluated, allowing for adjustments and adaptations as the project progresses. This not only for the Owned risks but also for the Accepted and Mitigated risks. This includes also to identify periodically new risk, ideally at each sprint planning.
- No Training and Skill Development: Provide training and support to team members involved in risk assessment. Equip them with the skills and knowledge necessary to identify, evaluate, and manage risks comprehensively. For example, do they know basics such as the difference between risk, issue and impediment?
The difference between risk, problems, issue and impediment
Summary
While the ROAM model offers a simple and quick way to evaluate and categorize risks, it lacks the depth and detail of a more comprehensive risk management approach. To mitigate its limitations, agile teams can combine it with detailed analysis, sufficient documentation, regularly review identified risks and encourage open communication. But also train teams so that they have the skills for an effective risk management..
In general, however, I somehow get the impression that ROAM is “Risk Management on the fly”. For a more detailed risk management, I can already hear the counter-argument: “But that’s no longer agile!” Here is my answer:
Would you rather be agile or have fewer problems in the future?
More about Risk Management in projects
Here You Can Find More Knowledge
Would you like to learn more about how to make your projects more successful with Scrum and Agile Project Management? My book Scrum – How to Successfully Apply Agile Project Management and Scrum takes you an important step further!
Do you know somebody who might be interested in this article? Then forward it or share it. Thank you!
