Do you understand how to show you understand? (Part 1 of 2)

RFPs regularly ask bidders to demonstrate understanding. The understanding section(s) is challenging to write. Your understanding sets the stage for the solution you propose and its substantiated benefits. A mediocre understanding reduces customer confidence in your ability to perform the work. Here are six common pitfalls and how to avoid them.

Pitfall #1: Weak words

We understand. We recognize. We believe. These are common ways bidders try to demonstrate understanding. But using these crutch words does nothing to build customer confidence. In fact, these common phrases weaken your understanding section. Look at the example below.

The ABC Team understands the complexities and challenges associated with the contract.

This sentence says nothing. The proposal would be much more convincing if the bidder described the referenced complexities and challenges based on customer knowledge, industry research, lessons learned, and the like. An insightful description of the as-is environment sets the stage to present the features, benefits, and proofs of your approach. Using qualifiers such as we understand, believe, or feel only weakens the narrative.

Tip #1: Describe the program complexities and customer needs underlying the RFP, setting you up to then show how you will solve their problems. Delete all instances of we understand, recognize, believe, or feel.

Pitfall #2: The cut and paste

Another typical way to start an understanding narrative is to repeat back from the agency website the customer mission and/or to repeat the program objectives stated in the scope of work. Again, this information is fluff. The customer knows their mission. They know the program objectives. Repeating this information only shows you can cut and paste.

Tip #2: Discuss why the customer established the program objectives and how these relate to the mission, using your own words. Of course, this narrative requires that the capture team communicate these underlying needs to the proposal team.

Pitfall #3 The list of past projects

Many bidders pepper their understanding section with long lists of agencies and project names. Corporate experience examples only show understanding if they directly tie to what the customer is seeking. Bridging an experience example to a customer need requires that you show how lessons learned, results achieved, problems solved, etc. give you insights into what this customer wants. Listing all the agencies that are your customers in and of itself does not demonstrate understanding.

Tip #3: Share situations you faced on relevant customer contracts (especially those you are referencing as past performance examples) and how you addressed them. Present problems you solved and results you achieved.

Pitfall #4 Parroting requirements

Another common pitfall is to present a requirements summary rather than an understanding. Often, proposals present a re-statement of the SOW or performance work statement (PWS). If the customer listed requirements, parroting these requirements does nothing to demonstrate your customer knowledge.

Tip #4: Critically assess your understanding section. Are you showing the underlying hot buttons, challenges, risks, and problems that you will solve, or are you merely parroting requirements? Lack of knowledge of customer concerns is a red flag that either you have not done capture or capture has not done a proper hand off to the proposal team.

Pitfall #5 Visuals that ignore the audience

Evaluators make snap judgments about a proposal based on its appearance. Most proposal teams fail to investigate the customer’s response to visual cues. The submitted proposal may then be a turn off to the evaluators.

Tip #5: Learn their true colors. Review customer work products such as reports, web sites, presentations, and the like to understand color palettes that resonate, whether they prefer text or graphic-heavy material, bullets or tables, or other hints as to their potential response to your proposal.

Pitfall #6 Risks that aren’t risks

A great way to demonstrate understanding is through your risk management plan. Yet, often, the risks bidders list in proposals are statements, not risks. For example:

Incumbent capture

This is not a risk. It is an activity.

Tip #6: Develop if-then risk statements, and then describe mitigations:

If the selected vendor does not capture incumbents, then the program will face service disruption.

Follow this if-then statement with your mitigation. How will you capture incumbents, as proven by which successful transitions?

An insightful risk approach will also identify risk probabilities and impacts pre- and post-mitigation. All risks presented should be from the customer’s perspective, which again requires that you know the customer.

Part 2 of this understanding series will dive deeper into how to prepare a great risk mitigation approach that demonstrates your understanding of the customer and the contract.

by Lisa Pafe, APMP-NCA President, CPP APMP Fellow, and PMI PMP

Connect with Lisa Pafe on LinkedIn

Lohfeld Consulting

See Full Bio