No matter what industry you are in and what working methodology you use, the odds are against your success. Depending which report you look at, analysts find that as few as 31% of projects actually succeed in meeting all their goals. As many as 19% of all projects utterly fail, leaving the remaining 50% floundering somewhere in-between.
So, the question isn’t whether or not things are going to go wrong with your project, but what are you going to do about them? That’s why the first tab in your RAID log is the Risk tab. This is where we assess and plan responses for the risks that can affect the outcome of our projects.
Case Study: Risked if we do, risked if we don’t.
For one project in particular, the wrong risk management approach could have landed me and my project team a segment on CNN.
My team and I were engaged to replace a very key piece of aging infrastructure for a global organization that depended on its massive supply chain to move millions of tons of material around the world every day. This particular piece of infrastructure was key for moving all that material – and it was reaching the end of its serviceable life. The clock was ticking to replace it before it failed.
But replacing this particular part of the infrastructure was very risky. So risky that if we got it wrong, we would take down the entire global enterprise. The supply chain would stop: airplanes wouldn’t take off, materials wouldn’t ship, and nobody in the enterprise would even be able to log into their computer. If that happened, my project would get a special mention on CNN that went something like, “Global organization X went down today, unable to move any materials through their supply chain due to a failed computer upgrade…”
Understandably, the organization was quite risk-averse, so we were going to recommend a very cautious approach, taking our time and building a process to carefully and gradually move each application and each service to the new infrastructure when it was good and ready. It could take a long time – maybe a year or more – but this was the safe way to go.
We were about to propose this “safe” approach when our customer’s technical architect pulled us aside and said, “No, we can’t do that. We should do a ‘flash cut’ and flip all applications and systems to the new infrastructure at once. One huge big-bang.”
My project team was horrified at this idea. Flash cut the entire enterprise at once? Hundreds of business applications? Tens of thousands of devices and systems critical for keeping the supply chain moving? All at once? I could imagine our company name scrolling across the ticker at the bottom of the screen on CNN.
The technical architect’s logic was that it was even more risky to let the organization gradually move over to the new infrastructure a little bit at a time. They tried that before with a similar bit of infrastructure, and 10 years later that migration still was not complete. With the clock ticking on the life of the infrastructure we were supporting, we didn’t have 2 years to wait, let alone 10. In his view, the odds were that the migration would not be complete before it totally failed, creating a great many more issues than would happen if we went for a flash-cut.
So, what do we do? For this risk-averse organization, do we go for the long, slow insidious risk that will eventually catch up with the organization? Or do we rip off the bandaid and force the organization to make a conscious, if potentially traumatic, leap to a new infrastructure? There is risk either way, and the business had to make a well informed decision about how to proceed.
This is what enterprise risk management is all about. Before I tell you how that project went, let’s talk more about risk.
