Having read this article, I’m amazed that so little focus or insight is provided about the process used to select the software in the first place. The article correctly notes that “the devil is in the details,” but doesn’t begin to discuss how the details were defined during the purchase cycle. It just bewails how they were “found” during the aftermath. It’s always easiest to “find” the bugs in software when you use it “as you think it should run” not the way it was designed to run.

The simple solution to this problem is to define and specify the details BEFORE you buy the product, then follow a comprehensive and well-defined plan to choose appropriate vendors, evaluate each proposed system, and write a contract to acquire it. In fact, this solution is far easier to say than it is to implement. Like complex software itself, acquiring complex software is a complex process.

NOTE: The process of choosing significant, complex, and expensive software is labor intensive, time-consuming, and very expensive. I use the words “significant software” to indicate a level of work and cost that justifies a significant expenditure of resources (people, time, and money) just to define the requirements, evaluate the offerings, make the purchase, install the product, and evaluate the results. However, if you are going to spend $150,000 for a software package to support the financial functions of your entire company, it might be wise to invest $15–20,000 before you buy just to make sure you pick the right software and the right company.

Software Acquisition Process

1) Collect the requirements

2) Prepare a requirements / evaluation matrix. Define a weight factor for each requirement (I use a scale of 1 to 5) with respect to the requirement’s importance or value to the company. Be specific about what each requirement is and what it means to you and your company!

3) Conduct a first broad scan of potential vendors to select a “shortlist” of potential vendors and eliminate obvious non-contenders. Some sources of information include industry publications, the Internet, personal experiences of employees, and members of industry groups.

4) Prepare a Request for Proposal (RFP). Make sure to include ALL the requirements.

5) Give the RFP to the shortlist of vendors. Ask vendors to reply specifically to each and every line item.

6) Conduct a demonstration of the software by each vendor.

7) Evaluate and SCORE the proposals. Give each vendor a quantitative rating for each line item in the requirements matrix (again, I use a scale of 1 to 5). The score for each line item for each vendor is the vendors rating multiplied by the weight factor. (Note: This is NOT scoring the demonstration; it is scoring the proposal. Only use the demonstration to validate the vendor’s claims in the proposal.)

8) Decide which software to buy.

As a consultant to a large microchip manufacturer some years ago, my task was to help them acquire graphic user interface software to provide user interaction with one of their corporate databases. At the time I was engaged, the small development team had already narrowed the field of competitors to 6 or 7 potential vendors. They had also decided on approximately 30 “requirements.” It took about 2 weeks just to develop that requirements / evaluation matrix with more than 280 line items.

In fact, the development team charged with making the selection were all software engineers who focused solely on the technical requirements they needed to implement the software in their programming environment. What they had not considered were all the business requirements that come with any capital purchase: things like the health and quality of the vendor, the capabilities of the vendor’s support staff, the maintenance plan and cost for the life of the software, and training capabilities of the vendor and costs to train users.

The line items fell into broad general categories, and because we now had a two-level matrix, we decided to have a two-level weighting factor: the first level was the importance of the category of requirements to the company; the second level was the relative importance of each individual requirement within its group. The score for each value was the product of the two level factors and the individual product score. (Certainly we could have eliminated the two-level complexity and come up with a single value for each line item, but choosing a single value for each requirement out of nearly 300 becomes more geometrically more difficult as you add more categories and more requirements.)

While the article seems to attack Sage Software for overselling its product, I’m more inclined to blame Digital Warehouse for not investing the time and resources to adequately and accurately define its needs and more carefully evaluate Sage’s ability to meet them. While I don’t fully endorse “caveat emptor” as a business philosophy, in this case, I think a little more responsibility falls on Digital Warehouse’s shoulders. My sincere condolences to Stephanie Bice who inherited the wind of her predecessors bad decision making process.