Your organization’s ability to act is directly linked to its decision-making. In projects and (agile) development, decision-making is essential in driving delivery. That’s why most agile and project methodologies recommend securing decision authority as close to the “source” – where the actual work is done, e.g. at team/team member-level. Decision-making is such a critical component that any decision-making is to be encouraged as long as you learn and adapt based on the outcome. And here there’s an important link to understanding risks.
Your risks are a great place to start if you want a better understanding of your organization’s decision-making. Organizations might have several other types of risks: cybersecurity risks, compliance risks, or personal safety risks – often in different risk registers and systems, sometimes all lumped together in a big ol’ puddle without any means of discerning which type is which (this is not recommended). However, the risks covered in this article are what you’d traditionally call project risks. They’re events or matters that have a certain probability of making a particular impact on your ability to deliver a certain product.
When organizations are using SAFe or perhaps scrum with some traditional method on top, there’s also the inevitable discussion of impediments vs. risks (perhaps vs. enablers vs. issues vs. etc.). This could be a whole other discussion (perhaps Diogenes-bald-chicken-reminiscent) and is also not the subject of this article (which is about understanding risks).
Decision-making is such a critical business component that any decision-making is to be encouraged as long as you learn and adapt based on the outcome. And here there's an important link to understanding risks… Click To TweetCRASH COURSE: Risk Handling Methodology
Before going further into the understanding risks vs. decision-making ability you’ll also need a quick introduction to handling risks. There are different ways to handle risks depending on the agile framework you’re using. SAFe uses the ROAM method at PI-planning events (Planning Iteration – basically quarterly planning across products and the teams working on them). All teams identify risks that might impede their ability to deliver as agreed at the end of the iteration. Risks are talked through with “management” (= typically the business owner, but generally the people ordering deliveries in/changes to a product together with any facilitators, e.g. the Release Train Engineer in SAFe) in a ROAM session at the PI-event.
ROAM is an acronym, labeling how a certain risk is handled:
- Resolved
- Owned
- Accepted
- Mitigated
Starting from the bottom in understanding risks…
Mitigated risks have a plan for being implemented in the iteration. The plan is typically incepted in a combination of suggestions from the team and input from the ROAM session. The team and management agree on the mitigation plan.
Accepted risks are seen as conditions that might impact the delivery. It is, however, crucial for the team to understand the details of the risk and the possible impact.
Owned risks should be handled just like their Mitigated siblings, but no plan could be decided on before/at the session which is why “somebody” – the owner – has the unenviable task of figuring out how to handle it. Hopefully, there are processes and people in place to help owners manage these risks!
Resolved risks are sufficiently handled (mitigated or removed) during the ROAM session or at the planning event (at the latest) making the team confident that they won’t impact their ability to deliver as agreed.
Most organizations use variants on this method for labeling what is going to happen with a particular risk. Some organizations have even implemented “auto-labeling” for their risk handling based on their “category” as a function of consequence and probability – a practice that can be found in several methodologies. My experience is that, while auto-labeling can be a powerful decision-support and prioritization tool, full autopilot in this regard (e.g. accepting all risks in a certain category) is not recommended for understanding risks.
Your risk register tells you different things about your decision-making. Start by sorting out any “non-risks” such as a lack of resources (money or manpower) or other similar constraints that should either be remedied or accepted as conditions (and delivery expectations managed accordingly). The remaining risks and how your (project/agile) organization has decided to handle them, often tell different things about your decision-making.
This does have some active risk management as a prerequisite:
- Someone follows up on the risks, e.g. making sure they’re closed when deemed irrelevant (= they’re not visible in any “active risks view” when they can’t impact).
- All identified risks brought up by the teams (e.g. at a ROAM session or similar) are registered.
Understanding risks: Resolved risks
Keep in mind when understanding risks that this is a different status to a closed risk – at least in SAFe methodology. Resolved risks should still be considered active in the PI they’re brought forward from and the resolution agreed upon at the ROAM session documented in your register. You can close the risks at the end of the PI if you’re certain they won’t have an impact in the future.
If you have a lot of risks resolved right away – well done you! You’re very good at finding resolutions to your risks. This indicates a great decision-making ability at the ROAM sessions (or similar) and the ability to communicate and problem-solve across teams and management.
But consider this: You might have a very “authoritative” management team:
- Inclined to downplay the importance of the risks and deciding to close risks that the team might still find important but they’re not willing to disagree with management (e.g. the business owner).
- If many risks brought forward by the team are easily solved, perhaps the team (e.g. the product owner) should be given greater decision authority and more initiatives towards incubating a team empowerment culture could be beneficial. Especially if many of the risks brought forward are more akin to impediments or smaller dependencies with other teams – all of which the team should be able to handle itself.
Understanding risks: Owned risks
I’ve seen this term used interchangeably with Accepted in practice (disregard what labels are actually used in your organization for understanding risks).
Especially when risks are escalated to higher management levels and handling the risk requires larger commitments of resources or negotiations with other departments or vendors. Any actions taken are sometimes so far in the future and so little is actually done, that the risk might as well be considered Accepted from a team point of view. If risks are escalated, you’ll need to make sure the affected team(s) is sufficiently informed on the progress and that the owner is aware of (and decides accordingly in regard to) important deadlines in the risk. Anything completely dependent on an escalated risk not impacting, ought to be considered a stretch goal (i.e. something the team will work on but can’t commit to as achieving the goal is reliant on factors outside the team’s sphere of influence).
A lot of Owned risks could also signify a lot of ambiguity – either regarding the delivery or how the context (e.g. surrounding organization) will impact the delivery. If the project or working on the product contains ambiguity in itself (e.g. a PoC), make sure that this is reflected in the expectations and the required level of detail and timespan in the planning for the team.
Understanding risks: Accepted risks
Accepted risks are actual concerns that people have about factors that might impede your product delivery, but the decision is to “not do anything” about it. In the majority of cases, there’s (hopefully) a very good reason for accepting the risk. As SAFe says: “Potential problems that must be understood and accepted.”
If there are risks, they’re reflecting conditions in your project no matter the probability or impact. When understanding risks, one risk might have a little impact on the project by itself but a large percentage of Accepted (and often forgotten thereafter) risks could have a compounded effect – even if it’s “just” in team members’ motivation as their concerns might be seen as neglected. I’ve seen risks accepted because they’re either too big or too small to be addressed. However, even smaller risks often have common themes hinting at deeper issues impeding your (short or long term) delivery, quality, employee motivation, etc.
Therefore, if you have a large backlog of “forgotten” risks you should take time out to periodically go through them with your management team to see what kind of decisions aren’t being made and why. For anyone familiar with ITIL this is akin to the problem management process – going through a lot of smaller incidents to see if there’s a common cause that should be resolved. If you’re able to spot common themes, then you could estimate an ROI by the compounded potential impact of the related risks. You can compare your decisions regarding risks with any other investment decision in improving your service and the supporting capabilities – some investments might even have a lower probability of ROI. At the very least you’ll want to set up reassessment conditions and a resulting prompt for each Accepted risk.
An important side note on Accepted risks
Depending on your risk management setup, your Accepted risks might be your “parking space” for active risks that are still relevant but, in practice, it doesn’t make sense to do anything about them (e.g. risks with an extremely low probability). Remember that a decision has been made for these risks = “won’t do anything – other stuff is more important.”
In so far as these risks might contribute to detecting common themes, there’s likely nothing to be gained from trying to make new decisions regarding any single one of the risks (unless some of the reassessment conditions have resulted in a prompt).
Ultimately, there’s a limited amount of decision-focus in any organization and it’s therefore very important that focus is prioritized.
Understanding risks: Mitigated risks
The most important factor in mitigated risks is that they progress. You’d definitely prefer to have your mitigating actions ready – or done – well before the estimated impact date.
You should be able to look at the latest date your risks are updated. If that date = creation date, you might have an issue. A bunch of things could be the cause of this (the lack of allocation, motivation to solve, or perceived importance being some). Look to see if the risk is assigned to the right person in regards to decision-making authority and/or skills, e.g. a mitigation plan which requires tasks to be done by resources across the team, products, or even other departments to be resolved might be difficult for a team member to progress sufficiently. Likewise, if the risk is escalated to someone outside the team, that person might have the needed decision authority and organizational pull but could lack the specialist knowledge to feel comfortable making decisions “before checking with XX” (this should be as short a process as possible – preferably 30 sec. as the person should be sitting right next to them.)
Even though a risk should have a single assignee who’s responsible, you’ll need to make sure that the right mix of competencies and decision authority is allocated to work on the risk. If the risk is escalated, the person assigned the risk should be working closely together with the right specialist/team member(s) = probably the one originally reporting the risk.
Risk velocity
Velocity = [time from inception] – [time to resolution or acceptance]. Try to keep your velocity as high as possible.
The longer a risk simmers in the backlog, the lower the likelihood of any action taking place. Unfortunately, this is not necessarily applicable to the probability or impact of the risk.
As a rule of thumb, risks that are not resolved by people in the project or release train within a set time limit (e.g. an iteration in SAFe) should be escalated to a level outside it.
Risk appetite
Your organization, project, release train, etc. all have implicit or explicit risk appetite which is a function of the size of the estimated impact, the impact date, and the velocity – “how fast do you make decisions regarding things that have a particular impact and how close do you like your close-calls.”
Some organizations have a very low official risk appetite, which might even be explicated in very detailed documentation of decision authority levels. However, in practice their risk appetite is extremely high as their low velocity (caused by lack of decision authority at the team level) results in impact by an unproportionate number of risks that might otherwise have been mitigated or avoided completely.
To re-iterate:
- A decision-empowered culture is, at all levels in an organization, very much a cultural thing. The reaction from management directly impacts how decision-prone the teams are. The more decision-prone teams generally perform better: higher motivation, better productivity, a steeper learning curve, etc.
- Management (and the rest of the organization) should trust that they have trustworthy, competent people working in the teams. Why? Because it is their responsibility to make sure the teams possess the knowledge, motivation, and tools required to do their job well.
Instead of trust, organizations are prone to implement control which is very inefficient – and even detrimental – in ensuring that complex tasks requiring high skill levels are done well.
I hope some of these pointers about understanding risks are applicable in your organization and perhaps can spark the conversation about how you manage risk or make decisions.
Disclaimer: When looking at your risks or trying to find tendencies… Be aware of the dangers of the over-analyzing of, well, basically anything, and of course keep in mind the difference between correlation and causation 😉.
The views reflected in this article are the views of the author and do not necessarily reflect the views of the global EY organization or its member companies.
Benjamin Kyvsgaard
Benjamin has almost 10 years of experience with IT management including vendor relations, service management, and process engineering. He’s specialized in Atlassian’s tools, risk management, and implementing and maturing agile and traditional project organizations from large organizations both in the private and public sector.
