5.10 The Cost of Risk Management

< Day Day Up >

At some point, risk planning needs a financial context. This can be played in two ways, assuming, of course, that the risk is significant to one or more project stakeholders.

Buy insurance. You pay a premium, for instance, $1000 a year for full coverage of your automobile for liability, theft, collision, and medical risk that could cost you millions if you had to pay those bills out of pocket. In the project world, you may similarly decide to spend additional sums up front in the hope of avoiding a geometrically higher cost should that risk come to pass. Renting a tent for the wedding reception fits this category. In the real IT world, examples of this strategy include bringing on additional consultants to get a better comfort level that programming will be done in time or buying swing servers to make server relocation projects less prone to production outages than would be the case with "hot cut" moves.
Save money for a rainy day. You may determine that the best way to deal with a risk is to allocate money to fix the problem should it occur, but do nothing else about the potential problem in the interim. That is an appropriate strategy under some conditions, but it would be great to have the money if you actually needed it for that purpose. You may get an increase in funding, or you may chose to cut back on discretionary expenditures to escrow those contingency funds. In one project, we did just that by canceling a "nice to have" deliverable. The savings were earmarked for loading up on temporary resources that we were pretty sure we would have to deploy at the 11th hour. Given that this particular risk was paying an enormous late penalty fee, reallocating funds to obviate that sanction was an easy choice to make.

Of course, by the time each person raises his or her hand for risk mitigation money no matter what its basis is, your budget is most certainly not up to the task. As a result, decisions must be made on which risks truly deserve funding, and which will have to be dealt with some other way should they come to pass. Years ago, I was exposed to an interesting, if simple, manner of evaluating risk from this perspective:

Estimate the cost associated with remediation (or damage control)
Multiply that by the probability of its occurrence

To illustrate this, suppose the remediation of an identified risk costs $100,000 for engineering, hardware, and software, and that the probability we would have to invoke that Plan B is 25 percent. Then, the risk value of this scenario comes out to $100,000 × 25 percent = $25,000.

You can perform this calculation for all presumed risks, then rank them against each other to help prioritize your risk planning, at least from a budgetary perspective. Of course, the problem with this approach is if you use it at the office but left your common sense and political acumen at home that day, you could make some very strange decisions. For instance, one could make a compelling case, particularly after September 11, that if the data center vaporized, we would lose a billion dollars of productivity and customer good will. ^[3] Quantifying this risk as being discussed would yield a risk value of $10 million ($1,000,000,000 × 1 percent). This number would no doubt be far higher than any other calculation for your project, even though its occurrence is unlikely, September 11 notwithstanding.

There is a more useful way to apply this algorithm. Let us look at the data center loss another way. Suppose, as previously alleged, that the "smoking hole" would result in a loss of $1 billion in productivity and customer good will (i.e., business), and that the probability of this happening is 1 percent. The math tells us $1,000,000,000 × 1 percent = $10,000,000.

Ask yourself if it is possible to provide disaster recovery for that data center for $10 million. In other words, could you build a mirrored site, rent processing power at a vendor site, or duplicate the mission critical applications several hundred miles away for that $10 million? The answer may be yes or no, but you can see how this clarifies the risk assessment conversation.

Maybe, once you drill down, it would cost twice that much (i.e., $20 million). So be it. Document the results of this analysis and hand it back to the potential victims. Let them decide whether kicking in an additional $10 million makes sense to them. Be sure they understand that without that support you are restricted in what you can do, and what the likely consequences would be to the user community. In other words, tell them what risk you could mitigate for $10 million or whatever number your analysis yields. Keep in mind that any significant risk ultimately belongs to the business, not the project, so there is no reason you should be left to tangle with this on your own. If the customer or beneficiary feels the project should carry the financial burden, then you need to draw on your management's ability to negotiate with their management, especially if this conversation turns ridiculous or nasty, which it often does.

Present your analysis and let them make the call, but do not do that by tossing it over the wall to them. Instead, I recommend the approach of saying, "Bill, I think if such and such is done, the impact to your organization is basically neutralized. The problem is that I do not have the $100,000 (or $10 million) it would take to make this problem go away. Can we talk further about the need to address this and how to make up any funding shortfalls that decision would create?"

This last statement falls in the category I call "chuck and duck," (i.e., something you cringe in advance of saying because you anticipate grief in return). This would be one of those times as a project manager that you get to tell a beneficiary that your project is going to cost his organization time, money, or pain. That may sound hypocritical if not mercenary, but these things happen in the corporate world every day. Besides, chances are that you personally did not create the risk and, further, that it is the tenuous or unforgiving environment in which your project labors that is largely to blame. Take the approach that you are the good guy trying to minimize collateral damage, not create it.

^[3]Even though insurance would eventually pay to reconstruct the lost site.

< Day Day Up >