RFP response documents are not well liked whichever side of the fence you sit on, they are painful to write and even worse to read. Their greatest failing though has to be in their ineffectiveness at helping people decide which solutions to buy. In the end it is people who buy solutions not companies.
Like pulling teeth
What is it that makes RFP responses so universally despised ? Well where to begin. Firstly they are painfully unwieldy – full of many hundreds of mind numbing and often irrelevant questions that are generically reused across many different RFP’s. Secondly there is a general suspicion that every vendor will say they do everything and fully comply to all of the requirements. It becoming more of an exercise in whose RFP response weighs the most rather than who has the best solution. All of which results in a sense of frustration at the utter futility of the whole exercise – people just going through the motions as no one is brave enough to stop the madness and excessive waste of time and resources.
A better way
Why do people continue to follow this broken, time consuming, resource hungry process ? It’s hard to say – probably the involvement of so many people and the mountain of documentation provides some kind of reassurance that due care and consideration has been given prior to spending company money for a significant purchase. But in nearly all cases this is a false sense of security. Most of the real value coming from the interactive discussions with the vendors rather than the forest killing tomes of response documents. In these enlightened times a new more agile approach to selecting software is demanded.
It’s easy to see that there is much wrong with the RFP process and in particular the associated documentation. The question is what would be a better approach. To that end I would like to propose the following software selection manifesto. A call to arms to everyone who has ever had to endure writing RFP responses or given up the will to live reading them.
Software selection manifesto
Favours the following
- Interactive dialogue over documentation
- People over company background
- Realistic prototypes over slideware and demo’s
- Reference data over marketecture
Interactive dialogue over documentation
People much prefer talking to people than reading huge documents. If there is to be some documentation it should be minimal and really serve the purpose for laying out a framework for the face to face discussion to take place. Interactive discussions allow key areas to be explored in a way that no document can address.
People over company background
People buy from people not companies. The cultural compatibility and the confidence in the people who will both manage and help deliver your solution is worth more than all the company marketing blurb you could care to consume. Which is not to say due diligence shouldn’t be done on company financial and commercial viability – this is of course necessary. However with all things being equal the people make the difference between success and failure of most software projects.
Realistic prototypes over slideware and demo’s
Prototypes or proof of concepts allow a particular use case with relevant data to be explored. With some well chosen use cases it is possible to get a reasonable understanding of how a solution may help meet the requirements. This is often far more valuable in understanding a solution’s fit to the requirements than trying to mentally map slideware and canned demo’s to your specific needs. The reason for the ‘realistic’ qualifier is that often people lay out too many complex use cases that simply can’t be effectively delivered in a reasonable timescale. Here it is a case of quality over quantity for prototypes.
Reference data over marketecture
Is it more useful that I draw you a diagram showing how the architecture will scale or that I share data with you about a customer who is running the solution with similar traffic volumes and users with equivalent data sets on a given hardware footprint ? No amount of architecture discussion or drawing will replace the reality of real data proof points. Architecture diagrams have their place but real data should be the most persuasive evidence in making a decision.
In the end these are guiding principles not a recipe or process to be followed. Their objective is to provide a framework that is more pragmatic and efficient in the use of both time and resources in assessing whether a solution is really fitting your business needs and if the people from the vendor will make it successful.