18 Must-Dos for a Winning Proposal

ANSWER THE MAIL!!

Proposal responses can be huge. It is important to follow the bid instructionsThat’s all we ask. Just answer the mail!

In a previous article, “14 Steps to a Great Procurement Management Plan,” I described the lengths to which my team went to develop comprehensive Requests for Proposals (RFPs). These RFPs required that the respondents described their proposed solutions in a thorough, consistent, logical manner. In other words, the RFPs were designed to make it easier for the bidders to “answer the mail”, which in turn facilitated our review of the proposals.

And many of the bidders still got it wrong!

In the latter part of my IT career, I served on several proposal review teams to assist the reviewers to understand what was being proposed. In our reviews, we often had to hunt throughout the bidders’ proposals for information, or surmise what the bidders meant from context, or wade through hundreds of pages of boilerplate fluff that had little to do with the RFP requirements. Keep in mind, most of the proposals were from 3,000 to 6,000 pages in length. Also keep in mind, these bidders were asking for our business – yet they made it exceedingly difficult for us to assess why we should give it to them.

Having been on both sides of the IT services buyer/seller equation, both as a proposal writer and reviewer, I have a greater appreciation for what review teams endure when tasked with scoring proposals. No reviewer wants to disqualify a bidder simply because he or she had to hunt for relevant information. At the same time, a sloppy bid response like the ones described above did not endear the bidder to the reviewer, nor garner extra scoring points.

I have compiled four key attributes to help you to develop credible, understandable, winning proposals. These are supported by 18 “must-do” pointers that will put any bidder in a favorable position to win the project. Corporate IT departments can adapt these points when submitting an in-house response for an IT project to their management.

It’s all about them. It’s not about you.

If there is one major principle to follow in writing a proposal to a prospective client, it’s this. The RFP issuer is the buyer with a problem that needs to be solved. Your organization is an IT provider with a solution for their problem. Focus on how you can help them, not on your great capabilities. As legendary Harvard marketing professor Theodore Levitt once said, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.”

I could stop right here. If IT providers would spend their time focusing on solving the buyer’s problem, rather than beating their corporate chest, they would earn more positive responses from the reviewer team.

But there’s more …

Be professional at all times

Earlier, I used the word “sloppy” to describe many of the bid responses that I have reviewed. Imagine trying to persuade the buyer that your team will execute the project professionally while submitting a proposal that is anything but.

Here are a few tips you can use to show your professionalism:

i. Answer in the order requested. The RFPs that we issued always specified an order to be followed in the proposal response. Specifically, this allowed our review process to be more efficient.

During the proposal review we would subdivide the bidders’ responses (these were several thousand pages in length) by Subject Matter Expert (SME). This enabled the SMEs to compare the sections they were evaluating across all bid responses. If bidders did not respond according to the specified order, it made it time-consuming for the reviewers to locate the relevant information in other sections of the proposal.

ii. Answer according to exact specifications. If the RFP requires the response to the submitted on recycled paper, the bidder must submit it on recycled paper. If the RFP requires electronic submission with 1-inch margins and 12-point Helvetica font, it must be submitted exactly as specified. If it calls for a page limit for each section, the page limit should be observed. The bidder’s ability to follow instructions exactly provides the reviewers with an understanding of how well they will execute the project.

For example, I was performing a red team review (final edits) for a proposal that my firm was submitting, when I discovered that all of our key personnel resumes did not follow the format specified in the RFP. The proposal writer had inserted our standard boilerplate resumes into the proposal as-is. All required information was included; however, was not per the RFP specifications. This would not have resulted in our bid being disqualified, but it would have lowered the scoring for our key personnel.

iii. Use the prospective client’s language. Remember, it’s about them. Bidders should use the language of the client’s business as much as possible and avoid using jargon. Technical language should be relegated solely to the technical sections of the proposal.

Early in my career, our firm had won a major project to implement a statewide public assistance system. One of the criticisms of our response was that we continually used the phrase “Food Stamps Program”. The client’s policy lead informed us that the proper term was “Food Stamp Program” (not plural). This indicated to her that we did not know her business. Fortunately, it didn’t cost us the bid, but it taught us that the little things matter.

iv. Every proposal section must stand on its own. This is similar to the first sub-point above. Most bidders don’t realize that the reviewers don’t review the entire proposal. The proposals are taken apart and relevant sections are doled out to the responsible SMEs.

In their responses, IT providers often make references or call-backs to other sections of the proposal. This may save them time and may avoid repeating information; however, this practice greatly impedes the review process as reviewers hunt for the referenced section in a part of the proposal they aren’t responsible for.

v. Be careful when using boilerplate material. IT providers develop vast libraries of proposal responses over time. Some of this material becomes boilerplate for future proposals. While this can be a huge time saver, it also creates risk.

In my work as a reviewer, I have seen the bidders refer to the prospective client by the name of another organization because the response was lifted verbatim from boilerplate material. I have seen a key staff position filled by two separate individuals – again a copy-paste error. I’ve also seen boilerplate graphics included without update for this project.

Boilerplate material must be read carefully to ensure that it speaks specifically to this project for this client.

vi. Enable your content to be reviewed efficiently. Reviewers may have several proposal sections to score in a relatively short period of time. Each section may be several hundreds of pages in length. Bidders should attempt to make the reviewers’ job easier by eliminating non-essential fluff, using bullet points, formatting for easier reading (headings, sub-headings, call-outs, bolding, underlining), and using diagrams and figures to illustrate concepts more effectively.

vii. Write simply. Regardless of the sophistication of your prospective client’s reviewers, they have limited time to score the proposals. Erudite language (see what I did there?) will slow them down. A good rule of thumb is to write at an 8th-grade reading level. This is optimal for faster reading and better comprehension.

Write your content to gain your prospective client’s confidence

The client has expended much time and effort producing the RFP. The bidder should take equal care to respond to every aspect of the RFP, persuading the client that it understands the problem and can help solve it.

The following suggestions should go without saying; however, in my experience it was surprising at how often some of these elementary concepts were ignored by bidders.

viii. Show your knowledge of the prospective client. As noted earlier, it’s all about them. The bidder must do their homework, understanding who the prospective client is and why they issued the RFP. The bidder must show throughout the entire response that they understand the client’s problem.

Whenever we issued RFPs, we would include a section requesting bidders to state their understanding of the client’s business and the problem to be solved. Through their responses we could identify potentially good project partners.

ix. Provide a detailed execution strategy, deliverables plan, and project schedule. The execution strategy shows the bidder’s experience and creative approach to problem-solving. A description of deliverables establishes an early statement of scope. A well-developed project schedule, complete with critical path and key milestones, helps the review team visualize how the project will be conducted from inception through implementation.

x. Explain the what and how of your project execution, and also why. I have witnessed bid responses where the IT providers are so enamored with their own capabilities that they believe it is enough to just describe the “what” and “how” of their approach – a sort of “trust me, I’m the expert” approach. They forget to explain to the reviewer “why” they are performing those activities. As a result, an important part of the response may be lost and scored lower. The reviewer may not have fully grasped what was intended.

xi. Describe how you will manage the contract. Bidders should describe their project management methodology in terms of how they will serve the communication, quality, and project delivery needs of the client. They should describe how they will manage to the schedule and budget, and help the prospective client achieve a successful outcome.

xii. Describe how you will work with the prospective client’s staff. Most client organizations require their own staff be included on the project to serve as SMEs, user acceptance testers, and project oversight. At the same time, these staff may feel overwhelmed and intimidated by work which they are not familiar with. Bidders should describe how they will work with the client stakeholders and their staff to the overall benefit of the project.

xiii. Include the risks and potential problems. Many proposals that I have reviewed seemed to imply there would be no risks or problems during project execution. The entire project would be one long honeymoon.

Alerting the reviewers to potential risks and problem areas, along with a high-level description of how such challenges would be handled, gives them greater confidence in the bidder’s experience and capabilities.

xiv. Ghost your competition. It’s likely that a strong competitor will also be bidding. While it is important to know the prospective client, it is also important to know the competition and the potential solution they may be bidding. It is perfectly acceptable to include language in the proposal to alert the reviewer as to what “some in the industry” may offer and why such an offer would be substandard.

xv. Handle objections. In the same manner as ghosting the competition, the bidder should envision any objections that the reviewers may have while reading the proposal. The bidder should put themselves in the reviewer’s chair and read each response from that perspective. Each time they question their own content, they understand that the reviewer may have the same objections. Either the text should be rewritten to eliminate the objection, or more explanation added.

Provide your qualifications

A standard aspect of RFPs is to require bidders to describe their corporate qualifications and the qualifications of key personnel being proposed. Often, substantial scoring points are reserved for the capabilities of the bidder to execute based on corporate and personnel experience.

Some thoughts based on experience include:

xvi. Do not embellish your qualifications. Contrary to popular belief, corporate and personnel references will be checked. I’ve witnessed IT providers who have indicated that they were the developer of a major successful project, only to discover that they served as staff augmentation to the main contracting firm. I’ve seen staff members presented as experienced system development project managers, only to find that they had been managing the technology infrastructure in a data center. I’ve seen key personnel presented as having PMP credentials, to find out later that their credentials were earned based on managing a very small sub-team on a single project.

Bidders should propose their best available staff and represent their qualifications straightforwardly. Corporate qualifications regarding past project successes should be presented likewise.

xvii. Avoid bait-and-switch. Some IT providers have a reputation for bidding key personnel that meet or exceed position qualifications, but who are currently contracted on another project. While these staff members’ qualifications may earn maximum points, not delivering them or delivering someone with less experience, risks disqualification. Only key staff that are intended to work on the project should be proposed.

xviii. Provide credible testimonials. Client references and case studies are essential to validate the content of the proposal and the solution that is offered. Testimonials from past clients for projects similar to the project being bid are highly effective. If possible, direct quotes from past clients’ executives should be included. Compelling stories of past successes are instrumental in persuading the reviewers to give a higher score.

These are important considerations when determining how to structure a winning proposal. Given all of that, nothing is more important than reminding yourself that it’s not about you.

It’s all about them.

Remind yourself to stress the people aspects of how you will conduct the project. That goes a long way in “answering the mail.”


Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.