Proposal Writing: How to Analyze the Buyer’s Mindset

In theory, responding to an RFP should be a simply task. As each RFP has a fixed set of requirements you, the bidder, should simply have to answer these in order to be considered.

Download Now for only $19.99

Download Template

Learn more about these Proposal Templates ]

Proposal Writing: how to analyze the buyer’s mindset

Let consider the following scenario:

“As the RFP’s author, with a significant stake in the project’s success, I am very anxious that I could select the wrong partner and jeopardize both my own position and also the agency that I represent.

It is for this reason that you, as a prospective contractor, need to convince me that you possess the ability to address both my immediate (and long-term) requirements as captured in the RFP and also those that I may have overlooked or omitted, for whatever reason.

Therefore, when you respond to my RFP, it is imperative that you answer every point in the document correctly but also consider the possibility that there are areas to need to be explored for this project to succeed.”

In the competitive world of government contracting, it is not enough to merely answer the requirements as set out in the RFP.

You have to go much further than this; to win this contract you need to convince me that you understand WHY I have prepared this RFP and are sensitive to my needs, both spoken and unspoken, during this project.

After all, I am expecting that your expertise will uncover areas that I have overlooked and you can resolve these without exploiting me financially.

Most proposals that an RFP evaluation team receive are very similar in tone, content, style, and cost.

For the most part, they are dull, formulaic, and repetitive.

Almost all are congested with jaded business clichés, the buzzword of the month, and resort to pseudo-jargon whenever possible.

Though I have years of experience in my industry sector, the proposal’s authors frequently speak down to me, avoid the key ‘pain points’ highlighted in our RFP and attempt to impress me with new technologies, many of which they have not even implemented themselves.

In short, despite what their executive summary may profess, they make no real effort to understand my needs and even worse, don’t appear to grasp the urgency behind this proposal nor the months of effort my team put into it. It feels that we were simply another proposal on their lengthy to-do list.

Question: Do you know how a proposal is typically evaluated in your country?

If not, contact your national procurement agency and ask for the guidelines on proposal evaluation. If none are available, contact the government agency who issued the RFP and ask if they have guidelines. You can do this either before you submit your proposal or during the clarification stages.

With this in mind, if you sincerely want to win my business, you need to differentiate your proposal from the rest of the pack as otherwise they are politely refused. Future submissions from your company will not be anticipated with much enthusiasm.

So, if you acknowledge this and want to raise the profile of your submissions, consider the following.

Identify the individuals in my team who will ‘buy’ this project.

After all, I don’t make the final decision on my own. On the contrary, I will consult with my colleagues through-out the entire procurement process.

Making an impression involves analyzing the buyer’s interests. In other words, you need to consider what types of buyers are involved in the procurement process and then write your proposal around their needs. For example:

Examine the Technical Buyers

What does the technical buyer look for?

  • Is it a track record of similar deployments or is s/he interested in a particular skill-set?
  • This person’s role is to screen out technologies that do not align with their strategy.
  • It’s also to determine if you really have the expertise you claim you have.

This person(s) may be in the business for many years and could be (read: will be) suspicious when dealing with unproven consultants. S/he has been burnt before and does not want to engage another ‘cowboy’ who will ruin their project.

How do you prove you are trustworthy?

Understanding the Finance Officer’s Criteria

What is the financial controller interested in?

This person will have the final word on the project’s go-ahead.

They are solely concerned with the bottom line and how you will impact their profit margin. This person is afraid that you will exploit grey areas in the contract to your advantage, such as forcing the project into extended change control and accumulating additional man days.

How do you reduce these fears?

They will ask colleagues (i.e. due diligence) to get an idea of how you operate and will listen to those who have worked with you. If you are new in town, they may make them more nervous as you could potentially disappear in mid-project or prove to be a totally unsuitable match.

Understanding the Operations Manager’s Concerns

How does your proposal go down with the Operation buyer?

This person will work with your team on a daily basis and could be concerned with ‘rumors’ that you will try to bully or intimidate staff during projects. Some consultancies come with a very tarnished name!

This person is concerned that s/he may be excluded from the project’s success or blamed if it fails. After your team has left, this person will have to use the solution that you will have implemented. Remember: one reason you are being contracted is because this person’s team do not have the skills to implement the solution by themselves – this area can be a very sensitive!

Now that we know that there is a ‘team’ of buyers, each of whom may have a different appreciation of your proposal, you need to prepare all communications with this in mind.

The buyers know that their proposal is not perfect and that there are gaps, inconsistencies, and errors in its construction. But they expect you to accept this and patiently help them to remedy the situation.

What I’m emphasizing here is that you need to build trust with us, the buyers, and unless you have a physiological profile of us in mind, your proposal will probably miss the mark.

You see, we have never met face to face. You don’t even know my name. But, I may know quite a lot about you – and some of what I’ve heard may not be very nice.

If you take this on board, your proposal needs to go to great length to assuage these fears and demonstrate repeatedly that you are not just going through the motions with this bid but have a very compelling argument that will justify us in awarding you with this business.

Profiling the Buyers

Keeping in mind that we are a team of buyers, you need to prepare profiles for each role. You won’t get it 100% right the first time, but you will definitely be moving in the right direction while your competitors are laboriously cranking out the same ‘boiler-plate’ proposal as per usual.

To understand the buyers:

  • Classify the team members based on their role and estimate their input (i.e. influence) into the final approval.
  • Define each member as a buying type. Note that some buyers may have more that one role, e.g. the CTO may have a role in the technical evaluation and signing off the project budget.
  • For each buyer, identify their fears, hopes, anxieties and what they would consider to be major success factors.
  • Put these in a matrix and cross-reference this when evaluating your own proposal. Apply weights and values if appropriate.
  • Once you have completed this task, the next step is to write your response with these buyers in mind. Remember: you are not writing to an anonymous disembodied entity – there is a very real person examining your proposal.

With these profiles at hand, you can blend into your proposal all those points that answer all the unspoken requirements not laid out in the proposal.

Thousands of templates to jump start your project

Acceptance Test Plan

Contingency Plan

Software Development Templates

Acquisition Plan

Conversion Plan

Software Requirements Specification

Action Plan

Cost Benefit Analysis

Software Testing

API Documentation

Database Design

Standard Operating Procedures (SOP)

Audience Analysis

Datasheet

Statement of Work

Availability Plan

Deployment Plan

System Administration Guide

Bill of Materials

Design Document

System Boundary

Business Case

Disaster Recovery Plan

System Design Document

Business Continuity

Disposition Plan

System Specifications

Business Plan

Documentation Plan

Technical Writing Templates

Business Process

Employee Handbook

Test Plan

Business Requirements

Error Message Guide

Training Plan

Business Rules

Expression of Interest

Transition Plan

Capacity Plan

Fact Sheet

Troubleshooting Guide

Case Study

Feasibility Study

Use Case

Change Management Plan

Functional Requirements

User Guide

Communication Plan

Grant Proposal

Verification and Validation Plan

Concept of Operations

Implementation Plan

White Papers

Concept Proposal

Installation Plan

Work Instructions

Configuration Management Plan

Interface Control Document

Software Development Templates

Acceptance Test Plan

Maintenance Plan

Software Requirements Specification

Acquisition Plan

Market Research

Software Testing

Action Plan

Marketing Plan

Standard Operating Procedures (SOP)

API Documentation

Needs Statement

Statement of Work

Audience Analysis

Operations Guide

System Administration Guide

Availability Plan

Policy Manual

System Boundary

Bill of Materials

Project Plan

System Design Document

Business Case

Proposal Manager Templates

System Specifications

Business Continuity

Proposal Template

Technical Writing Templates

Business Plan

Quality Assurance Plan

Test Plan

Business Process

Release Notes

Training Plan

Business Requirements

Request for Proposal

Transition Plan

Business Rules

Risk Management Plan

Troubleshooting Guide

Capacity Plan

Scope of Work

Use Case

Case Study

Security Plan

User Guide

Change Management Plan

Service Level Agreement (SLA)

Verification and Validation Plan

Communication Plan

Setup Guide

White Papers

Concept of Operations

Social Media Policy

Work Instructions

Concept Proposal

Contingency Plan

 

Configuration Management Plan

Conversion Plan