HealthCare.gov famously failed at launch, not delivering what was promised. Depending on whom you ask - and whom you believe - the cost to taxpayers ranges from $654 million to well over $1 billion. If, as Professor Van Helsing said in Bram Stoker's Dracula, "We learn from failure, not from success," there are surely important lessons here. Whether we do learn from them - and apply what we've learned to trucking software projects - is something else.
Clearly, past software-project failures don't prevent new ones: HealthCare.gov joins a long string of spectacular initial failures by government and private industry, and isn't the worst by a long shot. Other government-sponsored programs have taken more time and larger chunks of taxpayer money, only to be completely scrapped in the end.
Of course, government software failures are very public and, because of their scale, generally quite costly. Private industry, on the other hand, seeks to conceal its failures and often succeeds - but its failures seem no less frequent.
Reported software disasters include McDonald's Corp., which canceled a purchasing software project in 2004 that had cost $170 million. And in the same year, Hewlett-Packard lost $160 million and Ford Motor Co. lost $400 million on failed software projects.
Whether the transportation industry in general - and trucking, in particular - has learned from software-project failures such as these is something no one can say for certain. That's because no one can count the undertakings that succeeded precisely because such lessons were heeded. Yet it seems likely they are many.
We all know trucking has had its own software disasters, but because most trucking companies operate under the radar of the general business media, those problems largely go unreported. Stories still spread by word of mouth, however.
In more than one whispered instance, carriers that aspired to be billion-dollar companies launched software initiatives as though they already were in that category. They contracted with big-name vendors who provided so much sophistication that the software functioned poorly - when it functioned at all - and the costs were near catastrophic.
Yet fleets, especially growing fleets, must continually update the software so essential to their businesses, including operations, accounting, and maintenance. Private fleets need to connect with corporate enterprise resource planning, or ERP, systems. Commercial fleets need customer relations management, or CRM. In many cases, off-the-shelf software won't do the job - at least not without customization. Thus are many fleet software projects born.
And here are the lessons fleet executives need to learn from the costly disasters of others:
First, be aware that some software projects, despite everyone's best, most-informed efforts, will fail. It is in the very complex nature of writing code. Programming requires thousands, maybe millions of decisions - one at every precise juncture in a business process.
Programming automates choices and decisions people used to make almost without thinking: Is the shipper an established account or a new customer? Does the load originate in one part of a region or another? Is the commodity hazardous or harmless?
If it's this, then do that. If not that, choose one of these other options. Each tiny decision leads down another process path, and the smallest misstep in software work flow can generate consequences far down the line - vastly complicating attempts to find what went wrong.
Don't bet more on a software project than you can afford - and certainly don't wager the company on the project's success. Those are the two most important lessons for fleet executives, and Dallas-based FoxMeyer Corp. appears to be their poster child.
The unfortunate FoxMeyer was a drug wholesaler with annual sales of $5.5 billion. In 1993, the firm hired Anderson Consulting (now Accenture) and SAP, the massive German software company, to consolidate a sprawling distribution system and implement a bold ERP system. The project was budgeted at $65 million but cost more than $100 million by its launch in 1995.
It didn't work, and the following year - overwhelmed with the project's costs - FoxMeyer itself failed.
The best defense against failure is to make the first phase of the project something that affects the minimum number of users and proves the concept. Allow yourself time to fix initial problems before adding more operational complexity. Bring in new modules when you're comfortable that the basics are working correctly.
Always have a Plan B. Ask yourself what you will do on day one if the new system fails. Decide who will be responsible for which functions and how they will be carried out to keep trucks rolling and customers happy.
Take every step you can to reduce the odds of failure. For example, select vendors with fleet experience and proven software modules. Every piece of proven software represents thousands of programming questions that already have been decided, coded, implemented and debugged. It's very late in the game for fleets to build systems from the ground up,
especially with the risk that implies.
Whatever the project entails, listen to the people involved. Be confident, but don't minimize warnings of trouble.
The Wall Street Journal recently wrote about a software CEO so frustrated by project delays that he fired the vice president who reported the latest problem. His unmistakable message: No more excuses.
But after that, of course, no one was willing to tell the truth about the program's status, which in the end cost the company dearly.
