The software vendor may not be the reason why your enterprise software project is failing.
Sometimes it seems that a week can't go by without my hearing about a major enterprise software project failure that will cost a customer millions in lost revenues and a software vendor even more in lost credibility. The scenario is a familiar one: An often incendiary quote by a disgruntled user appears in the press, the software vendor goes into damage control, and the competition tries, sort of, to hide a fleeting but delicious sense of schadenfreude.
The irony is that even though fingers are pointed at the vendor and its software, the actual number of cases when the product is to blame for a project failure is extremely low. What really happened in most of these cases is a combination of factors that affix the blame on a much broader range of parties. In the end, the vendors still bear some of the blame, but, more often than not, some heretofore blameless individuals must also share the responsibility. Here's my short list of the reasons why these projects fail:
The Implementer Did It
The role of the implementer in any software project is one of those classic "damned if you do and damned if you don't" issues. Most companies can't implement big enterprise software projects by themselves, making systems integrators and implementers absolutely essential to project success. But if you dig down into why projects fail, the smoking gun is all too often sitting in the implementer's holster.
There are a lot of reasons for this, starting with technical incompetence and ending in business and project management incompetence. Don't get me wrong; most implementers are highly competent professionals. But the ones who aren't can do a lot of damage — and, by the way, they're often the first to try to blame the software vendor for the project blow-up.
The Salesperson Did It
Just to make sure we're spreading the blame around equally, we have to consider the role of the overpromising salesperson. A lot of projects go south simply because sales promised something the software — and an army of competent consultants — could never actually achieve.
I once participated in a postmortem review of a failed project and found that four different vendor salespeople had lied to the customer in a grand conspiracy to convince the customer that the products under consideration could actually work together. Each salesperson vouched for the interoperability of the products at an RFP review meeting, and the company believed what it was told. The postmortem I attended was in some ways a "premortem" for the hapless customer, which never recovered from the $50 million cost of the project's failure.
The Brinkmanship Follies
There are definitely times when customers have only themselves to blame. One of the most common reasons for singing mea culpa is what I call the brinkmanship follies. It usually goes like this: A company thinks it needs a new software product to remain competitive and begins an urgent implementation project. Three months into the project, someone with scads of political clout decides that the new implementation doesn't match his or her needs. The project team stops what it's doing and begins a series of meetings intended to graft this johnny-come-lately's needs onto the previously well-crafted project design.
All hell breaks loose as other politically connected bosses smell blood in the water and angle for their own role in the scope-creep frenzy. Pretty soon the hapless implementer is scrambling to explain why the project is now so bloated and out of control that going live during this lifetime is largely impossible.
The Death of a Thousand Customizations
I once spoke to a CIO who told me with great pride how he had gotten rid of his overpriced ERP vendor and gone with a low-cost alternative that had saved him several millions of dollars. As we discussed the functionality he required, it became obvious that the low-ball product didn't have the out-of-the-box functionality his business required. No problem, he replied, I can do that with the vendor's toolkit and some third-party products.
No matter that the custom-developed apps would be one-offs supported only by consultants and the third-party products would come from start-ups with shaky financials and project teams that had never supported a customer of this size before. Just a little customization and all would be well, the CIO promised. Anyone care to guess the outcome? Two years later, the hapless CIO was gone and the "overpriced" ERP vendor was back, looking rather cost-effective after all.
The Agile ArchiveWhen it comes to managing data, donít look at backup and archiving systems as burdens and cost centers. A well-designed archive can enhance data protection and restores, ease search and e-discovery efforts, and save money by intelligently moving data from expensive primary storage systems.
2014 Analytics, BI, and Information Management SurveyITís tried for years to simplify data analytics and business intelligence efforts. Have visual analysis tools and Hadoop and NoSQL databases helped? Respondents to our 2014 InformationWeek Analytics, Business Intelligence, and Information Management Survey have a mixed outlook.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.