Following the previous event, on the second or selected day on the PI Planning agenda in Scaled Agile Framework (SAFe), is planning Program Risks.
What are Program Risks?
Program risks are situations that can expose the product or projects to harm. Organizations spend a great amount of time understanding them and devising mitigation strategies to deal with them timely. They should dedicate considerable effort to proactively identify and develop strategies to mitigate risks. However, there is often confusion about what happens after risks are identified during PI Planning. Typically, teams raise risks, and business owners may delegate action items to the teams, but without proper management, these risks can resurface at the most inconvenient times and possibly cause harm to the project.
It is also crucial to differentiate between team-level and program-level risks: team risks should be handled by the teams themselves, while program-level risks require management at the program level. Clear distinction and proper management of these risks are essential to prevent potential disruptions and ensure smooth project execution.
| Team Level Risks | Program Level Risks |
|---|---|
| Team-level risks involve issues affecting the internal workings of the team, such as lack of resources, vacation days, or the availability of individual team members. For example, if a key team member is on vacation, this is primarily a team-level concern. However, if this team member plays a critical role in delivering specific project functionality, their absence can escalate into a program-level risk, potentially impacting the overall project schedule or delivery. | Program risks are broader and can affect the entire program or project. They arise from dependencies, external factors, or other elements influencing the program’s overall success. Unlike team-level risks, program risks should be continuously recorded, monitored, and managed throughout the entire planning event. Addressing these risks proactively ensures potential issues are identified early and effectively managed, helping maintain the program’s health and progress. |
There is often a fine line between team-level and program-level risks, and they may shift between these categories during PI execution. Regardless of their classification, the most crucial aspect is to establish a clear owner and set a due date for any associated mitigating actions. In SAFe, risks are addressed towards the end of the planning event, which can make them appear as an afterthought. However, to ensure that risks are managed proactively during the event with all stakeholders present, they should be continuously recorded, monitored, and actively discussed throughout the entire PI planning event.
Risks managed early are opportunities seized later.
How to Prepare for Program Risks?
To prepare for program risks, start by establishing a system for capturing risks. This could be an in-person method, an online tool like Kendis, or a combination. Relying solely on post-it notes will not be sufficient for tracking and managing risks beyond the PI planning phase, so ensure you have a comprehensive plan.
Additionally, define the statuses that will be used to represent the risk lifecycle. While SAFe suggests R.O.A.M. (Resolved, Owned, Accepted, Mitigated), you might find it beneficial to create other statuses that better align with your specific workflows and risk management processes.
Learn more about Managing Risks with ROAM
How are Program Risks Planned?
This event is typically facilitated by the Release Train Engineer (RTE) with the prime focus being, discovering the program risks and discussing how they can be mitigated.
Program risks are categorized into team-level and program-level risks. Team-level risks, such as resource shortages or vacation overlaps, should be managed within the team and escalated to a program-level risk if they have broader implications. Once escalated, these risks should be added to the program risk board for visibility and management.
Each risk should have an assigned owner, which could be the person who identified the risk, someone responsible for corresponding action points, or a manager, risk manager, or release manager. This ensures accountability and clarity on who is addressing the risk.
During PI planning, risks are typically captured on sticky notes and categorized into four quadrants using the R.O.A.M. (Resolved, Owned, Accepted, Mitigated) framework. Each risk is placed into one of these quadrants based on its status. If possible, assign a resolution date for the risk or, at minimum, a date for the mitigating actions to be completed. If risks are related to user stories, they should be linked to relevant features, milestones, or projects.
The risk description should clearly indicate which part of the execution will be affected. During the PI planning, ensure that risks are categorized, and action points are discussed and documented for each risk. This structured approach helps in proactive risk management and ensures that risks are addressed effectively throughout the PI planning event and beyond.
Top 10 Tips for PI Planning Risks
- Categorize Risks: Identify and categorize risks into team-level and program-level. Team-level risks should be managed within the team and escalated to the program level if they impact broader aspects.
- Assign Ownership: Each risk should have an owner. This could be the person who identified the risk, someone responsible for action points, or a manager or risk manager.
- Create a Risk Board: For program-level risks, maintain a dedicated risk board to track and manage these risks throughout the PI planning process.
- Document Risks: During PI planning, capture risks on sticky notes and use the four-quadrant R.O.A.M. (Resolved, Owned, Accepted, Mitigated) framework to categorize them.
- Update Risk Status: Place each risk into one of the R.O.A.M. quadrants to indicate its current status and ensure it is addressed accordingly.
- Set Resolution Dates: Assign a target date for resolving each risk or, at minimum, for completing mitigating actions.
- Link Risks to Features: If risks affect specific user stories or features, link them to relevant features, milestones, or projects for better tracking.
- Track in Kendis: Use Kendis to track risks within Scrum of Scrums or Sprint reports to monitor their impact during execution.
- Describe Impact: Clearly describe how each risk affects different parts of the execution, providing detailed indications of its potential impact.
- Discuss Action Points: During PI planning, categorize risks and discuss action points for each. Ensure these are documented to manage and address the risks effectively.
Conclusion
Identifying risks during PI Planning is crucial for ensuring successful project delivery. Neglecting these risks can undermine the entire outcome of the planning process. To mitigate this, it is essential to assign someone with the responsibility for ongoing risk identification and tracking after the PI Planning phase. This proactive approach helps safeguard the project’s success and ensures that potential issues are addressed in a timely manner.
To learn more, click here.
