Why the Traditional Software RFP Selection Process Falls Short

Why the Traditional Software RFP Selection Process Falls Short

Will you soon start the process of which software or vendor to choose for your ERP, website, service desk, or other major system?  If so, you may also be dreading the amount of time and energy that will be required – and the risk involved – not only for yourself, but also for your team.

Many organizations instinctively turn to the traditional RFP process for software and vendor selection. But, the RFP process has inherent shortcomings.

1. The Buyers
Buyers are often not as good as they should be at transforming their business needs and plans into crisp, clear, pertinent requirements – and segregating “needs” from “wants.”

2. The Vendors
Vendors are very good at responding to RFPs in ways that are informative, but not revealing.

3. The RFP Process
The RFP process rarely produces results that are repeatable, predictable, and generally regarded as “fair.”

What to do? It’s about Clarity and Focus
We’ve found there is a better way to approach these types of major decisions – saving everyone time and getting to key differentiators of prospective vendor software solutions based on unique requirements – through a derivative of the Kepner-Tregoe(R) Decision Analysis process, using what we refer to as our Blueprint methodology – where 1.) system requirements are described in the context of key business process flows, and 2.) there is a scenario-based approach to evaluating alternatives.

The Blueprint process includes a few assumptions:

  • A project has been formally chartered
  • A cross-functional team has been commissioned
  • The key business processes that the system is intended to enable have been identified, documented, and are clearly understood

It also utilizes a four-phase approach:
1. Clarify Purpose
2. Evaluate Alternatives
3. Assess Risks
4. Make the Decision

Of course, each phase includes Objectives, Activities, and defined Deliverables – and should include a list of stakeholders, their estimated time investment, and have those items mapped to a phased project timeline.

We provide a sample work plan for the Blueprint Scenario-Based Software Selection Process.

About the author