RFP? The case for a different approach.

Note: The views expressed here are my own and do not necessarily reflect the views of my employers, past or present.

I’m coming to the end of another draining RFP process and am convinced now, more than ever, that the RFP method is one of the most wasteful and worst ways to decide on on a software solution for your organisation.

TL;DR Using RFX’s to buy software is outdated, costly and a poor way to engage vendors. You’ll potentially end up over-paying for a compromised result. This is why...

For the uninitiated, an RFP is a “Request For Proposal” or tender process whereby the issuer spends a lot of time and effort putting together a long list of requirements and questions which they issue to a pre-selected set of respondents to answer. The respondent’s put together their response, submit back to the issuer and then the to-and-fro process continues with short-listing, Q&A sessions, demonstrations, contract negotiations etc etc. Increasingly, this is being outsourced to third- parties as a lucrative service.

I come from a construction background and worked as an estimator for an electrical contractor in the past. For construction, tenders are the usual way of doing business and, by and large, are suited to their task. You have a carefully specified, exact set of requirements, usually created by an architect and/or designer. The estimators job is to calculate the time and materials required to meet the spec. Margin is added and bids are submitted. The point being, there’s only so many ways you can wire the same set of lights or power circuits.

In my experience, this is a terrible way to buy software. Formal specification for software has largely disappeared except from safety-critical systems. The world has moved on but RFP’s have not. RFPs are reams of questions - some general, some more detailed - regarding levels of “compliance” to particular capabilities. Anyone working with enterprise software understands the large amount of ambiguity with questions such as these. Most of today’s enterprise software starts with a baseline which can then be confgured to meet a particular need. “Configure” is a key, loaded term here and usually denotes how software can be changed without fundamentally changing the underlying code base; typically through the user interface. If further tailoring is required, then custom code can usually be built or installed over the base to fit the bill. The “Customisation” versus “Configuration” debate is probably better saved for another day.

One of the main benefits a solutions engineer or pre-sales person provides is being able to collaboratively work with your business, talk to different stakeholders and work out where the problems, process bottlenecks and challenges are. We’re skilled in this discovery process and can help prioritise your challenges and then recommend a solution. Every major software vendor employs SEs in some form, trains them well for this and are available for you to utilise. Of course, we’ll be aligned to our employer... but collectively, we’re there to guide your stakeholders, management team and advise. An RFP engagement typically offers very limited opportunities to engage in this collaborative way and we’re constrained in being able add much value to the process. It’s essentially reduced to a game of Yes/No/Maybe, with some written comments which then have to be interpreted by the RFP assessor.

Here’s what I think is a better way....

1. Clearly define the problem you're solving for, the impact to the business and affected stakeholders. Set up a core team to run the process and evaluate. A trained Business Analyst should be a key part of the team.
2. Do your research. All vendors now have a ton of information and documentation on their company portals. There’s also independent comparison sites as well as the traditional Gartner and Forrester analyst reports. 
3. Short-list potential vendors. You or your stakeholders probably already have this in your heads so brainstorm it internally and define the pros and cons of each. Maybe it’s an existing relationship, maybe they’re considered “best in breed” for a particular area.
4. Collaborate. Invite each vendor in and share your challenges and aims. Provide access to the affected stakeholders. Make the process collaborative. When we say we want to “partner” with customers it’s not just a turn of phrase. 
5. Assess and Negotiate. If a vendor believes they can help, ask each to provide a “point of view” presentation together with potential solutions and cost/benefit projections. If the team deems necessary, shortlist again and progress to either a demo or proof of concept phase.
6. Implement. Once you’re comfortable with a vendor, their proposed solutions and costs, move forward to implementation. Where possible keep the initial evaluation team and vendor team working closely together to ensure the original criteria are adhered to and requirements don’t fall through the gaps in handover.

You’ll spend less time and money, have more chance of success and end up with a better solution than with the RFP route. That said, this is just my experience and from one side of the buying process. I’m interested to hear what people’s experience is like on the procurement side and also from my peers in Pre-Sales. Do you feel the RFX process provides intrinsic value and how do you think it could be improved for both parties?