After a long risk management session at PMI Hyderabad club, in which the project managers share with us their try to get the team to consider all reasonable risks and opportunities, most of the PM asked their team after the session, the wrap-up question, “Are there any other risks we haven’t captured?” Some sarcastic team member 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 tell 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 (fishbone kind of). The occurrence of risk events previously thought of as remote as. How did our risk models fail us so completely?, and the ideas expressed in The Black Swan are influencing risk managers in all industries.
That’s all form me now.
Risk management in IT projects
What does this have to do with risk management in a project context? Risk management can become a unnoticeable 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 knowledge / 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 notable points:- 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 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 get an EMP attack, or the delivery truck could get stolen (all scenarios I’ve seen in real time and experienced the failure of projects due to that). 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, 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, production support, packaged software integration, and development. 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 has learned, assumptions about what might fail, how it would affect the rest of the project, and what the worst-case scenario might look like are often colored by emotion, ego, rationalization, and self-interest. As any experienced PM can confirm, 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 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 blocking the team from uncovering the real risks to the project.
- Get paid for risk: One of the most characteristic errors I see, that 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, IT operational type projects. There’s a risk in any engagement, whether you’re upgrading Windows or developing an entirely new software 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 don’t go in the right direction. I would suggest that every project estimate includes a risk premium. 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 carry. It also prepares the client for the reality that every project will have unknowns and adverse events.
That’s all form me now.
