Friday, 30 December 2016

Rest in Peace, RFP

At one time or another, most of us have gone through the Request for Proposal (RFP) process — either as a customer looking for a vendor, or as a vendor responding to a request from a prospective customer. At the end of the day though, I think everyone comes to the same (and sometimes rather abrupt) realization that the RFP exercise is a massive waste of time and resources for both parties, and rarely yields the desired results.

Still, it surprises me that RFP's are so widely used by organizations looking to select vendors. And, I'm not alone in my thinking here. Craig Weiss at E-Learning 24/7 has commented on this in his excellent article, LMS Guide: Everything from Selecting to Implementing. On the first page he asks the question, "When should I use an RFP?" — and his answer mirrors my own: "Ideally, never."

Of course, Craig follows up with constructive alternatives to the RFP process, and I will offer some of my thoughts on that later. First, let's look at the primary culprits that make the RFP process so dysfunctional, and how they misdirect valuable time, energy and resources.

Culprit #1 — Poorly specified requirements

An RFP should clearly specify requirements and desired outcomes so that a vendor can propose the best possible solution in accordance with a realistic and feasible budget. Ideally, requirements analysis is done first, and the outcome from that analysis shapes an RFP.

However, when I look back at every RFP that has crossed my desk in the past 20 years, very few include requirements that are defined with sufficient detail to support constructive conversation, let alone an actionable response. You've heard of "putting the cart before the horse." That's what tends to happen and as a result, the RFP too often becomes a glorified fact-finding document, and this leads us to the second culprit.

Culprit #2 — RFP as fact finding

OK, so here we are. A typical RFP offers little in the way of structured, actionable specifications. It may have been shaped by a committee, and it almost certainly contains inconsistencies and omissions in its attempt to serve the whims of multiple stakeholders.

Of course there are plenty of vendors willing to spend the time and resources "educating" their potential customers by doing the necessary requirements analysis as part of the proposal effort. Essentially, the proposal document becomes something that is a combination of: a statement of interest, a functional specification, and an implementation estimate; all prepared by the vendor, free of charges and obligations.

From my experience, if you are not certain that you have at least a 50/50 chance of winning an RFP, then it is insane to even consider a response. After all, in what other context would you willingly forego compensation for time, effort, and expertise?

Vendors expend a tremendous amount of time and money preparing their responses to a typical RFP, most of which is wasted effort when only one vendor is selected — and all of which is wasted effort when no vendor is selected because the process is scrapped partway through. This leads us to our third culprit.

Culprit #3 — A one-sided process

No matter how you look at it, the RFP process is opaque and one-sided. Don't believe me? Consider how often a budget is disclosed in an RFP. Almost never. Consider how often an RFP is recalled or cancelled for no reason at all. All too often.

The RFP process fails to support or engage customers and vendors in an environment that is characterized by clear and constructive dialogue, with lines of communication that are open and transparent. Some argue they do not disclose budget for fear of vendors who will propose solutions based on price rather than proposing solutions based on merit and capability. I disagree. The reality is this position needlessly complicates (and sometimes blocks) meaningful communication, it negates value, and it attracts desperate vendors who are willing to say anything to get the work they need.

The RFP process is not a panacea for vendor selection because it is disingenuous and one-sided from the start, and it sets the stage for a frustrating experience for both vendors and customers. Think about it, who walks into a dealership with the intent of buying a car without disclosing the basics of the buying decision, like budget?

Alternatives to the RFP process

About two years ago we decided we would respond to an RFP only when: 1) the requirements are clearly defined and 2) we have a minimum 50/50 chance of being awarded the work. If both of these criteria are not met then our response is simple: no response. Instead we get on with productive work for real customers who value our efforts, and with whom we can communicate openly.

Craig's LMS Guide emphasizes a strong focus on "putting first things first" and "not putting the cart before the horse." You need to begin by allocating time to do your homework properly: identify systems of interest, commit to product demonstrations, and understand the capabilities of prospective vendors.

I agree, and I would add that the results from your "homework" should be captured and documented in a formal product planning or requirements analysis.

Product Planning and Requirements Analysis

Product planning and requirements analysis is our first step when we on-board new customers and when we work with current customers to expand and tailor our solutions to their growing and evolving business needs. Without this first step, the probability of a successful implementation is greatly diminished.

Product planning and requirements analysis typically unfolds in several phases; it requires its own budget, with an experienced guide and a strong commitment from the entire team. If the resources for this are not available to you internally, then you need to find them before you start. This is critical.

Core Components of Requirements Analysis and Product Planning
Requirements Gathering
  • Product concept and definition
  • Business process
  • Business value
  • Platform summary
Requirements Analysis
  • Functional specifications
  • Underlying data model
  • Application security requirements
  • Reporting capabilities
  • Configuration and integration requirements
  • Data conversion
  • Value-added features
  • System delivery
Product Planning
  • Methodology and approach
  • Project team
  • Schedule
  • Cost estimates
Product planning and requirements analysis is tremendously valuable when it's done right. If you are working in an organization that still needs to follow an RFP process, then the outcome from this work will allow you to prepare a well-considered and properly documented RFP that vendors will truly appreciate.

At InSite we advocate for transparency and we value relationships. In fact, our company was founded on relationships first and technology second. Our culture empowers us to develop incredible solutions like Shift iQ and InSite's Open Management Information system.

If you work in a company like ours then you know every constructive relationship supports collaboration in an open and transparent environment, which allows everyone to discuss, decide, and deliver on realistic expectations. RFPs rarely, if ever, contribute to achieving this, and we have been pleased to see organizations of every size begin to abandon the RFP process in favor of much more productive alternatives.

Rest In Peace, RFP!

No comments:

Post a Comment