What's Next: Software for Non-Dummies
Integrating new applications can be easy, if you let it be.
Published February 2003
EMAIL THIS ARTICLE
PRINTER FRIENDLY
COMMENT ON THIS ARTICLEWhat's Next
Magazines like this one make their way in the world by teaching people how to succeed in business. We usually write about success. And when we write about failure, it is as a mournful lesson, designed to ensure that the rest of us never do something like that. But we might anyway. Because there is one area of business where success is rare and failure is the norm, an area that is generally not talked or written about -- software development. If your company is undertaking a project to write its own software, chances are that the project is going to fail. This column is about how to avoid that problem.
Software-development projects fail all the time, no matter what their size. The Standish Group, an IT-research firm in West Yarmouth, Mass., has been keeping track of this phenomenon since 1994, and the good news is that we are doing much better at completing projects than we used to. The bad news is that in 2000 only 28% of software projects could be classed as complete successes (meaning they were executed on time and on budget) while 23% failed outright (meaning that they were abandoned). Those numbers are improvements over a 16% success rate and a 31% failure rate when the first study was done, in 1994.
I can't imagine too many business owners liking those odds, but the picture does get darker. If 28% of software projects were complete successes in 2000, then 72% were at least partial failures. And in software, even partial failure generally means getting absolutely nothing for your money.
According to the Standish Group, more than $275 billion will be spent on software development this year, covering about 250,000 projects. That means that if the recent success and failure percentages apply, $63 billion in development costs will go down the toilet in 2003 alone.
The Standish Group has done a good job of establishing guidelines to improve the success rate of such projects, but I have an even better plan: just don't do it. Don't develop software at all. If the outcome is often total failure, then forget about achieving success and instead work to avoid failure. And frankly, most businesses don't need custom software, anyway. Of course, that isn't the advice you'd get from most consultants, but then most consultants want to write the software for you. Their failure rate, by the way, is no better. The Standish numbers are for professional-development groups, not your nephew the computer geek.
That nephew is an even greater threat, since he generally comes with little experience or formal training. He gets the job just because he is your nephew, which makes him harder to fire and minimizes the true importance of IT in your organization. Still, he seems for that millisecond on the second green like a real bargain. "My nephew knows all about computers! Heck, he can knock out that (inventory system, point-of-sale system, antigravity system, whatever) in no time at all!"
Except that he can't. And even if he is successful in finishing the application you think you need, there is every likelihood that the application will be almost unusable by anyone except your nephew, who instantly gets lifetime job security.
So much for the nephew, but is it better to buy custom applications from a big company, even an IBM or EDS? No. Such custom IT projects fail just as often as nephew projects and cost even more. Few businesses can afford to commit to major projects that are more likely to fail than not.
What a relief, then, that most companies don't need custom software at all. They need accounting, inventory management, order entry, purchasing, and HR services. The requirements for those services are well understood, and the question inevitably comes down to one of building or buying. Do we build our own application or buy one?
Never build. Always buy.
Buy a mature application that has been on the market for at least three years and adapt it to your purpose, running it on equipment you already own. Never buy a 1.0 or even a 2.0 version of any software. Frankly, the name of the vendor doesn't matter as long as the product has been on the market for at least three years and has significant market share.
Whether the application you have chosen runs under Windows, Unix, Linux, or even Mac OS is, from a business standpoint, meaningless. Notwithstanding millions of dollars in Microsoft advertising, no company ever gained business advantage through selection of an operating system. Applications bring value to IT, not operating systems and not hardware.
The important notion in terms of your applications is maturity. If you are being upgraded constantly and you are being forced to upgrade your operating system or hardware, then your applications are not mature. Mature applications will not change much from year to year, and that means savings not only on software but on hardware, too. If you've picked your applications well, you'll have no reason to replace your equipment every three years -- which is what most companies do. The only things in a computer that really wear out are the components that have moving parts or handle a lot of energy -- namely, the hard disks and power supplies. Those items are generally inexpensive. A perfectly good strategy is to replace those components every three years. If you do that, your computers should last well over five years and provide trouble-free service. Your spreadsheet may recalculate a little slower, but the numbers you see will make you happier.
