Risk Management in Jira Align
Author: Elizabeth Wheeler
Jira Align simplifies risk management for organizations by employing the popular ROAM method, which helps teams identify potential obstacles that could adversely affect their ability to achieve the set objectives for an increment (or quarter).
Through ROAM, each risk is categorized into one of four groups:
Risks entered into Jira Align can be visualized using the Risks Grid or, more effectively, through the Risks ROAM Report. This report is designed to highlight specific programs and increments.
However, I've often observed that enterprises and programs adopt risk management in Jira Align without providing further guidance to their teams. As a result, all default fields related to risks are enabled, leading to reports that, while impressive in appearance, may ultimately visualize non-actionable data.
Consider the Risks ROAM Report mentioned above. From this visualization only, consider what information is portrayed:
This is great information, but what can't you see?
The readers of the Risks ROAM Report may assume that risks are being compared consistently across teams and even across programs (when looking at the Risks Grid). However, with no guidance on how to enter risks, the data quality is suspect, and ultimately someone will be fielding questions from the leadership team - not a good use of time, or fun.
Where do I start?
Effective use of Jira Align involves implementing guidance for its features. Notably, as a Jira Align Administrator, you have the capability to customize fields on work items, including risks, according to the portfolio and/or enterprise's needs. This customization ensures consistency within a portfolio, while different portfolios may have different screens.
The screenshot below illustrates a risk work item with all optional fields enabled. Note that within Jira Align, the appearance of your item may vary, as most items can be renamed or have certain fields disabled.
领英推荐
The next image displays the fields admins can enable/disable or make required on the risk work item.
You might notice that this list includes only a subset of all the fields available for risk work items. Fields such as Title, Description, Program, and Program Increment are mandatory and cannot be disabled.
My primary recommendation, applicable not just to risk management, is to offer clear guidance for each enabled field. If no guidance is provided, consider disabling the field. Your process should define how you use the tools.
Furthermore, even if risk screens can vary by portfolio, assess whether such variations are necessary. Achieving consistency in risk management across the organization is highly beneficial.
Having identified which fields are essential and which can be disabled, take the opportunity to tailor the tool to fit your organization's specific context. Remember to publish your guidance in an easily accessible location (e.g., a Jira Align Checklist, Confluence, SharePoint, or even a printed help sheet) for your users.
The remainder of this article offers ideas and discussions to aid in the development of guidance for your teams and, hopefully, your entire organization.
Title - This field is displayed prominently on the Risks ROAM report and in the Risks Grid. Take advantage of this! Implement a standard for how to title risks that communicates more information and makes it easier to read.
Occurrence - It's more than okay to acknowledge this field (and others) are subjective and to encourage users to make an assessment based on the information available now. Additionally, this is a good place to remind users that if a risk is not foreseeable - don't add it. I've seen similar scales like this work well.
Impact - Don't forget to define what the impact is in reference to - the release? the business? the work item? Next, define the scale for your users.
Critical Path - The term "critical path" gets thrown around in a traditional project management setting, but Agile teams are generally not as familiar with the term. If using this field, don't forget to define what it means. I've seen teams use it to quickly note if the risk is related to the critical path of the entire release or simply if it's tied to an MVP work item. As always, simply define it and do what works for your teams.
Target Resolution Date & Notify - These fields are two I suspect lead to more administration than actual benefit - not in all cases, but I'd venture to bet most. Can you or do you shore up risks before the end of planning? Does your team look at risks over the increment where you're continually talking about those that require your attention? If both of these are true, you're doing a great job and probably don't need these extra fields.
Contingency - This is another field, where if you're not careful can lead to more administration than value. Think about ROAM - which category does it fit with? I'd argue it's not applicable. A contingency represents an alternate path, but if the risk is resolved, owned, accepted, or mitigated then that path is theoretically already defined or not applicable. Using the contingency field in conjunction ROAM feels heavy-handed.
In summary, Jira Align is a powerful tool for visualizing how an organization executes its business strategy, including managing risks and dependent relationships that threaten success. Before diving in, clearly define your processes to maximize the investment in this tool.