Musings on project management: So you need to write an RFP

Thursday, September 4, 2014

So you need to write an RFP

Spoiler alert! This posting may be dry to the taste...

Ever been asked to write an RFP (request for proposal)? It may not be as easy as you think. My metric is about 2-3 hours per finished page, exclusive of specifications. Specs are normally just imported. So, it could take you the best part of a week to put an RFP in place.

My outline is given in the Slideshare presentation below

Beyond the outline, here's a few things to think about.

Source identification: Sources, per se, are not part of the RFP, but sources are its audience. And the RFP is written for a specific audience, so sources certainly influence the RFP

Source identification, or more better, source identification and validation (vetting), is both a science and an art. The science part is an objective list of source attributes; the art part is judgment, admittedly not objective.

Of course, there's sole source (the only one in the world who can do it) or selected source (the only one in the world you want as your contractor), but more often an RFP regulates competition among multiple sources.

Award criteria: How are you going to decide who wins?

Lowest cost, technically acceptable (pass/fail) is the easiest and most objective. Just open the envelop of all those with passing technical grades and take the lowest cost -- no questions, no fuss
Best value is not easiest and not objective but it might get you the most optimum solution. Rather than pass/fail, you get to consider various innovations and quality factors, various management possibilities, what the risk is to you, schedule, and of course cost.

Best value may not be lowest cost. That's always controversial, since cost is the one value proposition everyone understands. No one wants to spend more than the value is worth.

The flexibility of best value (or, glass half empty: lack of objectivity) comes with its own risk: the award, if in the public sector, is subject to protest about how the best value was determined.

Risk transfer: what technical, functional, and business risks are you going transfer to the contractor via the RFP, and are you prepared to pay for that transfer? In effect, you're buying insurance from the contractor. All other risks are your to keep; you can be self-insured, or pass them off to an insurance party.

Here are some risk methods you can put in the RFP:

Contract incentives, penalties, cost sharing, and other contract cost-schedule-scope controls: all are forms of risk management practices.
Liquidated damages: you get paid for your business losses if the contractor screws up
Indemnity: your contractor isolates you from liabilities if something goes wrong
Arbitration: you agree to forgo some of your legal rights for a simpler resolution of disputes

Statement of work (SoW): This is the part most PMs know something about, so a lot of words aren't needed. It may be the first thing an interested contractor reads. The SoW answers this question: what is it you want the contractor to do? A top-level narrative, story, WBS, or vision is usually included.

The SoW is where you can say how agile can the contractor can be interpreting the vision. Think about how anchored to your story are you?

Typically, unless you are pretty confident you are right, you don't tell the contractor how to do the job, but only what job needs to be done.

Specifications: How's and what's: Specs are where you can speak to measures of "how" insofar as you tell the contractor how something is to be measured; or you can speak to measures of what insofar as you tell the contractor what the metrics are and what the metric limits are

Requirements: And last but not least, the infamous Requirements backlog or matrix. Requirements are usually made a part of the SoW as detailed "what's" or they can be a specification onto themselves.

Requirements are where problems surface on almost every project:

Are they objective, that is: having a metric for DONE
Are they unambiguous? ... almost never is the answer here. Some interpretation required.
Are they complete? ... almost certainly never is the answer here. But, can you admit the requirements are incomplete? In some culture and context, there can be no such admission. Or, you may be arrogant about your ability to obtain completeness. My take: arrogant people take risks and make mistakes...the more arrogance, the larger the risks... etc

But, where you can say: Not complete, then presumably the contractor can fill out the backlog with new or modified requirements as information is developed?
Are they valid? Can you accept that some requirements will be abandoned before the project ends because they've been shown to be invalid, inappropriate, or OBE (overtaken by events)?
Are they timely? Can you buy into the idea that some requirements are best left to later? ... you really don't have enough information at the beginning. There will be decision junctions, with probabilistic branching, the control of which you simply can't

RFP template from John Goodpasture