Casting Stones - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Software // Information Management
News
5/5/2004
05:13 PM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

Casting Stones

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.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
News
Think Like a Chief Innovation Officer and Get Work Done
Joao-Pierre S. Ruth, Senior Writer,  10/13/2020
Slideshows
10 Trends Accelerating Edge Computing
Cynthia Harvey, Freelance Journalist, InformationWeek,  10/8/2020
News
Northwestern Mutual CIO: Riding Out the Pandemic
Jessica Davis, Senior Editor, Enterprise Apps,  10/7/2020
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
[Special Report] Edge Computing: An IT Platform for the New Enterprise
Edge computing is poised to make a major splash within the next generation of corporate IT architectures. Here's what you need to know!
Slideshows
Flash Poll