Over the last two decades the road to business process transformation has been cluttered with IT enabled transformation disasters. In the last few years, these are some that we’ve analyzed:
- MillerCoors Sues HCL for $100M for Breach of Contract and is Countersued by HCL
- Bridgestone Sues IBM for $600M in Damages
- National Grid Sues Wipro Stating Costs Exceeded $1B for a Program Initially Budgeted for $290M
- Co-Op Insurance Sues IBM for $100M in Damages
- The State of Oregon and Oracle File Dueling Lawsuits
- After 4 Years, Avon Writes off $125M in Project Costs, Supported by SAP and IBM
- Select Comfort Goes Live with Oracle Too Early Without the Support of an SI and Stock Drops 25%
- City of Anchorage Alaska Budgets $50M for SAP but has Ballooned Over $100M and is Still Growing
What do these examples of recent IT-enabled transformation horror stories teach us? IT implementation disasters come in every shape and every size. They are not specific to a software package, system integrator, industry, geography or company size. Each failure has its own story and its own pedigree.
Hundreds of independent studies, both privately and publicly funded, have been conducted to identify the critical success/failure factors associated with IT enabled transformation. The standard list of failure factors should hold no surprises:
- Lack of executive engagement
- Inadequate business case
- Incorrect software package selection
- Lack of rigorous project management
- Limited end-user participation
- Failing to re-engineer business processes
- …and many more
There is a broad understanding of the factors which bring about project success or failure, so why are there still so many project disasters? Why don’t the methodologies and project management techniques that have been honed and exhaustively written about over the last 20 years always work?
I believe that the answer to this question can be traced back to the failure in one sliver of the program implementation process – Risk Management. IT program risk management processes are specifically designed to identify potential risks to a program, assess the magnitude of the risk, and prescribe treatment that is appropriate to the specific risk level. If executed appropriately, these processes should theoretically incorporate the success and failure factors that have been identified. This leads to the more interesting question… if the IT project risks are already known and there are well established processes to manage risk, then why do the risk management processes fail?
Risk by definition, is not a problem. Risk is the anticipation of a future problem. Risk leads an insidious and elusive existence. It is present and absent, hard to pinpoint but very important. If everything goes according to plan, nothing bad happens. But as the saying goes, without risk there is no reward. The only way to eliminate risk entirely is to do nothing at all, which of course brings its own risks to the business.
I have spent the last several years reading all the research papers I could get my hands on, studying the press as it relates to IT project implementation disasters, and going through all of the IT transformation implementations I have been involved with to identify what goes wrong with the risk management process. From this research have concluded that there are five things that repeatedly derail risk management.
1. Failure to establish the proper context
Risk management processes are often designed around the risks associated with a single domain of risk effects – delivering the project on-time and on-budget. Failing to fully consider risks associated with operational continuity and business case attainment can lead to major gaps in risk identification.
2. Flawed executive engagement model
If executives are not actively engaged in the risk identification process an opportunity is lost to develop a common view of success and to synchronize perceptions of risk. Engaging executives early also enables the project team to develop a more balanced view and take ownership of risk.
3. Not recognizing and addressing biases in the identification and assessment of risks
All of us make decisions that are based upon cognitive biases. Whether cultural, organizationally driven or experiential, we all have them. Failure to recognize these biases can lead to an inappropriate assessment regarding the probability of a particular risk event occurring or the potential magnitude of its impact.
4. Failure to account for risk interrelationships
In an analysis of project risks, it is not always obvious how risks interrelate. Understanding how the realization of one risk might increase the probability of another risk is important in assessing the overall impact of a potential risk.
5. Lack of rigor
Executed properly, risk management practices are embedded into the core decision making, status reporting and deliverable tracking of a program. Failure to scrupulously incorporate the practice of risk management can lead to risk management simply becoming a program cost overhead.