How software implementations fail

The doctor’s comment from my last post leads me neatly onto posting about what is broken about today’s models of enterprise software in general (and enterprise e-sourcing software in particular).

Here’s a take on how your average enterprise software deployment fails to meet expectations: 

1. Someone in “the business” figures that a software tool will help address a particular business objective. After all, they were at an industry conference recently in which a company spoke about the tremendous benefits it achieved by adopting solution XYZ.
    
2. They issue a list of requirements to potential software vendors …
    
3. … who all agree that their software is capable of meeting those requirements.
    
4. The business then identifies a consulting partner to manage the implementation.
    
5. Implementation of the software begins with everyone in high spirits.
    
6. Then everybody realises that the business processes are a lot more complex than had been assumed in step 1.
    
7. To compound this, it turns out that when the software vendor had said their product was capable of meeting the requirements, they neglected to mention that this would only be at considerable customisation costs.
    
8. More money is thrown at the project.
     
9. Then the business decides to change the requirements. (Repeat steps 6 to 8 for as long as $$$ and enthusiasm allow. Remember that the consulting partner is charging day rates for this so won’t be overly upset. Or if you thought you had a fixed price agreement now is when the change orders start flying thick and fast.)
    
10. The project is going nowhere. Exhaustion sets in and finally everybody agrees to implement something approximating the original set of requirements. The software is only just about being used.
     
11. The system is declared “live” to great fanfare from the project team, and indifference from the people who are supposed to be using it.
     
12. Just when everyone thinks the project has finished, someone checks back to see how well the software system has delivered against its original objectives. No-one can remember the original objectives.
     
13. Various options now exist: Scrap the system (or scale back the implementation scope), point fingers, hire more people to operate the new system etc etc. Some or all of these options get played out.
     
14. Eventually the dust settles. Project sponsor, consulting partner and software vendor all agree that the project was a tremendous success. Press releases, glowing resumes and presentations at industry conferences follow.
     
15. …….. time to start again with the next customer.

Has Software-as-a-Service / On Demand solved all this? Not necessarily, is the simple answer, you realise, when you speak to some of the people who actually have to use this stuff.