Unforced Errors:0; You:1

I’ve learned the hard way how a second set of well-trained fresh eyes reviewing your bid can be the difference between an “L” and a “W” on your proposal stats. Let me spare you the awful feeling of getting a “Dear John” letter from your proposal evaluation team because of an unforced error in your writeup.


First, let’s set the stage:

It is early February and your in-house proposal team is working on twelve concurrent RFPs and RFIs. Every single SME in your team is running capture on at least three bids of their own and helping their peers on their three. Your days are thirteen hours long, not including your commute or lunch – if you are lucky enough not to have a working lunch. Raise your hand if you can relate to, or see this scenario coming. Everyone, please put your hands down.

When capture and proposal teams are running at full speed, permutations of complacency, laziness, fatigue and blindness set in. Even the most seasoned FedGov / DoD bidders can lose track of what proposal they are working on, and what are the requirements that must be compellingly addressed.

Out of several unforced errors that can cost you an award, let’s look at three that can hide in plain sight, and that you can avoid with the help of a “third party” Grey Team and a good Tech Review.

CLAIMS WITHOUT PROOF

“We have a world class [insert here the name of goods or services your company offers]…” or “Our unique [insert here clever product name for your product or technology that other dozen companies have] is the best performing [good or service] in its class”.

Claims like these are dropped by engineers and product managers on RFIs more frequently than we care to admit; and we still overlook them! They are the perfect cue for any member of the evaluation board to hit that “skip” button in their brain and move on to the next factual sentence. Proposals are NOT marketing collateral, or a pitch at Shark Tank. Proposals are legal instruments through which funds are awarded and should highlight facts that build the proof that supports a claim of value and compliance. Just because you say so, it is not always so.

When you are too close to the products and services you bid, you can confuse emotion with fact, and assume that the evaluator reading the proposal is as vested in your product or service as your company is. This is the moment when you could use a set of eyes that has nothing to lose by saying – “I don’t get it” or “how can we claim this; where is the proof?”

A Technical Review performed by an objective third party can not only identify these claims without proof, but also help your team edit them such that the case that you plead is rock solid, and based on facts.

SIMILAR BUT NOT EQUAL

Some RFPs allow “replacements in kind” (RIKs). Others don’t. If the program office and the solicitation specify that the writing device they want to purchase MUST have blue ink, you can’t bid a pencil for the job. (Sharpies are ok though)

If a solicitation for services has three critical positions and one of the requirements is that those slated for the job must have completed a PhD in [insert here discipline], the resume or CV for the candidate you put forth has to show that the PhD was earned, not in progress, and that the discipline is the one requested, not one that is similar.

Attention to detail fades when your team is all over the place and/or is not familiar with specific requirements. G-shock rated is not the same as MILSPEC, and OMP3 is not the same as CMMI. PhD is not the same as DSc.

The good news; a Technical Review performed by a seasoned and experienced third party using a well-crafted compliance matrix can identify these deficiencies in your proposal and help you cure them so that you submit a 100% compliant bid.

FEATURE Vs. BENEFIT

One of my favorites. The grading criteria states that bidders must “demonstrate value add” to the customer’s mission. This is tricky, because it implies that you understand what the customer’s mission is, and what their operational goals are.

The bid’s Technical Volume should focus on demonstrating value add, and somehow, we think that a Gatling gun of technical specifications answers the mail. Not even close. Stating specifications, while a requirement, only asserts that your team meets the minimum standard, and unfortunately in this instance, the minimum is not good enough.

“Our NVGs operate for 8hrs on a single charge” – so? What does that matter to the soldier out on patrol? “Our NVGs operate for 8hrs at full power on a single 15 min charge.” (indulge me here) “This feature maximizes operational readiness and the safety of the operator because…”

You get my drift here. Technical specifications are not the same as “valued features”, and yet we often miss that in the proposals we submit. Why? Because we are writing three of them at the same time and unlike the NVGs above, we need more than 15 min on the rack in order to properly operate (unless you are a Navy Nuke of course). It takes the best-trained writers incredible effort to synthesize “value add” from technical specifications when their minds are clear. Imagine when writing three proposals at the same time.

This is when they could use a seasoned third party that has walked miles in the same shoes as the evaluators and end-users. A third party that can not only answer the questions of the RFP, but also the subsequent “so what?” that is ever so critical to show “value add”. We call this “third party” the “Grey Team”; the crusty group of experts that can identify a problem before it happens, and can explain in the simplest of forms why what and why your company’s bids really matter to the end-users.

Even the most experienced Capture and Proposal teams can use outside help, especially when the pace of business picks up. Don’t let it be an issue of pride because you have the talent “in house”. Acknowledge the fact that your SMEs can’t do twenty things at the same time, and do them well. Having a third party help your proposal team with a solid Technical Review pays by itself the first time you save a “W” by avoiding unforced errors.