As someone who has reviewed dozens of failures over the years, its clear that the times in which bad software killed a project are virtually non-existent. Whats more common is the projects were poorly run, that specifications werent translated in to a workable system, go-live took place before the data transfer was verified and the users trained: All of which gave the appearance that the main goal of the SI was to latch on to the client and suck as much revenue out of the project as possible, while hopefully leaving things messed up enough to guarantee the project extensions and modifications that could turn the project into an annuity for the SI.
|Enterprise Advisor Columns|
Google Docs: Terms of Disservice or Evil 2.0?
Vista and Office in the Enterprise: The Big Tent Looks Tattered
Undercutting Salesforce.com: Microsoft Prices CRM On-Demand to Move
Who's Afraid of Google? The New Evil Empire
Am I being too harsh? Even when things have gone remarkably well, and the majority of project have been successful, the cost burden of the traditional SI implementation has hampered attempts to get total cost of ownership under control and deliver a genuine return on investment. Again, this isnt just the SIs fault, the vendors have been colluding with them along these lines for years. To the mutual benefit of all. But if you look at the money pot that has flowed into enterprise software over the years, too much, way too much, has ended up with the SIs certainly with respect to the value they have been able to deliver.
So heres to SaaS and its upending of one of the worst things about enterprise software. Marc Benioff of Salesforce.com has definitely exaggerated when he talks about SaaS representing the end of software. But SaaS is definitely heralding the end of the SI, at least with respect to bloated projects that fail to deliver anything but excessive costs. Their demise will be a good thing, even if it means that the vendors have to find a new channel for selling high-end projects to big companies. Its time for the industry to move beyond these issues, and I for one wont miss those over-priced implementations one little bit.