How Business Automation Projects Fail, Part 2

In part 1 of this series I wrote about a simple case where failure to define requirements for a software purchase ended up costing the business several thousands of dollars worth of wasted effort that had to be re-done. The software purchase price was just a few hundred dollars, so it seemed okay to take shortcuts in the selection process. The resulting loss was more than anyone bargained for.

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!