Proposal Central
How to Lose Really Big
By
Nov 5, 2007, 14:25

How to Lose Really Big:
Evaluators Advice for Writing
Losing Proposals

A tongue-in-cheek take on how not to succeed

Part 1 of many

by Michael Asner
(michael@rfpmentor.com)

Your firm's been on a winning streak for too long and it's time for a change? Tired of scoring win after win in the million dollar contract race? Not sure what to do? We can help.

This article draws on my experience as an evaluator as well as several of my colleagues who have been or are currently evaluators of numerous large scale public contracts. Our collective experience in rejecting proposals is vast. Like evaluators everywhere, we are busy, overworked and subject to the stresses and strains from having to bend to our bosses' political agendas. We spend public money and have to make sure that the choices we make won't result in disasters which end up costing us our jobs. We want clean proposals which comply with our specifications, meet the requirements, contain feasible project plans, done by reliable, experienced companies for reasonable prices.

What we get is another story. In order to help make the contract award decision easier (to help separate the chaff from the wheat), we have reached back into our collaborative memory and have identified a few pointers to help those of you who want to lose, and lose big. The rules which follow will simplify our lives. They will let us reject your proposals without much effort. And if we can reject all but one or two proposals, our job is simplified, our workload is lighter, and the decision is easier. (To be fair, we've included some advice from industry experts on how to win, not lose, how to avoid being eliminated, how to force us to take your proposal seriously. This advice is included in the shaded boxes.

Use boilerplate with reckless abandon!

When you use "search and replace", don't verify each and every word for that's the job of the spell checker feature. One of my colleagues, Ted Nelson likes to tell the story about a large IT firm's multi-million dollar proposal. The proposal developed for the State of Washington detailed how the proposed work was specifically developed for the State of Iowa! Dan Safford, one of the best proposal writers I know, tells the same story but it was an Air Force proposal and it stated "we will keep NASA apprised of all program activities".

We evaluators really appreciate "canned" solutions. It makes us question whether you actually looked at our detailed requirements. Boilerplate boffos make us question your ability to manage the details of the proposed project or solution. These mistakes save us lots of work by helping us eliminate you from the competition without any serious analysis of your solution.

Expert, Opposing View:

Proposal evaluators can smell boilerplate a mile away. If you decide to use it, make sure it is not in place of sections you should tailor to this specific proposal. Dan Safford Page 126, Proposals: On Target, On Time www.psassociates.com

Don't Use the Executive Summary

Some proposal writers make it too easy for us - they omit the executive summary entirely. In doing this, they make it difficult for us to understand their proposal. Don't give us any hints about the content. Don't entice us. Don't make us curious about your solution. Let us put your story together by forcing us to read the entire proposal, all 200 pages. Some proposal writers still don't realize that an executive summary is not an option.

Some proposal writers are more sophisticated. They do include an executive summary - but still one designed to ensure that their proposal is not taken seriously. These writers, trying to impress their boss or the company owner, use the executive summary to tell us about the history of their firm. They think that it's important we know that the firm was founded more than 100 years ago by the current president's grandfather. They think it's important that we know the names of the founder's children and the schools his sons attended. There is no pretence of trying to impress us with the firms experience, capabilities, track record, or the specifics of their solution. Family history is what they give us - not a short paragraph but two pages, complete with pictures.

Ome Almeda, of the Valley Medical Center in Renton, WA evaluates proposals for his organization and thinks that the Executive Summary is "a very important part of the proposal . . . If I don't get what you are offering in the first ten minutes, I will lose interest".

Ignore Costs

Make sure your technical and management proposal is excellent and that your cost is 30% or 40% higher than my budget or your nearest competitor.

If you are a proposal manager, this is easy to do. Simply leave the costing to the accountants. Don't investigate alternative program designs and their costs. Don't analyse the RFP to get clues about my budget or the type of solution I want. Ensure that each of your proposal writers on this project understands that cost is someone else's concern.

. . . . the average proposal writer knew nothing of the costs of the program he or she was proposing . . . but was led to infer that costs were none of his or her concern, that he or she needed only to design and present a program for the accountants to cost for the client . . . Small wonder that so many proposals lose on cost alone! Herman Holtz Author (with Terry Schmidt) of the classic on proposal writing, The Winning Proposal, McGraw Hill, 1981 From Proposal Discussion Forum on www.proposalworks.com, Jan. 05, 2001

By doing these things, you can ensure that your proposal exceeds my budget and can't win

Avoid a detailed analysis and discussion of "our problem"

We issue RFPs to obtain solutions. And most suppliers provide information to convince us that they truly understand our problem. It's a house of cards. If we believe that you understand our problem, we might believe that your solution will work. So, make our jobs easy. Keep the proposed solution vague. Don't show us that you actually understand why we have to change. Don't demonstrate your understanding of the issues we face. Simply assume that somehow the evaluators will know intuitively what you mean.

You can reinforce this approach by repeating the RFPs definition of the problem. If I say on page one of the RFP "due to an expansion in the number of transactions, and the age of our programs and technology, we are looking for a network-based solution, capable of handling five times our current volume", then be sure to repeat my words in your proposal. The more words that you copy from the RFP, the more I'm convinced you don't care.

Don't describe your views or insights or experience with this problem. Don't explain how you've helped others. (One of your competitors will.)

Expert, Opposing View:

Simply regurgitating the RFP buys you absolutely nothing; it will earn the evaluator's disgust with your ineptness, or worse yet, his everlasting hatred for your insult to his intelligence. Donald V. Helgeson Page 99, Engineer's and Manager's Guide To Winning Proposals, 1994, Norwood, MA, Artech House

Be arrogant. Ignore our instructions. Turn your back on the work we've done.

There's nothing we love more than to be told what we really want. Why should we know? We only spent the last six months in long gruelling committee meetings hammering out the details. Explain to us what we don't know. Even if you are one of the "leaders in the industry", we will be pleased to award the contract to your less arrogant competitor.

Tell us we're stupid. We don't mind. It helps us quickly determine those with whom we would prefer working with. Your obvious disdain for our approach reinforces our decision to score your proposal low in those areas where we have the most discretion.

One of my favorite anecdotes comes from a colleague who was sitting in on an evaluation committee presentation. One of the bidding firm's hot-shot project leaders got up and said "I don't know who wrote this technical section, but he doesn't know what he's talking about." It was predictable what would happen. Almost immediately, one of the evaluators, a woman, stood up, and said "I did. Perhaps I can answer your questions". Needless to say, the firm didn't score lots of points in the presentation.

The final word on this topic goes to Ted Nelson, a seasoned evaluator from the state of Washington. His favorite bidder strategy is when the proposal makes it clear that "we really don't understand our problem and that our requirements are not the correct requirements." Ted recalls that he once issued an RFP in which he asked the Vendor to describe the project manager's experience in nine different areas. The response addressed only four or five of the areas and then described to Ted and the other evaluators what was really important in a project manager. As Ted said: "It was certainly reassuring to realize that we didn't understand what we needed in a project manager."

Expert, Opposing View:

Don't rewrite the RFP requirements, and don't imply that a particular requirement is foolish, inappropriate, unnecessary, unsophisticated, technically backwards, or unworkable. Even if it is. Tom Sant Page 67, Persuasive Business Proposals 1992, AMACOM