Say the acronym "RFP" to anyone involved in the public sector and you'll probably hear a majority response: "Ugh!".  Requests for proposals can be the epitome of bureacracy.  Could you imagine anyone, sycophants aside, enjoying putting together a document of project scopes, surveying internal stakeholders for requirements, and then watching responses roll in that might or might not even be relevant?  The other side of the coin, as a vendor, I read through RFPs that are either so out of touch with reality that no solution in the space can meet all requirements or are written by the company that they had decided to go with regardless, making the RFP process simple paper dressing.

But, there are some positives behind the whole thing.  Interviewing stakeholders on how they would use the service, or currently handle processes the service might replace, can be necessary and lead to innovation.  Similarly, issuing an RFP is an easy way to solicit your needs to the vendor community in one fell swoop.  

I've distilled some best practices, both as a vendor and from speaking with public sector folks that deal with them regularly.

Keep It Simple, Stupid.

It is easy to let the requirements of an RFP morph into a behemoth.  While interviewing stakeholders, resist the temptation for the requirements list to turn into a list of all the things you ever wanted to make your job easier.  Unfortunately, that will lead you down one of two paths: either vendors will respond with half-truths about capabilities to meet your requirements, or the lack of response will necessitate starting the process all over again.  Both of these paths waste time, taxpayer funds, and critical momentum for innovative projects.

Instead, keep those with input into the requirements at a bare minimum.  This will ensure you have enough stakeholder input for project buy-in, but also not muddy up the requirements with diverging interests.  Similarly, keeping your requirements simple ensures you will have better response rates from vendors.  From there, you can weed out at your discretion.  More responses up-front increases competition and will result in a better resulting project or product.

Partner Up for Perspective

I'll let you into the dirty little secret of RFPs: a good number are rigged.  I'm sure if you spend your free time thumbing through the latest released RFPs like I do (nerd alert), you'll notice it, too.  Do you see a requirement: "Must integrate with (Vendor) product"?  Or requirements that only certain vendors can fulfill, regardless of how salient they are to the project at hand?  Unfortunately, practices like these are what give private-public partnerships a bad name.  

Clearly, there's some partnership happening; it's just at the wrong stage and for the wrong motives.  Sometimes, an RFP might be required and you're just going through the motions to purchase what you need/want, I get it.  One way to partner with vendors to ensure the best outcome of our project, however, is before even beginning to write your RFP.   Ask them if your requirements are off-base.  Maybe you have a service or feature required that no vendor currently supplies. 

There are two advantages to building partnerships with multiple vendors in the same space: you get to see if they're worth doing business with and you get to guide your project down a realistic path.  Typically, vendors know more about their competition than you do; if you ask them about whether X requirement seems realistic for this project, their response will show whether they're trustworthy.  If they lie about the capabilities of other vendors, or over-promise on requirements they can't currently fulfill, you would never know unless you cultivated relationships with multiple vendors and were able to ask around to fact-check.  This will prove who is worth business doing business with and who is just trying to get your business.

As I said, I've dealt with simple, easy-to-navigate Request for Proposals that led to a great fit.  I've also read those proposals that are a nightmare (75+ pages, hundreds of requirements) and said, "Why bother?"  It doesn't have to be a headache and it doesn't have to be useless.  Just keep it simple and partner up beforehand and you'll have a project that delivers a realistic, crafted outcome.