12 ways to fix the traditional but broken software RFP selection process

The traditional RFP process fails to deliver consistent results when purchasing off-the-shelf or cloud enterprise software. This article examines problems with the RFP process specific to selecting software and suggests appropriate resolutions.

Why does the traditional RFP process return such poor results when selecting off-the-shelf or cloud software?

A primary purpose of software RFPs is to discover how well potential products meet requirements at an acceptable price. Vendors respond to the RFP with their proposal. The organization selects the “best” proposal and makes the purchase. However, problems frequently appear after starting the software implementation, leading to missed deadlines, increasing costs and occasionally outright failures.

Sadly, the traditional software RFP process is broken. In fact, when it comes to purchasing off-the-shelf or cloud enterprise software, this process never worked properly in the first place. It is the reason stories about software failures regularly appear in the technical press. These stories are only the tip of the iceberg; people don't talk about most partial or outright failures because they don't want to be associated with them.

By definition, any enterprise software project that does not meet the target ROI is a failure to some degree. This article examines reasons why the process of selecting software via an RFP is broken and offers suggestions for fixing the problems.

The typical enterprise software selection project (cartoon) ProjectCartoon

The typical enterprise software selection project

1) Requirements management

Enterprise software systems can have many thousands of requirements. Managing these requirements with spreadsheets or word documents is labor intensive and error prone. Problems include a lack of version control, manual workflows, and missing files.

Advertisement

The Fix

Use a system designed to manage requirements for software purchases. Note that while superficially similar, systems optimized for software purchasing have a very different emphasis to those optimized for software development. For example, a purchasing focused system has a means of rating products against requirements and comparing them to the organization’s needs. Systems focused on software development do not have these features.

1 2 Page 1
Page 1 of 2
Survey says! Share your insights in our 19th annual State of the CIO study