Tag Archives: Business Value Risk

A Broader View of Risk Management for Agile

I recently participated in a LinkedIn discussion on risk management that was heavily focused on a conventional approach to risk management built around a plan-driven approach to project management. I wanted to share my thoughts on a broader view of risk management for Agile project environments as well as a traditional plan-driven project management environment.

First, let me preface this post by saying that I’m not an “Agile zealot”. If you’ve read any of my other posts or books or taken my training courses, I’m sure you recognize that I think that there is a widely-held misconception that:

  • “Agile” and “Waterfall” are polar opposites of each other, and
  • There is a binary and mutually-exclusive choice between the two approaches

I think we need to broaden our view of project management to see “Agile” and what is commonly called “Waterfall” as complementary to each other rather than competitive and recognize that traditional plan-driven project management is not the only approach to project management. I prefer to think of a continuous range of alternatives from heavily plan-driven at one extreme to heavily adaptive at the other extreme that looks something like this:

Increasing Agility and Adaptivity

And, the right thing to do is to fit the approach to the project rather than force-fitting a project to some arbitrary model (whatever it might be – Agile or plan-driven). One of the biggest characteristics that would influence the choice of an approach is the level of uncertainty in the project.

If you think of a broader approach to project management in those terms, it has a big impact on how you might do risk management. Here’s how I see some of the key differences in a risk management approach that might be associated with a more adaptive approach to project management in a very uncertain environment:

Why is Risk Management Different in an Agile or More Adaptive Environment?

  1. Definition of “Failure” – Risk is associated with the failure of a project, so how you define “failure” has a big impact on how you do risk management.
    • In a traditional plan-driven project, the requirements of the project are typically well-defined and a “failure” would normally be associated with failing to deliver those requirements within the required cost and schedule budgets allocated for the project. In that kind of environment, it wouldn’t normally be considered a failure if the project met the requirements it was supposed to meet within the cost and schedule goals but failed to deliver the appropriate business value.
    • That approach works fine in an environment where it is possible to relatively accurately define the requirements of the project before the project starts and three is a reasonable level of certainty that if you meet the defined requirements, the project will automatically produce the appropriate business value that is required.

    • An Agile or more adaptive approach is best in situations where it is much more difficult to define detailed requirements for the project prior to the start of the project and there is far less certainty of what is required to produce the appropriate business value. In that kind of environment, there is a much larger risk that the project won’t produce the required business value even if it does meet the defined requirements within budgeted cost and schedule goals. That’s a very important difference between an Agile (or adaptive) approach and a more traditional plan-driven approach.
  2. Relationship to Upfront Planning – Since an Agile approach normally has a lot less upfront planning, it typically requires a more dynamic approach for identifying and managing some of the risks while the project is in progress rather than a comprehensive approach to identify and anticipate risks before the project starts.

    Note that this is not an all-or-nothing choice between zero upfront planning and highly detailed and rigid upfront planning – the approach to planning could be anywhere between those extremes and the approach to risk management should be consistent with the level of planning.

    The important point is that it just isn’t practical to take a comprehensive approach to identify and anticipate all risks in a project with a very limited amount of upfront planning.

  3. The Relationship to Business Value – The risk of not producing the appropriate business value in a very uncertain environment is a very different kind of risk and requires a different kind of risk management approach. That kind of risk isn’t necessarily totally black-and-white – you could produce a relatively mediocre product that met the letter of the requirements but really didn’t provide much business value.

    A conventional approach to risk management is generally based on avoiding and eliminating risks and uncertainty as much as possible so that the project will deliver predictable results, but that approach can work against you if you have a goal of maximizing business value. (See my previous article on Management of Uncertainty in Agile Projects).

    In many cases, risk is associated with opportunities to provide a higher level of business value. With a conventional approach to risk management, you might try to reduce the level of uncertainty and ambiguity associated with user requirements as much as possible prior to the start of the project and you might also tend to favor a low risk approach of using tried-and-true technology rather than “pushing the envelope” a bit to use riskier technology that might provide a higher level of value to the user. From a conventional risk management perspective, that may be the right thing to do but it could easily result in a very mediocre product that doesn’t provide much business value.

How is the Approach to Risk Management Likely to be Different in an Agile environment?

Some people might think that risk management isn’t appropriate in an Agile environment – I don’t believe that to be the case. You can do as much or as little risk management as needed depending on the nature of the project – it just requires a different approach to risk management.

  1. It needs to recognize a broader definition of “failure” – a project can fail by failing to deliver business value even if it meets defined requirements and meets its cost and schedule goals
  2. The approach to risk management needs to be consistent with the overall level of upfront planning in the project – that might mean a less comprehensive identification and analysis of risks prior to the start of the project and a more dynamic approach to risk management as the project is in progress.
  3. Instead of seeing all risks as a bad thing that should be avoided and eliminated, we need to recognize that some risks are related to opportunities. For that reason, a decision to avoid or eliminate risks needs to consider the impact of potential missed opportunities as well as the impact of the risk.

Advantages of an Agile or Adaptive Risk Management Approach

In fact, an Agile or adaptive approach can have a lot of advantages for developing a very effective risk management approach. Steve Gordon commented that Agile or adaptive thinking provides the ability to structure a project to fail early and inexpensively to minimize the impact of a risk on the overall project. Wayne Mack also suggested several more specific risk management advantages that an Agile or adaptive approach can provide:

  • “Technical risks are addressed through early prototypes (“spike stories”) and side-by-side comparison of alternatives (‘A/B testing’)”
  • “Integration risk is mitigated through early and continuous integration. User acceptance risk is mitigated through early product review”
  • “Cost and schedule risk is mitigated through incremental releases – we always have something to show for the money spent; it is no longer an all or nothing trade-off”