Risk management works differently in agile project management vs. waterfall. In this article, I highlight the basic differences and offer guidance for choosing the most effective method for your current environment. I also offer four tips for staying on track with risk management when you undertake project management using an agile discipline.
Risk Management in Microsoft Project
If you work with Microsoft Project Professional or Standard versions, you may have tactically added to tasks a custom field for flagging risk. You may even have created graphical indicators for these (to emphasize risk visuals that are important to note), as seen in this figure:
Whether your schedule is lined out in sprints or waterfall, the use of the custom field is a handy way to create and communicate the story of risk tied to a key activity.
If you’re using Project Online or Project Server, you can readily see issues, risks and documents associated to both projects and tasks, coming from the associated SharePoint workspace or Team site.
The following screenshot shows a custom risk field in a project schedule.
Regardless of where or how you manage these, Project provides an excellent conduit both at a task level or a SharePoint site level to manage your project or program risks.
However, what you really need to concern yourself with isn’t just how to store or build out risks, but how to perform risk management, whether the methodology is agile or waterfall.
The Differences of Risk in Agile vs. Waterfall
For this article I won’t go into the details of risk management or discuss all of its moving parts. (For that kind of help, review the link in the box below.) However, I do want to highlight differences between the two methodologies under consideration here.
Want to learn more about risk management? Visit the MPUG risk management archive here.
It’s important not to treat risk management in agile the same way as you do in waterfall. I’ve seen many technical project managers who pursue their traditional risk management approaches only to find that those familiar practices really weren’t adequate.
Let me illustrate this failure with a short story. In my early career, I was part of a U.S. Navy Construction Battalion. The construction branch is a separate operation within the standard Navy; like the Marines, Seabees have different mission focus. We had a split role. We managed and constructed public work projects, but we fulfilled a combat role. During combat training, we learned how to transition rapidly from doing construction work to assuming our combat duties. This transition was critical to our success — that is, surviving in addition to getting work done.
In one of the training exercises, we actually became part of the target team down range of live fire, running up targets for those who were firing off live rounds as we trained. There’s nothing like the whizzing or pinging of live ammunition and seeing tracers flash overhead to make you move faster and give you a sense of how important it is to respond quickly or move in an agile way from doing one job to shifting to another.
To this day, I love to play paintball, which simulates much of the same experience you have in a live combat exercise — minus the dying or major injury part. When you play paintball, the whizzing or splat of a paintball over your head sharpens your reflexes instantly. When you don’t move fast enough, you’ll feel the welt and sting of failure.
Bottom line: Risk management in agile takes on a more active and reactive role that you need to factor into daily activities. With waterfall, you typically have more time to plan, or you have longer projects or more stable environments where requirements don’t change that often. In traditional project management, your approach to risk management is important, but it’s just not as active or ever-present as it is in an agile environment.
Let’s look at the way you handle these role-based differences as well as some tools that will help you in either project management scenario.
Success and Failure with Risk Management
What I love about doing project management are the detailed and robust processes around it. This is just as true for agile as it is for waterfall. On the surface, they appear to be similar since both leverage an “identify-quantify-prioritize-plan-manage” approach. The core difference lies in the frequency of the risk process as well as the management layer.
In waterfall, we do more upfront planning, including mapping out the risks. Because it’s inherently iterative, agile risk management goes through a more cyclical and repeated risk-planning exercise.
Let’s go through the cycle of risk management to find some of the approaches and tools that support great risk management.
Remember: We plan for risks that we know about as well as those that we don’t know about. Agile’s more iterative approach allows for these unknowns to surface and be addressed on a daily basis, especially if you’re using Scrum. In a more traditional approach, you usually identify and plan for only the largest risks. The traditional project’s risks tend to be more predictable — that’s not to say that they don’t dynamically appear. The technical projects tend to have more unknowns, and so they need more dynamic risk management.
Project managers often approach dynamic risk management by listing risks and using a type of probability and impact statement or matrix to quantify these, such as this example of a risk identification matrix:
To organize risks, we also see them listed in tiers. Overall, the idea is for you to have working sessions to identify risks that need to be evaluated and/or managed. The objective is to surface as many credible risks as possible. Then you evaluate the risks that you need to address instead of spending time on risks that may not occur or that have little to no impact if they do.
Remember also that risks can be good.
Typically in technical projects, we define a risk as simply “uncertainty that matters.” Under this definition, risks can also have a positive effect. For example, uncertainty can mean opportunities for your team that have a positive impact on your project. That’s why taking healthy risk is something you actually plan for when you’re creating a solution that has never been built. Your team mitigates negative risks (threats) and exploits positive ones (opportunities) by knowing when — and at what threshold — to plan for risk uncertainty as they through the development lifecycle.
If you’ve led or been involved in a “strengths, weaknesses, opportunities and threats” or SWOT analysis, you may have some experience in identifying these. The same holds true in risk planning and it is especially true for agile projects.
When doing agile project management, you must constantly do risk planning, analysis, and adjustments. Avoiding teamwork on SWOT tasks has led to failed projects or being unable to deliver all the features or capabilities desired by the project.
Agile teams traditionally don’t use any kind of intentional risk management approach because the very nature of the agile project helps you to address risk and communications. But don’t let the nature of agile projects cause you to not do risk management. If you infuse risk management into the project’s daily or sprint cycle, you can ensure success and help a team to stop spinning its wheels and focus on higher priority features. I personally have found that ignoring risk is a huge missed opportunity; that blind side tends to increase project costs because the team has to learn through failure.
Risk Quantification and Prioritization
Once you complete the process and the risk identification, then you can follow best practices and move to risk ranking or the quantification of the risk identified. Common to both agile and waterfall risk identification, you look for key information that will help you rate, rank and prioritize those risks as you identify them.
Some of these factors are:
- Size of risk impact (cost, schedule, work, political, visibility);
- Advanced warning;
- Type of risk (customer, cost, schedule, scope, training, etc.);
- Likelihood of occurrence; and
- Frequency of occurrence.
After listing and detailing all risks in the risk registry, you’ll find it helpful to build or use a risk matrix by assigning values to each identified risk. The example shown above uses three dimensions:
- Probability (likelihood and vertical axis);
- Impact (severity and size of the bubble); and
- Advanced notice (horizontal axis).
In agile risk management you review this matrix and risk register daily if you’re using Scrum or at the beginning and end of each sprint cycle in other agile approaches. Sprints are a set number of days or weeks in which work is done, allowing tasks to be time-boxed. It’s important to think about how these two risk management methodologies implement the risk steps and when they implement them. Risk management in a Waterfall project is a planned step of your project lifecycle. With agile, risk management happens in a more integrated way, such as during each iteration that a project goes through.
In this figure you can see that each sprint, no matter how long it is, is like going through mini planning, execution and closeout cycles.
With agile, it’s important to leverage risk planning early and often. Typically, you validate the risks, surface, and re-quantify the risks at each stage of the sprint.
Tip! Often, I’ll hear from project managers who are making the move from waterfall to agile that they have a hard time finding information on risk approaches. One thing to remember is that in agile projects, risks are often called “impediments” not “risks.” This subtle, but slightly different, terminology occurs in the tools themselves and in the available reference information.
A Risk Comparison Summary
As we look at the cyclical nature of risk management for agile, or even at the core risk planning around waterfall, we find many of the same elements and toolsets. However, there’s one important difference for agile projects: the identified risks can be more technical in nature.
In practice, the goal of a sprint is to produce features and functionality. That means the result must be working code with tangible and visible results to customers.
For technical projects, risks that surface sometimes become issues that you need to address or prioritize. In some cases, you must identify the risks, but you need not address them.
In this process of doing a retrospective, using a risk root cause analysis can be extremely helpful. Through that analysis, technical teams can identify leading causes and prioritize the elimination of these causes or issues in a planned and controlled manner for future releases or sprints.
The figure below provides an example of a root cause analysis tool that is commonly used to prioritize risk causes that lead to overall failures. Instead of trying to solve all possibilities, you can break these root cause suppositions down and begin with eliminating the most damaging risk or potential risk factors.
Remember, helping your team to focus, prioritize, and not be distracted is part of the role of the Scrum master, project manager, feature owner and the whole managing delivery team.
Agile Risk Management Tips
Keep these four things in mind when you’re incorporating risk management practices with agile teams:
- Use the short or small team risk evaluation workshops instead of the large planning session. These shorter sessions help to ingrain risk planning and thinking in the team. They also take less time and avoid the hassle of analyzing risk that might not occur once you start an iterative process.
- Always keep the risk register visible and available to everyone. Using SharePoint, Office 365 or a wiki can be an excellent approach. Just centralize the information and make that collaboration portal — whatever it is — available to the wider team and stakeholders.
- Working with agile teams is a dynamic process; in many cases, they’re self-organized and democratic. At Advisicon, we like to establish one member of the team in the “risk manager” role. That person takes responsibility for identifying and helping to prioritize risks, escalating risk steps, mitigation and contingency plans with the team and stakeholders.
- Don’t overthink risk ranking. In many cases, you can take a team vote or use an electronic tool to simply weigh and rate risks. This practice can help to subdue the loudest voices in the room and engage the team in the analysis instead of championing their favorite risk.
Regardless of the specifics of your projects and whether you’re using a waterfall or agile method, your team is sure to face some unforeseen or little expected issues during development. Preparing for these risks is essential for ensuring your project’s success and avoiding overhead.
Additional Risk PPM Resources
Want to learn more? Check out the Advisicon YouTube Channel, where you’ll find more information about risk management, project management tools, methodologies and best practices.
If you have a template to share with the MPUG community, post a link to it below in the Comments section. If you see a template you’d like to have a copy of in this article, send me email at tim.runcie@advisicon.com and I’ll share an example file with you.
