What it Takes to Win

You should structure your business development and proposal processes around what it will take to win. The problem is that most people prepare their proposals without having a clear idea what it will take to win. Only the customer really knows what that will take, so many companies don't even try to answer it.

Government RFPs make it easy to be lazy. They give you the evaluation criteria. The process is heavily regulated. You can follow the process, be RFP compliant, and even optimize against the evaluation criteria, all without really understanding what it will take to win. People frequently find themselves writing the proposal and then sprinkling some themes and win strategies in at the last minute.

When you ask yourself what it takes to win, each item you consider leads to more items that you need in order to get there. Each layer that you peel back takes you further back in time. It also tells you what you need to do at each step to arrive at the winning proposal. It can be a very helpful exercise to show people why they need to take action early in the process instead of waiting until the end.

To win a government proposal, you need to get the best score during the evaluation process, have the right price, and present the right offering. The right price is not always the lowest price. But it has to be competitive, within their budget, and well substantiated. The right offering must not only meet the specifications, but must also help the customer achieve their goals, wants, and desires.

To achieve the best score on a government proposal requires you to design your proposal around the evaluation criteria and process. Instead of simply writing the proposal, you must plan and design your content to achieve the best possible score. You also should establish a positive relationship with the customer before the RFP is released. If the customer wants to select you, it can only help your score.

Designing a proposal to win starts with having an outline that matches not only the instructions in the RFP, but also their evaluation forms and procedures. You should make smart use of layout design and navigation aids (RFP relevance boxes, cross-reference tables, etc.) to make it easier for the evaluators to see how to give you the maximum points for each section. Finally, you should communicate visually and use graphics to the maximum extent possible, to make it easier for the evaluators to quickly read, assess, and score your proposal. To do this, you are going to need to know how the customer evaluates their proposals --- not just what it says in the RFP, but their internal procedures, preferences, and tendencies. This information is available, and often even published, so often it's just a matter of asking about it early while you can still get it. Finally, keep in mind that each proposal is unique. Never use boilerplate unedited. There are so many variables in the customer, offering, evaluation criteria, and competitive environment, that you need to customize your design for each proposal.

You must plan your proposal's content in order to maximize its score. This starts by having an offering that reflects what the customer wants. But it also requires having good representation of the keywords in the RFP, the right points of emphasis, and alignment between your content and the evaluation criteria to maximize your score. Once you have achieved these things, you can focus on having a persuasive presentation. If you start by writing, and don't plan all of the goals the writing needs to accomplish, there is no way you can achieve the best possible score.

So how do you get the right offering that will make the customer want to select you, above and beyond the procedures for scoring the proposal? First, you need to have the right understanding of the customer's needs. The solution that you develop to meet the customer's needs must also fall within their budget. Achieving that means making accurate estimates and making the right trade-offs. The right trade-offs are the ones that reflect the customer's preferences. To achieve that means you have to know which trade-offs the customer would prefer. You also need to develop your offering to reflect how you wish to position yourself against the competition. Finally, in presenting your offering, you need to include the right level of detail. Doing this requires understanding what level of detail the customer wants. Ultimately, all you really need to do is to give the customer more of what they want than any competing offer. All you need to do this is to know more about the customer's current state, goals, issues, wants, desires, needs, level of consensus, politics, etc.

You cannot achieve this level of understanding from the RFP alone. To have the right understanding, you need to have a positive customer relationship, knowledge of their needs and the nature of the opportunity, and understanding of the competitive environment. A certain amount of self-awareness will also be required to understand the alignment of your own organization with the customer, as well as to anticipate what you need to do to pursue it.

So what does it really take to win? There is one thing that drives every item described above. To win you need the relationships that provide the intelligence you need to design and execute a winning plan. If you start with a winning proposal and peel back the layers, you end up going back in time to before the RFP is released. Winning starts with pre-RFP relationships. But it takes more than just the relationship itself. The relationship must satisfy the information needs of activity at every step along the way.

Whether you are developing your offering, planning and designing your proposal, or writing the proposal content, being successful requires information that is dependent on a pre-RFP relationship. A successful pursuit process will not only start pre-RFP and get that information, but will follow through to make sure that the information results in the best evaluation score backed by an offering that delivers what the customer wants at the right price.

Copyright © 2007. Please review the Terms of Use prior to copying or distributing.