Shortly after 2 P.M EST on August 14, 2003, a high-voltage power line in northern Ohio brushed against some overgrown trees and shut down. In the power industry, this is known as a fault. The line had softened under the heat of the high electrical current coursing through it. Normally, the problem would have tripped an alarm in the power company’s control room, but the alarm system failed.
For the next two hours, as system operators tried to understand what was happening, three other lines sagged into trees and switched off, forcing other power lines to take on the extra load. Overloaded, they cut out by 4:05 P.M., tripping a cascade of failures throughout southeastern Canada and eight northeastern states. All told, 50 million people lost power for up to two days in the biggest blackout in North American history. The event contributed to at least 11 deaths and cost an estimated $6 billion.
So what does this have to do with ERP implementation risk management? More than anything, it provides a powerful illustration of the outcomes of cascading failures. This same concept of cascading failures also applies to program risks. You can find evidence of cascading failures when you look into the mitigation activities associated with common ERP risks. Many times, the specific activities associated with the mitigation of the risks are dependent on successful mitigation of a related success factor. These inter-related risks form a network of risks that if a specific risk event occurs, it directly increases the probability of occurrence of other risks in the network.
Here is a simple example:
Key Risk: Inadequate time spent on testing an application prior to deployment
Mitigation: Assure availability of Key Users to Test System
Key Risk: Users unavailable to perform critical project activities
Mitigation: Assure middle management buy-in and support
Key Risk: Middle management does not buy-in to implementation
Mitigation: Top Management Sponsorship
In this example, one may observe how not having top management buy-in could directly lead to the inability to tap into critical business resources for testing. This can either lead to a delay in implementation or worse yet, a critically flawed implementation.
This brings us to Imperative Number 8: Program managers and executive leadership need to develop a fundamental understanding of the risk network. Building this understanding of the risk network allows management to focus early on the highly networked risks to improve the overall probability of the success of the program. Risks that are highly related to other risks have high dependency cardinality. Examples of risks with typically high cardinality include:
• Top Management Support
• Clarity of the Business Case
• Initial Estimates of Budget and Schedule
• Technical Complexity
The second lesson to be learned from the power outage of 2003 is that when one part of the network fails, the load of the system will increase on each of the remaining components of the network. In the case of risk, we will equate the flow of power with the probability of failure. If a particular risk event does occur, then the overall probability of failure or “failure load” will increase on the network or risks. Without immediate attention to develop contingency plans or increase the efforts associated with additional mediation, the probability of a project “blackout” will increase exponentially.
This brings me to Imperative 9: In the event of risk activation, program managers need to reassess the probability associated with all risks that are related to the failed risk to increase the mitigation efforts. Failure to do so runs the risk of a project blackout.