In part 2, this post, I’m writing about a much larger purchase of custom-developed software. This is a true story of a project that could have turned into a disaster. It could have sunk a new startup company before it ever got off the ground. It could have failed badly. But this one actually has a happy ending. Disaster was averted because the business owner stopped in the middle of the process to ask some key questions, and he acted on the answers.

The Background

The owner had a brand-new startup company with little more than a business plan and some funding. The plan required a unique custom developed website with a high level of complexity. Here are some of the requirements in general terms:

• A set of consumer-facing pages that could be branded with the company’s name or private labeled to business partners. In the case of private labeling, there could be differences in fuctionality.
• A set of pages and communication protocols to manage data exchange with another set of business partners.
• Very secure private communications and protected private logins for consumers and business partners.
• A complex and secure administrative back end to manage the entire enterprise.

The Steps

Here are the steps the business owner took to begin the software project:

• He prepared a Request for Proposal (RFP) that specified the requirements.
• He identified several vendors who were qualified to do the work.
• He submitted the RFP to the vendors and received proposals from them.
• He evaluated each proposal and spoke with each vendor about details.

The Problem

This was a good process as far as it went. But it came to an impasse. The owner identified one vendor that he felt comfortable working with. But the vendor’s proposed price was well over the budget that the owner could commit based on his funding. The price was about $350,000 where the budget called for a maximum of $250,000.

The owner didn’t want to throw away the work spent in establishing a rapport with the vendor, but he just couldn’t agree to the price. It would have jeopardized the entire startup.

The vendor maintained that the system they were proposing met the specifications, and for the system they were proposing their price wasn’t flexible.

They couldn’t move forward.

The Solution

Then the owner made a great decision. He decided to bring in an outside consultant to take a fresh look. That consultant happened to be me, which is how I know the details of the case.

Here’s the process I followed:

• I studied the RFP and the proposal in detail.
• I asked the owner some questions to clarify details of the requirements.
• I got on a conference call with the owner and the vendor to ask the vendor to explain how they were approaching key portions of the project and to explain why.
• I pondered all the information I had gathered.

Here’s what I concluded. The owner had requested a secure, robust, flexible system. The vendor was proposing an approach that would create an extremely secure, very robust, and supremely flexible system. It would certainly work, and work very well, but it was on the order of a Rolls Royce level solution, where a Cadillac solution would have been sufficient.

I proposed some compromises in complexity, especially in the area of flexibility, and made sure that the owner and the vendor understood the ramifications of my suggestions. They did, and they both agreed that the changes in approach were reasonable.

The vendor reworked the proposal according to my suggestions. The new price was about $200,000, a reduction of over 40% and well under the owner’s budget.

Everyone was happy. The company launched under budget and is now well established. But it could have been a total failure, all because the vendor had over-designed the solution because they hadn’t asked enough questions about the real requirements. Another victory for proper requirements planning!

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.