Page 307 - Writing Winning Business Proposals

298 Appendix G

Step 3: Strip All Requirements in the RFP,
and Test Them Against the Proposal

In this step, you need to identify every requirement in the RFP, including require-
ments not labeled as such, and “strip” them from the RFP by placing them in
the first column of a spreadsheet similar to the table in Figure G.1. In additional
columns, you can include the RFP’s page number(s) where the requirements are
listed and the degree—high (H), medium (M), low (L), or not at all (X)—to which
they are emphasized in the draft of your proposal and, if appropriate, in the slide
deck for the oral presentation.
All but Figure G.1’s first row and its last three contain requirements from
the RFP’s actual requirements sections (which, in total, included more than 50
requirements). The first row’s content comes from the RFP’s objectives section.
The last three rows contain the three hot buttons and their degree of emphasis
(which was “not at all”!) in the proposal. I’ve added those three rows to illustrate
these points:

◉ Although hot buttons aren’t technical requirements important for executing
a successful project, they are (de facto) requirements, not only for conduct-
ing the project but for selling it, even if the RFP’s writers don’t consider them
requirements.
◉ The consulting team should have considered them as requirements and
addressed them in their proposal.

As mentioned often in this book, on a hundred-point scale, the difference
between winning and coming in second is frequently as little as two to five points.
If the consultants had considered the prospect’s hot buttons as requirements,
would they have gained a few points? If they had addressed those hot buttons,
would they have won? (They didn’t.)
These questions don’t have easy answers, but this one does: Would it have
been worth the consultants’ time and effort to address the hot buttons, thereby
increasing the likelihood of their winning and decreasing the odds of their plac-
ing a close second?
In the consulting game, even great proposals lose, and even awful proposals
win. In fact, in situations like Scenario 1—that is, when RFPs are not involved—
great business developers will tell you that proposals themselves rarely win. They
either clinch or lose, because the engagement should have been won, or substan-
tially won, before the proposal was even submitted, as a result of relationships
and upfront selling. In such situations, the proposal is pro forma, in effect, a legal
document serving as a contract. In RFP situations, however, proposals play a