After a long risk management session, in which the project manager (PM) tries to get the team to consider all reasonable risks and opportunities, the PM will ask the wrap-up question, “Are there any other risks we haven’t captured?” Some sarcastic wag will inevitably respond with what he considers to be an out-there scenario: “The building could blow up!” or “The next great depression might start!” The point of these remarks is usually to chide the PM to stop taking everyone’s time spinning improbable scenarios of disaster and just let the engineers get on with their work.

If the twenty-first century has taught us anything, it’s that these out-there predictions have a nasty habit of occurring. In fact, the incidence of these improbable events, and their obvious impact, has inspired a theory that is described in the best-selling book The Black Swan by Nassim Taleb. The author’s proposition, in short, is that the human brain is wired for pattern recognition and so it sees patterns and narratives where none exist. This gives rise to the fallacy that we can accurately predict the future from the past and that events will follow the patterns that we have recently observed. This phenomenon of human understanding causes market frenzies and panics, as investors decide the market will always go up because it went up the last few weeks (or years) or that it will always go down because it has been going down.

The occurrence of risk events previously thought of as remote has prompted much reflection, especially in the financial community. How did our risk models fail us so completely? How did firms Bear Stearns and Lehman Brothers, whose companies depended on robust risk management, allow themselves to get caught in the maelstrom and shipwrecked? All financial firms understand that investors expect enhanced returns for taking on increased risk, so firms must figure out how risk should be priced. The financial community is rethinking and re-evaluating its entire approach to risk management, and the ideas expressed in The Black Swan are influencing risk managers in all industries.

Risk management in IT projects

What does this have to do with risk management in a project context? Plenty, in my view.

Risk management can become a rote exercise, in which project teams will plot out a few obvious problem scenarios, such as hardware that arrives dead or software that won’t install properly, and leave it at that. I’ve even seen teams that have a standing risk list and just append it to their scope document, assuming that the risks (and the contingency measures we should put in place) are the same for every project. Risks are often evaluated in isolation from each other, so that the cascade effects from one negative event are not thought through and managed properly. IT outsourcing, or engaging consultants, is a form of risk transfer; however, many IT consultants and service firms don’t have a grasp of risk pricing, so they allow their customers to shift risk to them without getting the appropriate rewards for taking on that risk.

So, in this new environment where everyone is more conscious of risk management, how should IT PMs change their approach to risk? Here are a few suggestions:

  • Consider the improbable: While it may be unlikely that the next great depression or a collapsing building will impact your next project, we’ve seen that these unlikely events can and do occur. Don’t allow the sarcasm or confidence of your delivery team to defer you from asking the right questions about catastrophic possibilities and from considering how you’ll mitigate these risks. The building may not fall, but the data center could get flooded or lose power, or the delivery truck could get stolen (all scenarios I’ve experienced). Force your team to walk through the less obvious, and sometimes the improbable, and you’ll find that this discussion flushes out some real risks that you must consider.
  • Follow the cascade: Adverse events often have deep cascade effects, reaching out and influencing areas that were thought to be isolated. Anyone who remembers the early days of the mortgage crisis remembers the confident predictions of many economists that sub-prime was an isolated part of the mortgage market and was unlikely to affect the entire economy. In IT project work, I’ve seen this phenomenon when teams don’t plot the intersections of events and requirements and fail to account for the impact that adverse events will have across the entire spectrum of project tasks. The simplest hardware failure or software glitch can cascade across the entire project, but teams are frequently divided into infrastructure, packaged software integration, and development, for example. It’s the role of PMs to ensure that the cross-discipline impacts of risks are identified and mitigated, as the PM is often the only resource on the project looking across all the delivery elements.
  • Beware hidden assumptions: As risk managers from AIG to Lehman Brothers learned, assumptions about what might fail, how it would affect the rest of the portfolio, and what the worst-case scenario might look like are often colored by emotion, ego, rationalization, and self-interest. As any experienced PM can attest, Wall Street traders are not the only self-proclaimed “masters of the universe”; any IT technician who has had a good run can fall into this category. We’re all subject to the risk of believing in our own competence and infallibility, and we all have highly tuned rationalization engines that can convince us that things will work out well because they have so far. PMs must challenge these rationalizations and expressions of overconfidence to ensure that emotion is not impeding the team from uncovering the real risks to the program.
  • Get paid for risk: One of the most prevalent errors I see IT service firms and contract PMs make is to allow the client to transfer risk to them without getting paid for it. Too many firms end up doing rework or free work on projects that were inherently risky, but were priced at the same rate as less risky, operational-type projects. There’s risk in any engagement, whether you’re upgrading Windows or developing an entirely new ERP system from scratch; many firms will price these efforts at the same billable rate, often without a risk contingency budget, and then end up eating the overages when things blow up. I recommend that every project estimate includes a risk premium — that is, a percentage of the estimated delivery cost that is calculated separately for each project and is the result of a distinct team effort to evaluate the risk of this particular project. Presenting the internal or external client with a separate risk premium sends the message that the team has seriously considered the level of risk this project entails. It also prepares the client for the reality that every project will have unknowns and adverse events.

Everyone from Wall Street economists to Homeland Security agents have learned in the past few years that our risk calculations must be broader, deeper, and more encompassing than they were previously. In the world of the IT PM, we must take advantage of the painful lessons of other risk managers and ensure that we’re thinking about the mitigation of even unlikely events and that we’re considering the cascade effects of every risk we identify.

Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!