Software selection demystified

News Story by Michael W. McLaughlin
June 19, 1995 – Computerworld

If you had a crystal ball that could predict the issues you would face in your software selection project, what would it tell you? I recently was asked that question by a manufacturing client who was concerned about the pace of software selection, the risk of poor decision-making and, of course, cost.

While fortune-telling is not part of my job, I did share with him a set of guiding principles to reduce the mystery, uncertainty and risk of software selection projects. The most critical point, of course, is to begin with a compelling business case--one that establishes the business imperatives and outlines the estimated costs and expected benefits--in order to build consensus.

Next, plan your strategy early. Envision the selection process as a car trip: Before setting out, make the significant decisions about where to go, how to get there and how much to spend. Then, for optimum results, empower a small, full-time, cross-functional team of ``A'' players to complete the process.

The ``secret'' to success, however, frequently escapes those in the driver's seat. Why? Because most teams fail to accept two realities. First, today's leading software offerings usually meet most business requirements. And second, less than 50% of the planned features will end up in the implemented systems, regardless of the upfront analysis.

The most successful teams recognize these realities and then organize for speed and results. They adhere to the following guidelines:

``Time-box'' the project. Once the team is focused, delays in decision-making and schedule slippage can be avoided with a nonnegotiable time frame. The time box also establishes an early management discipline that accelerates project completion.

Avoid a request for proposal like the plague. A written response to a list of software requirements provides limited value. Instead, prototype your requirements on a vendor's system. By seeing the software operating in a simulated environment, team members will know immediately whether or not they have a solution.

Narrow the field quickly. First, examine each vendor's scope of offerings, technology platform, proposed budget and industry fit. Next, analyze the vendor's ability to support major functions and high-priority needs. Last, complete a detailed modeling and analysis of the software functions. Most important, methodically eliminate candidates at each phase to quickly focus the team on the viable systems.

A few words of caution. Don't buy futures. As a general rule, don't decide on software based on promises of future releases, and don't count on any functionality you haven't seen. Consider futures only for ``nice to have'' features.

Get all the costs on the table. One client who failed to account for user training, change management and the process redesign effort discovered that these oversights doubled the project and budget. Other frequently overlooked components are IS skills training, legacy system integration, and customer education and software enhancements.

The selection process isn't easy, but it is manageable. And, if you observe the principles noted above, you won't need a crystal ball for guidance.