Proposal Land

Better RFP Responses & Management
 
Proposal Land

Term: Proposal Speak

The style of language used in a proposal as distinct from that used in plans and other internal documents. Includes use of the future tense, as opposed to the present, to clearly indicate to evaluators the bidder’s intention to provide a product or service in a specified way.

May be used pejoratively to mean fluff as opposed to substance, or even to mean outright lies.

Really?

Bidders will submit a detailed Transition Plan.

Really? You need that at this stage? How’s about bidders tell you about three transitions they’ve managed? What the work was, what they did, how well it turned out?

Bidders will submit a comprehensive Quality Management Plan.

Really? You need that at this stage? How’s about bidders list their certifications from independent industry organizations explicitly dedicated to assessing quality-management plans and practices?

Bidders will submit a Project Management Plan.

Really? You need that at this stage? How’s about bidders give you an organization chart and explain how it’s going to work?

All human endeavour has a lot of built-in inertia: bureaucratic endeavour, even more. And so RFPs continue to hit the street requiring detailed, long, and largely useless plans.

Let’s go back to first principles:

  • What do you (really) need to know about how the bidder will do the work?
  • What do you (really) need to know about what you’ll get for your money?
  • What do you (really) need to know to distinguish between competing bidders?

Imagine you have only two weeks to make a contracting decision. What can bidders reasonably put together in the first of those weeks that will let you choose wisely in the second one?

Hopelessly oversimplified? Yes. Impossibly impractical? Sure. But it’s still a useful thought-experiment antidote to churning out more-or-less the same questions, time after time.

I mean, really.

 

Divide and Conquer

How do I edit thee?
Let me count the ways.

I edit thee for obvious responsiveness, aligning the sections with the questions: the same numbering, headings, and order.

I edit thee for organization within each section, keeping like topics together and imposing some sort of defensible order on a stream-of-consciousness input.

I edit thee for clarity, ensuring that the same concept in different sections uses the same words.

I edit thee for macro consistency, ensuring that content in different sections tells the same story.

I edit thee for micro consistency, enforcing arbitrary standards on acronym use, capitalization, spelling, units of measurement, and an entire flock of factoids.

I edit thee for readability:

  • Breaking down long sentences
  • Breaking apart long paragraphs
  • Using simpler words
  • Adding bullets and graphics

I edit thee for style, smoothing the idiosyncracies that different writers and technical/business specialties exhibit.

I edit thee for marketing impact, putting the benefit first: in each section, in each paragraph, in each sentence.

I edit thee for length, finding shorter ways to say almost everything.

I edit thee for typos and grammatical errors, driving out basic mistakes.

I edit thee in one pass, jumping effortlessly between the biggest picture (solution clarity and consistency), the big picture (marketing impact), the slightly smaller picture (style consistency), the tiniest of tiny pictures (standardizing spaces around slashes), and all the pictures in-between.

Or not.

Jumping from one conceptual level to another, from one level of abstraction to another, from one level of detail to another, is work. Hard work. Tiring work. Prone-to-error work.

The longer I do this work, the more I’m inclined to break editing into discrete tasks. First, structure and numbering. Second, readability and length. Third, clarity. Fourth, consistency and style. Fifth, length and graphics.

One person can do it all, or a few editors can tag-team a document, with one cleaning up the obvious messes and the other reading for meaning. Successive passes can deliver a higher-quality product faster than a single pass, and with less wear-and-tear on the editor(s).

Pick one focus at a time (OK, or two – this *is* Proposal Land and some parallel processing is expected). Complete it (or them). And repeat.

 

Here’s the Thing

Bidders shall provide three (3) examples
of past experience on relevant, similar projects.

Grrr. It kinda grates, don’t it? I mean, how can experience be anything but “past”?

But this egregious and all-too-common error by contracting officers is not the subject of *this* rant. This rant is about something bidders *can* control: being ready to describe that experience. Because here’s the thing: It’s not like it’s a surprise requirement the client springs on us in the final weeks of a proposal.

Oh, by the way, we just decided
that we need you to describe three (3) projects
that look just like this one.
(Psych!)

No, they’re completely upfront about it when they issue the RFP. Indeed, in government contracting it’s an obvious requirement even before the RFP hits the street. And indeed again, no company would bid on work without having some sort of relevant, similar experience. So, like, you’re ready, right?

No. Never. Because here’s the thing. Until the RFP arrives, you don’t know exactly how experience will be scored:

  • Will they count number of projects or number of years or both?
  • Will they focus on project duration or recency or currency or some weird hybrid?
  • Will they require (or reward) broad or deep experience?
  • Will they set minimum thresholds for the volume of whatever service is being contracted, whatever product is being bought?
  • Will you score higher if the staff you’re proposing have worked on one or more of your experience examples?
  • Will project location matter? Client type? Contract value? Employee numbers? Some specific tricky or obscure technical or security requirement?
  • Is there a mandatory experience response as well as a rated one? Can you use the same examples in both? Must you? Must you not?

And so on. It’s hard, you know?

But here’s the thing. Although you can’t be 100% ready before the RFP comes out, you can get 100% ready soon after it does. You can take your list of experience (created before the RFP came out) and give it to a small but informed team: some people who know the projects in detail and some person who knows how to present examples completely, exactly, and precisely according to RFP instructions. I dunno — maybe three (3) people in total? Maybe.

Before the main proposal team has finalized their solution and written their first draft, your PET (Past-Experience Team) can finish their assessment on the experience options, showing how they *should* score against any hard, quantitative evaluation criteria, as well as how they *might* score against any qualitative criteria. Then the executives can pass hands over the list and authorize a final selection. With, I dunno, maybe one (1) extra, just because in case you never know? Maybe. But only one (1).

Then the PET can go to town, fleshing out the experience examples to make them look as good as they can: as good as they are, maybe. Details. Results. Certifications. Photos. Kudos.

Let’s recap:

  • Do your pre-RFP homework.
  • Launch a small, dedicated group to work on experience as soon as the RFP comes out.
  • Authorize a final list of examples given the evaluation criteria, within the first few weeks. Maybe three (3) weeks? On a long proposal, no more than that. On a shorter one, sooner.
  • Go (GO. GO!!!) on the presentation of the approved examples.

Now, maybe this has not been your past practice.  Maybe you prefer the experience of getting to Red Team and having executives rip your experience section (mandatory or rated or both) to bits. But here’s the thing. I found that getting ripped got old after, oh, I dunno, a few times. Maybe three (3)? Maybe.

Or think of it this way. As the purveyors of financial products say . . .

Past performance is not a guarantee
of future results.

But here’s the thing: It is exactly that if you don’t do anything differently.