IT implementations - especially compliance software implementations -- can go awry in many different ways. Here are some of the worst.
Like Indiana Jones' fear of the mysterious, booby-trapped Temple of Doom, your wariness of IT implementations is justified. And like Indy (Harrison Ford), you can avoid the booby-traps. Success depends in part on approaching implementation as a change management issue, not an IT project.
After years of suffering with that old legacy computer system and old compliance software -- patching, reworking and using Excel to do reporting -- the board has finally approved an upgrade to a state-of-the-art system. You, having been such a vocal advocate for change, have been appointed the sponsor for the project. At last you can show them how it should be done!
A week later, you start considering what needs to be done, uncomfortable thoughts start creeping into the back of your mind. Which was the last successful computer implementation you can remember? What happened to Joe who oversaw the last debacle? It then hits you: This time, YOU are responsible!
Your fears are rational. Forty percent of IT projects are unsuccessful and 25% fail to produce a result at all. What in the world goes wrong? Let's take a look.
At first you may think that you can’t go wrong if you buy IBM or SAP solutions. But then you remember reading about the Queensland Health IBM disaster. So you hire consultants to identify your requirements and get IT to source and evaluated possible suppliers. You select the Oracle solution (very impressive presentation) and hire a large, established firm to implement it.
IT appoints one of their BAs to liaise with the supplier’s BAs to ensure they interpret the consultant "use case" specification. Then IT hires a project manager due to his strong adherence to PRINCE2 methodology. You're all set, then. The project starts. Within in month you start receiving charts and graphs, showing everything on track.
Two months pass and variations start coming in. The delivery date slips six weeks into the future, and the cost increases 5%. But that's still OK. IT set up a test environment under formal change protocols, and contracted professional testers.
Another two months pass. You get more charts and reports, all on track. But now IT informs you they need to upgrade hardware and comms. to run the new software, and that comes out of your budget. The supplier has released a new version, and you decide to take it up due to its additional features. One month later you are informed there is a three-month slippage as all the work to date must be reconfigured for the new version and hardware. Oops. Then the IT manager resigns and takes your BA with him.
The supplier finally provides a prototype for testing. But now the internal Oracle expertise is lacking, so you contract someone. You lose another month and the cost goes up again. Testers give the system a big workout producing 25 pages of fixes required, half of which the supplier rejects as out of scope. You negotiate and agree an 80% fit with another 10% cost increase. Changes are made, passed by the change control committee, implemented and retested, and suddenly another three months have gone by.
Finally, user-acceptance testing commences -- and all hell breaks loose. Staff don’t find the software useable. The functionality doesn’t really work the way your business does. The amount of input slows processing and increases manpower costs. IT inform you that you really need an additional BI module to get the analysis you expect.
The economy contracts and the CFO calls for a review of the project. The project is now 9 months overdue and 50% over budget with little justifiable additional benefits from the original proposal. Further, the supplier just provided a quote to implement the findings of the user review of the system, which amounts to a 25% price increase plus $150,000 for the BI solution (whatever that is). You are starting to feel like you are starring in the film "Groundhog Day," and you notice that, unlike in the past, you are not being included in other management meetings.
How did it all go wrong? Simply put, you treated the whole endeavor as an IT project and not as a change management issue. The first problem relates to the selection criteria of the system and supplier. Here I refer you to our 10 Essentials handbook.
Next time we will look at a detailed review of these events and how we suggest things should be handled differently.