The software vendor may not be the reason why your enterprise software project is failing.
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.
Visit our Intelligent Applications community for news, analysis, and practical insights to help you gain business value from new and existing technologies for enterprise applications.
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.