What’s your success ratio with proposals? 25% is average. Very few get 50%. I help government agencies evaluate proposals. Most bids that come across my desk make the same errors, use the same flawed strategies and are never accepted. And the next time, they repeat the same mistake. Here are some ways to avoid this. It’s not painful, it just requires effort.
What does a Proposal Evaluator Do?
My job is to reject your proposal. I fail proposals if they miss a requirement, avoid a clause or get the figures wrong. We received 36 proposals for the last RFP. Some were over 300 pages. The less I have to review, the better.
Tip: make sure the proposals are well-bound. We scribble all over them, book-marking pages, and adding comments. Don’t use cheap papers and poor ring-binders. If they fall apart, I’m not going to re-assemble your document.
- I eliminate proposals that don’t measure up. This means they fail on a technicality, are over budget, don’t agree to the deadline or have omitted to include some document.
- Then I review what’s left and make a short list.
- For me, evaluating a proposal is a process of elimination, not a process of selection. That happens later.
- When you start your proposal, don’t focus on getting selected, instead WRITE A PROPOSAL THAT CANNOT BE ELIMINATED!
Here’s how you can do this:
- Write your proposal so that the evaluator cannot reject it on a technicality.
- Respond to every requirement in the Request For Proposal (RFP). This means you cannot be dis-qualified on the grounds that you were “non-responsive to the RFP.”
- Identify the solution. If it’s a product, name it & give the version number.
- Don’t be vague. State clearly how you will do this. If possible, describe the solution in a single sentience.
- Demonstrate that you have provided this expertise in a similar project.
- Support you claims with case studies, white papers and other reports where you are given credit.
- Provide pen portraits of your team. CVs go in the appendix.
- List the benefits that your solution provides. Cross-reference these against the requirements. Itemize and prioritize each benefit.
Remember, the evaluators are looking for ways to disqualify you.
- Check your proposal once, twice and three times.
- Each time check for a different weakness or error. For example, once for writing errors, then for flaws in the solution and finally in the costs. You can make errors elsewhere but NEVER in the costs.
Once you have this established, then drill-down into each requirements and respond from the perspective of the reader. Regardless of how good you think your proposal is, if you overlook a technicality, you’re out.
What have I missed? Let me know what you think below.