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.
But even buying off-the-shelf applications can be a mistake if you use them the wrong way. This part is very important. All good enterprise software uses a database into which you throw raw data and then retrieve everything from finished reports to invoices. But how you get from raw to finished can vary greatly even with the same underlying database. If you really want that funny-looking financial report, there are two ways to get it. You can have your programmer or consultant mess with the innards of the database until it generates what you want, or you can leave the database alone and put your effort into creating a custom query that results in the appropriate output. Always do the latter. Never touch the core code of any application, because doing so will be very, very expensive in the long run. If you approach this the right way, the special stuff doesn't break when you update the software. If you modify the software, upgrades become a nightmare.
If off-the-shelf applications still won't do, another alternative is outsourcing, especially to Web-based application suites. Seriously consider that option if you are being courted by companies like Siebel Systems, Oracle, SAP, and PeopleSoft -- outfits that normally target only the biggest customers but are now being driven down market by the tough economy. Don't be flattered, because the major costs of doing business with the big boys are incurred after the sale. Small and midsize companies don't expect that, and it can be a painful lesson.
The question will come down to building a software application or buying one. Never build. Always buy.