If you work in system integration projects, you have likely wondered how to manage project risks within your organization’s chosen Agile approach.  This is a topic seldom discussed in certification courses for Agile-based approaches such as Scrum.  The two major reasons for this are:

1. Most of these courses focus exclusively on team-level Agile.  In other words, how does a small team of individual contributors work together under the Agile approach?  Individual small teams tend to work on smaller efforts that require much less coordination.  In most of these situations, formalized risk management is overkill.
2. Managing risk is baked into Agile because Agile is an inherently empirical way of working.  Since Agile development is iterative and incremental, teams narrow the scope of what they build to fit within short time frames.  This enables them to, quickly and frequently, build, test, fix, deploy, evaluate and change what they build, and how. Every iteration of value delivery brings multiple opportunities to address risk “in real time.”  In other words, Agile spreads risk management across the entire development effort.

However, system integration projects are typically large and complex, with multiple teams working across organizations while managing multiple dependencies.  The larger the project, the more risk project sponsors and stakeholders assume.  A formalized approach to risk management becomes a priority.

So, what does a formalized Agile risk management approach look like?  It looks a lot like a traditional risk management approach with three main differences:

1. Agile risk management is more adaptive than predictive
2. Agile projects perform risk management activities more frequently and faster than traditional projects
3. Risk management activities in Agile projects are much more coupled to project execution than in traditional projects

Before describing a formalized Agile risk management approach, let’s level set understanding about project risk management.  Along with the short background provided here, I highly recommend reading this article from pmi.org about risk analysis and management.

Risks, Opportunities, and Issues

The third edition of the Project Management Body of Knowledge (PMBOK Guide) defines risk as:

An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.

Project Management Body of Knowledge (PMBOK Guide), Third Edition

By that definition, risks are not just harbingers of negative outcomes.  They may also be opportunities to affect positive outcomes.  Once a negative risk becomes reality, it becomes an issue.

Risk Categories

Categorizing project risks is helpful.  Doing so facilitates risk tracking across the entire project scope.  It also communicates that risk management is everyone’s job, not just that of project management.  Table 1 lists a typical set of project risk categories and their associated extended categories[1]:

Risks belonging to the external, organizational, and project management categories are typically:

• Closely aligned to high-level project concerns outside the control of development teams
• Less dynamic and fluid than technical risks
• Almost exclusively in the realm of project and program management and/or product management

Much of Agile literature and training narrowly focus on technical risks. This aligns with their focus on Agile execution by small teams.  However, external, organizational, and project management risks often impact projects far more.

The Risk Management Cycle

Both traditional and Agile projects execute the activities of the Risk Management Cycle depicted in Figure 1.  Table 2 lists and describes each activity of the cycle[2]:

Predictive vs. Adaptive Planning

Risk management is an important part of project planning.  Traditional project management engages in predictive planning, while Agile performs adaptive planning.  The chosen planning approach affects how projects manage risk.

Traditional project management tries to account for all project tasks and milestones upfront.  Agile planning breaks up the planning horizon into increments. These increments facilitate changing plans when circumstances change.  To be effective, a project’s risk management approach must align to the chosen project management approach.

While all projects, whether they adopt a predictive or adaptive planning approach, perform every activity of the Risk Management Cycle, they emphasize different activities.

A predictive risk management approach emphasizes risk forecasting (prediction) and analysis. Risk analysis entails determining the probability of occurrence and expected project impact of individual risks.  The rationale is that the earlier project managers identify and prioritize project risks, the sooner they can address them before they become issues.

An adaptive risk management approach emphasizes keeping risks small by defining, developing, and delivering system functionality iteratively and incrementally.  This allows teams to handle risks while their potential for project impact is small and to continually monitor risks as solutions evolve and grow.

Traditional vs. Agile Risk Management Characteristics

I’ll now discuss the key differences between how traditional and Agile projects manage risk.

Traditional Risk Identification and Evaluation

Traditional projects develop and execute detailed plans that span the entire project timeline.  Project management often breaks up larger projects into planning packages as part of “rolling wave planning”, but each of those planning packages are themselves detailed plans.  Project plans are based on the resources needed to complete the entire scope of deliverables at a certain cost (The Iron Triangle).

Project plans start with requirements definition.  The entire set of approved requirements defines project scope.  Changes to requirements mean changes to project scope, which translate into schedule and cost changes.

Similarly, traditional risk management tries to identify and evaluate project risks and opportunities prior to or at the start of projects.  While risk management is supposed to happen throughout a project’s timeline, traditional projects tend to perform the bulk of Risk Identification and Evaluation upfront.

The problem with this arrangement is that people cannot predict the future.  The larger and more complex the project, the more likely project requirements and risks will change. 

Traditional project management develops and executes plans assuming requirements, and the design approaches that implement them, are inherently correct and will not change.  This opens projects to the greatest risk of all:  building the wrong thing.

Risk Identification and Evaluation activities in traditional projects often cannot keep up with the accelerated pace of modern software development. In many organizations, risk management is relegated to weekly or monthly risk management boards.  By the time a board adjudicates a risk it may already be an issue.

Agile Risk Identification and Evaluation

While some degree of upfront Risk identification and Evaluation happens in Agile projects, the planning horizon is typically far shorter than that of traditional projects.  Also, most Risk Identification and Evaluation of technical risks happen as part of development, rather than resulting from a separate risk management process.

Traditional Risk Handling and Controlling

Traditional (Waterfall) projects typically get one pass through the Software Development Lifecycle (SCLC).  That pass is strictly constrained by schedule, resources, and cost.  As a result, there is often little room to add risk management activities to the schedule.

Project managers and developers are incentivized to deliver according to plan.  This puts pressure on them to ignore risks until they become issues.  They also forgo opportunities in favor of “flying the plan.”

Agile Risk Handling and Controlling

The Agile SDLC is fast moving and iterative.  Every feature software development teams deliver goes through its own “mini-SDLC”.  Agile planning coupled with DevOps automation support this:

• Agile provides frequent opportunities to evaluate what development teams build and how
• Adaptive planning allows sponsors, stakeholders, and development teams to change requirements, plans, and approaches
• Teams add risks to their work backlogs and prioritize them, thus integrating Risk Handling actions into team workflows
• Shorter development timeframes with frequent deliveries / releases provide: 1) More frequent and earlier warning of emerging risks; 2) More feedback from which to gauge the effectiveness of risk management efforts

Recommended Approach

The Agile SDLC improves management of technical risks.  However, as stated earlier, external, organizational, and project management risks often impact projects far more than technical risks.  Agile teams have the flexibility to manage technical scope.  They have far less control over funding and major project milestones.

External, organizational, and project management risks influence the overall business or mission context within which teams develop solutions.  Project leadership must actively manage these risks before they impact the work of development teams. 

Agile projects should leverage traditional risk management tools and techniques to manage more strategic, slower-moving risks.  Project leaders would then work with development teams to translate such risks into actionable work items and prioritize them.  All project members should have access to risk management reporting and the ability to submit risk candidates as part of their work.

Conclusion

Too often, risk management gets short shrift, especially in Agile projects.  Risk management is an integral part of project planning, regardless of the software development approach employed.  Combining Agile requirements definition and planning, with DevOps automation, and a robust risk management process helps teams deliver valuable software capabilities, cost-effectively, and in time to be valuable.

[1,2] Lavanya, N., Malarvizhi, T., “Risk Analysis and Management,” Project Management Institute, 3 March 2008, https://www.pmi.org/learning/library/risk-analysis-project-management-7070

---

Last Updated on February 2, 2022