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 from an engineering, marketing, or product team. 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 better yet: 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.
Among sources, 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 to do it), 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 entirely 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, 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.
Risk methods: 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 practises.
- 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 you are.
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 for compliance: It is certainly necessary to speak about how something is to be measured to prove compliance; or you can speak to what is to be measured to verify compliance to the specification.
Requirements: And last but not least, the book of requirements is tantamount to the infamous
Requirements backlog.
Give these ideas about requirements some thought
- 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
Buy them at any online book retailer!
