I’m starting a short series in How Business Automation Projects Fail. This is part 1, where I’ll cover the case of an apparently simple project to install a common software package. In part 2 I write about a much more complex and expensive project.

Business Processes

Businesses run by following well defined processes. Let’s look at a wholesale distribution business as an example. Here’s a grossly simplified version of the core processes at the heart of the business:

An order comes in.

The accounting department vets the payment, issues an invoice when necessary, records the transaction, and passes the order to fulfillment department.

The fulfillment department picks, packs, and ships the merchandise, records the shipping transaction, and adjusts inventory quantities.

The buying department reviews the revised inventory records and places replenishment orders when necessary.

Process Automation

In many cases, business processes can be made more efficient by letting computers do portions of them. Say you’re a small wholesaler with an overall selling process similar to what I’ve described. You know you want to automate many parts of the process. You’d like the computer to do the accounting, keep track of the inventory, alert you when customers haven’t paid and when inventory quantities are low.

So maybe you go to your accountant and ask for advice. The accountant says “Buy QuickBooks. I’ll help you set it up,” because that’s what the accountant is familiar with. So you do.

A month later you have the software installed and mostly configured, and you start to try running sample transactions through the system. You quickly discover that there’s a big problem. QuickBooks lacks the ability to manage multiple warehouse locations (this is a hypothetical example) and you need that badly. The entire automated system is useless to you without that feature.

Failed Project Postmortem

How did this happen? Your accountant recommended a capable and familiar software package without taking the time to define your requirements completely and to compare those with the software’s capabilities. The accountant was never trained in that discipline, and neither were you.

What’s the net result? You’ve lost a month of work setting up the software, and you have to start over from square one. You still have to find or commission the right software and get it set up.

Does this little story sound far-fetched? It’s not. It happens to small and medium businesses every day. This is exactly how software projects fail, how business automation projects fail – by failing to define the requirements formally and to make sure that they will be met by the proposed solution.

In this part I’ve told about one common way that a packaged software acquisition and installation project can fail. Stay tuned for part 2, where I’ll cover a more complex project where the business commissions a custom software solution.