Chapter 8: Approaching Risk in an Agile Environment

Risk management is one of those areas where the rubber meets the road. Do it well, and you will avoid the numerous potholes and road-blocks that inevitably pop up in most projects. Do it poorly, and you will find yourself in crisis-management mode more often than project-execution mode. This chapter looks at the subtle differences in the mechanics of risk planning in an agile environment versus a classic one. It also covers the not-so-subtle attitudes of how risk management is often perceived in one environment versus the other.

Let's start off by taking a look at a hypothetical business scenario and reviewing the potential impact of classic and agile risk management approaches.

Time to Market

Getting to market as fast as possible is, perhaps, the most frequently cited project management urgency. And this is for a good reason. Financial analysts everywhere are influenced by the "first mover" advantage. Simply put, the first-mover advantage states that the first company to market with a new product or feature will grab the majority of the market share. Of course, there are many other variables that can affect the market share captured by a new product, but the absence of a competitive product is very compelling.

Imagine the business advantages of beating your competition to market and enjoying a temporary monopoly (of sorts) until they catch up. You lock in your current customers, and then convert some of your competitor's customers, thereby increasing your market share. Your increased volume gives you economies of scale and better terms with your suppliers, thus, driving down your costs. You have pricing flexibility, which leads to higher margins. Your project breakeven time is drastically reduced, making future projects that much easier to justify. And the lifetime return on the project has just shot up dramatically, increasing your company's bottom line. All in all, being first to market allows you to create a whirlwind of enthusiasm around your product and within your company.

Product lifecycles are continuing to shorten, and getting to market within the target window (of opportunity) often determines the over-all success of both the project and product. By classic PM standards, the project can be successful (if the scope is delivered on schedule and within cost), while the product is actually a failure. Running too many of these so-called "successful" projects will eventually bring down the whole organization. When presented with a business scenario that requires a course change for the project, you need to remember to equate the project to the current business realities rather than the previously determined, and possibly out-of-date, project boundaries. Now let's see what the picture might look like if you are beaten to market and your competition steals even a small percentage of your customers.

First, assuming your products are essentially equivalent, you have little chance of gaining back any lost market share until your next product release. Your customers needed a product. You couldn't supply it when they needed it (or perceived a need for it), so they went to your competitor (with a little nudging from their sales/marketing efforts), end of story. Second, your reduced volume puts you at a disadvantage with your suppliers, potentially reducing your margins and making it harder to hit the financials for the product. Third, your project breakeven just moved out to the right, making the justification for the next product release that much harder for management to swallow. Ironically, when you are beaten to market, you need to be especially agile in bouncing back to win the next race and can't afford to be spending excess time justifying follow-on projects. Fourth, the lifetime return on your project may have just gone negative. And, guess what, you probably can't just cancel the product because you are committed to the customers that you have managed to retain. You are going to be producing a money-losing product until you can replace it with a better one. Hopefully, you'll win that race.

A more and more common tactic for accelerating timelines is to reduce the scope (i.e., features) of a project/release with the promise of quickly adding the dropped features in the next release (see Figure 8-1). Typically, a move like this is in reaction to one of two broad situations: First, something has happened in the marketplace (external to the project). It could be that a marketing manager catches word of an impending competitive move. He then comes to the project manager asking what can be done to finish up and get to market as soon as possible. Or second, it could be something internal to the project itself, such as technical obstacles that are creating significant troubles in one part of the project and not others. As a result, the project manager has incentive to move forward and complete the project (minus the one trouble area). This is a good example of integrating the project and the business, because to decide on a course of action, the team must consider all of the project dimensions, plus the market analysis, manufacturing cost, scheduling viability, technical support availability for the initial release and upgrade, the overall financial picture, and any other relevant business elements. Usually, this route involves increasing the overall cost and timeline of the project to get to the same scope (as in your original plan), but these actions may be justified, depending on the outcome of the aforementioned analysis.

Figure 8-1: Reducing scope to get to market earlier usually extends the overall time and cost needed to get to the original scope.

So, while a decision based solely on the project characteristics may point us in one direction, when the business dimensions are put into the mix, we are pointed in quite a different direction. Being able to make the right decisions in situations such as these is greatly enhanced if anticipated and planned for as part of a risk management strategy, rather than managed "on the fly" in a reactionary fashion. The classic risk management strategies of mitigation and contingency are applicable in the agile environment, but with slight modifications.

Mitigation

Mitigation plans can be thought of as doing extra work, beyond the original plan, in an effort to prevent the risk event from ever happening. Note that this is not usually chosen as an approach to address a competitive (i.e., external) risk, but it is commonly used for technical (i.e., internal) ones, such as in our example of a technical difficulty in part of the project. This is an effective way to address a risk, assuming that the added costs can be justified. Certainly, if the costs of mitigating a risk outweigh the benefits, then it does not make sense to implement a mitigation strategy.

The key to effectively using mitigation plans in an agile environment is early identification of the risk. The reason is simply due to the time horizon under which such a plan can be created and implemented. In the classic paradigm, we may develop a detailed Gantt chart up-front for a six-month project, thus leaving a pretty long period in which to identify risks and develop mitigation plans. In the agile scenario for the same-length project, we may have a network diagram with six major milestones, but only a detailed Gantt chart through the next milestone. If the risk is within the window of the next milestone, there may not be adequate time to efficiently create and implement a mitigation plan. However, if the identified risk is three milestones out on the network diagram, there will be quite a bit of time to develop a mitigation strategy that can be woven into the detailed plans leading up to that milestone.

Agile Strategy

When using mitigation plans in conjunction with the agile planning approach, be cognizant of the time horizon available in which to plan and implement the mitigation, once the risk is identified.

Contingency

Contingency plans can be thought of as subsets of an overall project plan that get filed away. They are only used if the specific risk event does occur. The objective of a contingency plan is to neutralize the impact of a risk to your project, and it can be just as important as the primary project plan for high-priority risks.

The key to contingency planning is to be able to identify those few risks that are worth planning for. After all, it is not efficient to create contingency plans around every identified risk. The ability to categorize the identified risks as a "high enough" priority is necessary to make this process work.

The general goal of contingency plans is to develop alternate pathways to circumvent potential problems, if they should present themselves. This lends itself well to the agile planning approach of using network diagrams to map the various possible pathways since analysis of these pathways can help you plan for the potential direction that the project will take. In fact, you could say that contingency plans are integrated into the overall agile plan right from the start, albeit at a high level, where the contingency is equivalent to an alternate path that the project may take at a predetermined decision point.

By standing back and studying all the possible project pathways, you are able to gain the 20,000-foot view necessary to take in the whole project. If you then assign weighting to each branch of a decision point, based on what is most likely to happen, not what you want to happen, you will start to see the higher-probability pathways emerge (see Figure 8-2). From here, you can take the necessary actions to guide the project forward. For example, a project manager may decide to extend the detailed planning process past the next foreseeable milestone or decision point, if there is a high enough probability that a particular pathway will be taken.

Figure 8-2: Network diagram with probability weighting assigned to various pathways.

Agile Strategy

Prioritize the already-defined pathways of the network diagram so that you can focus your team's energy on the most likely paths.

Classic project planning is centered on creating a single, primary plan. When using this approach, contingency plans are generally focused on circumventing an obstacle, then getting back onto the primary plan. Since agile project planning involves looking at multiple possible project pathways, contingency planning involves more analysis of the pathways, so you can best guide the project toward the next milestone. It isn't necessarily focused on returning to the primary pathway. (See Figure 8-3.)

Figure 8-3: Contingency planning in an agile versus classic environment.

In the end, the classic and agile approaches to risk management are very similar. The core classic methods are very effective, and they need not be abandoned in the agile environment. However, the shorter, detailed planning horizon makes classic risk management methods more time-sensitive to implement when using the agile planning methodology. Agile projects are inherently more reactive due to the high uncertainty, and this is also true of agile risk management. This deficiency is strictly related to the shorter, detailed planning horizon, but it can be compensated for by some high-level anticipation of possible project pathways. The workflow at the end of this chapter provides a guideline for sequentially thinking through the mechanics of the risk management process. However, while having good mechanics around risk management is necessary for success, a potentially more critical element is the organization's attitude toward it.