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.
Organizational Attitude Toward Changing the Plan
Perhaps the primary difference between classic and agile PM is in the organization’s attitude toward changing the primary project plan via contingency plans. Classic PM expects the primary (i.e., initial) project plan to be pretty good. Functional areas plan their resources and other activities around the primary project plan and hardly give notice to the contingency plans, if they even exist. Thus, changes to the initial plan are not usually welcome news to management. Logically, management accepts the changes, but there is often the undercurrent of judgment that the project manager did not do his job well enough up-front, and that that is the real cause of the change.