Poorly Written RFPs Can Lead to Development Headaches
I decided to write this piece when I received, after the perfunctory exchange of NDA and cordial emails, yet another (crappy) request for proposal (RFP) from a potential client. I thought about attempting to explain to the client just why their RFP was poor and warning them about the consequences of choosing a vendor based on responses generated from their RFP. I would have concluded with my heartfelt plea of “look-I’m-not-advocating-for-us-here-but-you”, but I didn’t have it in me at the moment. I’ve grown weary of writing those emails.
Although I do have empathy for why RFPs exist, let me just outline what I (and any other reputable software development firms) see in this particular RFP so that, perhaps, if any of these look familiar, you might be able to go back and reconsider your request. But more importantly, I actually want you to have a chance at developing a piece of custom software that will make you a hero and not get you fired for leading the company down a path of rampant budget extensions, schedule delays, poorly implemented features and a whole boatload of hurt feeling reports and righteous indignation.
What NOT To Do With An RFP
Our hapless example of a poorly presented RFP:
- It did not make the best use of its content. The entire document was 9 pages long. (Including Cover Page and Table of Contents, Version History and a nearly blank 7th page)
The document contained sections for Company Overview, Project Overview and the client’s Infrastructure – none of which provided more information than the client’s website or any more insight into the app they needed. - The client provided a schedule that had absolutely no basis in reality and was hopelessly optimistic. Beyond dictating when development will be completed due to desired marketing campaign needs, I also noted that they’d given me exactly three days to respond with questions to the RFP and that they believed they would be able to turn around responses to those in under four.
- “Users will be able to generate reports through a custom dashboard.” Okay, just so you know, from a software developer’s perspective, that simple, innocuous sentence sends shivers of dismay down the spine. Dashboards, Reports, User Management and even “Create” can be blackholes of development time based on exactly what, very exactly what, this means to a business.
The vast majority of an RFP should be devoted to the requirements for the application. Spend your time here; spend your words here. I promise we won’t think less of a potential client for over-sharing. Please, draw me pictures, give me workflow outlines created on legal pads, give me user stories, give me your raw notes and research. We are not asking you how to build the application or to be sophisticated in your terminology – that’s the software development team’s job and they are very good at doing that. What I need is for you to expose the very knowledge I don’t possess: knowledge about your process, who your users are and what they need to do their job or accomplish their goal. Heck, I’ll even take free-association word clouds over stuff like “Social Collaboration Functionality”.
Now, back to the RFP:
- There was a list of technologies/technical terms that the client expected us to use or to know that were, frankly, cart-before-the-horse at worst and sort of ubiquitous at best. Asking us to demonstrate the ability to develop Relational Databases is kind of like asking your carpenter to be experienced in nailing boards. If that’s a concern then you’ve identified the wrong type of service provider to respond to your RFP.
- There was an inordinately long questionnaire (relative to the rest of the document) more concerned with final business negotiations, billing, rate cards, infrastructure, and staffing concerns than with who we are, what we do, how we do it and why we do it. I mean, I can give you all of that logistical, contractual information, but it won’t help you make a good decision on whom to hire.
RFPs Seldom Gather The Information They’re Supposed To
As I mentioned above, I understand why these documents exist. Our clients, in most cases, have been tasked with soliciting, vetting and securing a service provider to build an application that represents an enormous investment of time and money for their company. They may only have one chance to get it right. Failure is not an option. They know they will have people to report to about progress and budget, timeline and “when will it be done?!?!”, and the idea of doing that in a vacuum of information makes their stomachs churn at night. It’s not like they can stop by the job site and see the building materials arrive, watch the foreman organize the crew, see the building take shape before their eyes in a manner that, well, makes intuitive sense as being a successful structure. This is software and it is the domain of ephemera and “code” that somehow gets written and then “compiles” into applications that somehow “run”. The language of development and the processes used to run software development projects can be intimidating and slightly foreign. Clients have heard of developers acting like belligerent gatekeepers and there are plenty of stories of feckless developers disappearing behind a puff of smoke and bug reports.
So the RFP represents safety and control and I get that. But it really doesn’t accomplish your objective, despite how good it feels to write it out and format it in Ariel.
And the perception of the success of the RFP as represented above persists because there are companies that make a practice of responding to these RFPs using a strategy that sort of loops clients into thinking they are getting what they asked for only to immediately throw that aside to engage in a more productive process. It’s not as nefarious as it sounds; it’s an attempt to end-around an antiquated and unhelpful tool that businesses cling to in an effort to actually provide the services that a company needs. But this approach does have drawbacks as, once the client is committed and the contract signed and some groundwork laid, this approach puts the vendor in the position of requiring a new estimate and change-of-scope documents, and a revision of schedule and expectations, all of which immediately puts the client and the vendor in an adversarial relationship rather than a collaborative one – and that doesn’t actually sound like success to me.
Click here to read what Kendall suggests you should do instead of relying on an RFP. She includes a detailed outline of questions to consider when hiring a development team.
