Casting StonesCasting Stones

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.

Training is for Wimps

This is one of my favorite reasons for project failure, because it is so pervasive and so, well, just plain ridiculous that there ought to be a law against it. A company spends millions of dollars, thousands of hours, and tons of political capital implementing a new enterprise software suite and then decides to give its users a single, eight-hour training session.

To make the scenario even more pitiful, people who love teaching like the rest of us love heartburn do the training, using materials that could put an insomniac to sleep in the middle of a hurricane. The hapless users, already anxious because the rumor mill has been intimating that the new software project will result in massive layoffs, are now convinced they're all about to be fired because there's no way any of them actually have enough training to be competent. The new software system starts to grind to a halt, productivity heads for the toilet, and senior management starts looking for a plug to pull.

The Management Factor

At the end of the day, for the majority of failed enterprise software projects, the buck more often than not stops at the CIO's or CEO's desk. If you look at the reasons I've listed, bad management seems to be the overarching culprit for almost every project failure. Maybe the "bad implementer" problem is one that even good managers can't avoid — many of the implementers that have been tied to major project failures are from reputable firms that most top managers would expect to do a top-notch job. But in every other case I've mentioned, what has really happened is a massive failure by management to understand what goes into successful enterprise software projects and, to be blunt, act like responsible managers.

And just to be fair, by the time a project failure becomes public, the vendor gets to share the bad management rap as well. Because behind the scenes of any public failure is a hundred lost opportunities by the vendor to make things right. Again, bear in mind that the software usually works well enough. Which means that if the vendor lets the problem get so bad that it has to be aired in public, the customer relations' process has gone sour in ways that should never have happened in the first place.

So the next time you read about an enterprise software project failure, think management failure first and software failure second. Which is why I always like to respond to queries about software project failures by stating my project failure mantra: Bad software doesn't kill companies, bad management does.

Joshua Greenbaum is a principal at Enterprise Applications Consulting. He researches enterprise apps and e-business.