Proposals

Purpose

The following are actionable tactics to improve the ROI of time spent writing proposals.

Scope

Covers principles and process for finding and writing proposals at Countable. The author is most experienced writing proposals for the public sector.

Principles

  • The process starts before you start writing. You want to make sure the odds are stacked in your favour before you invest in writing anything.
  • Specialize! Choose similar projects, so you can re-use bits of old proposals that worked. It’s better to solve the same problem really well than to spread yourself thin. Choose an RFP in an area where you have the most expertise, similar work (including successes to hilight), and have a network of people in that area. Countable’s niches are web maps, healthcare and optimizing citizen flows for government.
  • Use your network’s experience, and team up. If you know someone who would be really great to add to your team, write them into the proposal too, and give them a small cut just for being present, even if they do very little work.
  • Score before you Send. Get someone who understands the client to evaluate your proposal and give you a score based on the official criteria before you submit.
  • Ask questions to qualify or disqualify the project, before writing. Your questions should increase trust, fill in blanks, and unearth hidden needs behind the RFP. Find out the truth about whether you can knock it out of the park. Examples “Would you consider a team outside your industry who can bring fresh ideas, or prefer a firm with lots of industry experience?”
  • Keep the proposal as short as possible while addressing the criteria and building trust.

Process

In brackets, we indicate the approximate time to allocate (not actual effort, just time to leave open)

  1. CAPTURE - find RFPs you can win (This should be happening all the time as described in Sales)
  2. PRE-QUALIFY - look a bit deeper (Score in our OPPORTUNITIES sheet)
  3. QUALIFY - (5 days) (ask questions as soon as possible after deciding to write, wait for responses)
  4. DRAFT - (2 to 6 days) (coordinator creates working doc right away, tags people in based on roles and expertise)
  5. REVIEW - (2-3 days) (use an external/impartial reviewer to simulate grading the proposal)
  6. REFINE - (1-3 days) (incorporate requested changes, saving time for one major refinement/copyedit) (Note: we’ll now observe a content freeze one full day before submission to allow for this)
  7. SUBMIT - (1 day)
  8. LEARN - save any feedback we get on RFPs in the same folder; update this document as we learn

Further notes to the above process points:

  • Reserve the last day for polishing (no new content contributions, by design)
  • 48 hours before the deadline is the last point we can do the offiical review/scoring.
  • For contributors, the coordinator should indicate what portions they should look at. Most people don’t need to read the whole thing.
  • Provide some indexing on what documents we have, for easier navigation of the repo?
  • By the 48 hours mark, a good quality version with all content and a lens to evaluation (in navigation) should be present.

Scoring Opportunities

In the Opportunities (SCORE) spreadsheet, we allot Pipeline % in the following manner:

  • When we’ve decided to apply for an opportunity, set it at 20%
  • When the application is clearly moving forward/we’re a frontrunner, set it at 50%
  • When we’ve received the opportunity, set it at 100%
  • If we’ve lost the opportunity, set it at 0%

1. RFP Lead Capture

Record the RFP due date, organization and link in a spreadsheet, along with its score as follows:

  • 20 points if the RFP is in your niche of products and services. Partial points if the industry matches, but not the exact service/product (it’s nearby).
  • 10 points for tech match. Mention of any from: Django, Node, Postgres, Vue, React, javascript, web mapping, etc. Deduct points for .NET, SAP.
  • 10 points if the final result publicly browsable, for portfolio value.
  • 10 if scoring criteria is explained in the RFP.
  • 10 points if Scrum or Agile is mentioned, partial (5) points if it the project is phased with a prototype.
  • 20 points for contract size. 0 for $10k, 5 for $20k, 10 for $50k, 15 for $100k, 20 for $200k and up, 15 for over $500k, 10 for over $1M. (This reflects our ideal project budget range of $100-500k)
  • 10 points if the RFP offers losing proposals a debrief on the scoring.
  • BONUS points if it’s an existing relationship, we can keep the IP for future use, or open source it, or some other circumstance.

50 points is the cut-off for moving on to PRE-QUALIFY

2. Pre-qualify

  1. Review all evaluation criteria. What is the estimated score we could get on the project? Is it within 5% of frontrunner’s estimated score? If not, move on.
  2. Look deeper at the proposal to see if it’s in your niche and you have a uniquely great offering that will both let you execute well and develop your niche stratgically. If not, move on.
  3. Estimate bid size, based on beating the frontrunner’s score by 5%. If there’s no budget for the project, estimate one based on past similar projects by the frontrunner, prospect, and software category. Is this amount profitable? If not, move on.
  4. Is the total timeline under 10 days? If so, the proposal is probably “wired” to be given to a specific company. Skip it.
  5. Determine who is the “frontrunner”, most likely to bid and win the project. Is there a strong off-the-shelf solution which is compatible, with a local supplier? What is the industry “state of the art” in this area. What is being used by others? What companies have won similar projects in the past. What vendors have the client used for similar projects before? Who has beat you on similar RFPs before? Public sector projects will often list applicants directly, or you will be able to identify them in the Q&A addendum shared with the group a few days in.

3. Qualify

You’ll want to ask a few questions before writing. If possible, get on the phone with someone in order to make a “conceptual agreement”. The goals are to get the interest and then the guidance of the buyer, and understand their priorities. Demonstrate a genuine interest in the outcome of the project, build trust, and fill in gaps regarding how well the proposals fits.

  1. If any of the critical info in our capture questions is unknown, ask it now (approx budget, technology options, can we use Scrum,
  2. Ask: What is the most important benefit to this project for a successful outcome?
  3. Make a super clear, one sentence statement of your unique approach. Ask the prospect if it’s a good approach.
  4. Ask questions to clarify any scoring criteria so you’re 100% clear what they each mean.
  5. Ask questions to help you understand what the evaluators are looking for.
  6. If the project solves a real problem, there should be an existing (partial, bad) solution. Ask “How are you currently getting by without this solution? What process will we be replacing?”.
  7. Get clarity on anything that might disqualify you, if you’re unsure about any of the mandatory criteria.
  8. If any key consideration is left out of the proposal, ask if it’s important the product be: Secure, Flexible, Scalable, Low maintenance or total ownership cost, Durable data.

Also, create several touchpoints (LinkedIn, email, phone) to get to know them before you write. If there’s a way to demonstrate your system woring, that is ideal.

Attend any pre-proposal call, webinar or meeting in order to meet the evaluators.

Do any further research to have information you need to decide to write.

4. Deciding to Write

With all the above done, you should now determine whether to write, or move on to a new RFP. You should know your approximate chances of winning, the value of the contract, and your alternatives, and make the best choice.

Are you the frontrunner? If not, can you propose a solution that is better in some way that matters to the prospect? The answer to one of these questions should be YES if you want to write. You must believe you have a good chance of winning based on all the information so far.

Proposal Writing Roles

Assign these roles to people at the top of the proposal draft:

This is the most important role in the process, driving forward everyone else’sales involvement and contributions. The coordinator’s job is to make sure:

  • The rest of the process below is followed by our team.
  • It’s clear in writing (Google Docs comments) who contributes what parts right away.
  • We finish early so we have time (ideally 5 days) for external review.
  • Double-check each contributor doesn’t miss any mandatory requirements or scored criteria.
  • Compiling the final deliverables in the correct format for submission.
  • The proposal is submitted on-time, making sure that any submission pre-requisites are met well in advance. Submitting right before the deadline will often result in a failure to submit correctly.

Identify someone to simulate the client scoring your proposal later on. They shouldn’t be involved in writing.

When they are tagged in to review the document, they should be directed in a meaningful way to not just the working document, but the original RFP description and specific evaluation criteria or rubric.

The Coordinator should ensure it’s clear to each technical author what section they must contribute. Use Google Docs task assignments.

  1. Create a folder for the proposal in Google Drive
  2. Save the original RFP and any supporting documents there.
  3. Past the mandatory and scored criteria from the RFP into a new Google Doc (in the color RED) to start a proposal outline (see below)
  4. Include, at the top of the outline (in the color GREEN): who is filling each of the Roles defined above, links to similar successful proposals and notes on their score, any answers to questions we wrote, or notes from the qualification process.

Copy most if not all of the original proposal into a Google Doc, invite everyone who will work on it, and proceed to copy the structure of the original RFP as your proposal structure. Write your proposal inline to the original RFP.

Write responses inline to the original RFP and mirror RFP document structure. Then, add the following sections if they’re not already there, but keep them very small/simple.
  • In the intro (if applicable), summarize the real needs underlying the proposal.
  • Who is the buyer’s customer and how will they benefit?
  • Indicate how technology has changed recently to allow a better solution, and how we deliver that.
  • Indicate a low total cost of ownership, and side benefits to their business. Indicate they’ll want to use the new system all the time.
  • Indicate why your company is specifically interested in this project and its results.
  • What makes your solution unique?
  • High level summary of your approach, with evidence from past projects that it will work.
  • How will a successful outcome be measured?
  • Optimize for clarity, not sophistication or length.
  • It should be clear how every sentence relates to the evlauation criteria. If any sentence is not clearly providing evidence or building trust, remove it. Efficient communication that knows just what to leave out is a great demonstration of confidence and expertise.
  • Include an visual or diagrams (about one every 2 pages)
  • Use the active voice, with optimistic tone.
  • Mention the customer, more often than you mention your own company.
What really matters (hidden need), and why will you deliver it better than the other bidders?
  • How is your approach different and will lead to a better result?
  • How does this project relate to your mission, values, and your team’s experience? Include a couple stories about this, to create a special connection to the project.

In particular, if you’re not the frontrunner, this is critical. Plant a seed of doubt about the frontrunner and build on that. A good one is that as a newcomer you can provide more customization because your product is still more flexible and early in its development lifecycle.

If you are the a frontrunner, point to your past successes. Your angle is to create concern that other solutions don’t have as much evidence of ability to deliver.

Include photos and some personal notes that relate each team member to the project, and their relevant past successes.

  • Highlight their industry, location and other parts of their identity.
  • Draw attention to the relevance of your prior work.
  • Leave out details that don’t indicate how similar your prior projects are to the current RFP, or how successful they were.

List features of your platform that align with the real problems behind the RFP and the stated criteria, and for each feature, list the benefits which solve those problems and provide evidence.

If the RFP has scoring criteria already, this should be your focus.

Don’t try to be clever and make up a proposal structure based on your domain knowledge. Instead, write your proposal inline to the original RFP, and include the original wording in a different font. This will make it easy to mark, clear you’ve missed no mandatory criteria, and clear how to score you.

In each section, the person creating the outline should make a note of the person from our team best qualified to write that section so it’s very clear who is contributing each section of the proposal. Mention and assign that person using a Google Docs comment.

There are usually 2 types of criteria. First, a list of things that could disqualify you. Second, a list of categories where you can score points.

For the first category, make a checklist and make sure you’re 100% confident in those items being checked off before you submit. For the actual scoring, it’s likely the prospect has a committee reviewing scores, and likely they’ll even be “blind”. This means they’ll be worried about being perceived as unfair, and will usually follow the criteria quite literally.

For scoring criteria that are clear, focus on creating the most truthful answer that will get the highest score. Get a “proxy” person to score you, and iterate to improve your score.

For scoring criteria that are less clear, there’s going to be more subjectivity. Find out what probably matters most to your evaluators, going back to the questions you asked earlier.

5. External Review Step

  • Get an external reviewer to pretend to be the buyer.
  • They must evaluate according to the official criteria.
  • Refine before sending.

6. Submit

Submission platforms can be buggy or broken sometimes, so get familiar with the platform you are submitting on and click through to the last step right away. Make sure you leave enough time to submit: we recommend submitting 1 day in advance in case something goes wrong.

7. Learn

The best way to measure proposal win-rate is “revenue won” / “revenue bid”, because it reflects the proposal value.

50% is a sweet spot to aim for, to balance risk-taking and revenue.

Get a debriefing whenever possible.

Specific Proposal Types:

Often, we are proposing a Django based project as a more flexible, cheaper, faster and more maintainable alternative to an ERP implementation (Enterprise Resource Planning). Here are some problems with ERPs that we solve for our clients:

  • It takes an average of 11 months after go-live for SMBs to realize benefits from an ERP [1], whereas our implementations typically realize benefits in 6 to 8 weeks due to our rapid prototyping approach in the first 2 weeks.
  • In an ERP usage survey, only 14 of 287 respondents reported realizing the benefits of “Upgrading Technology” with an ERP, and 34 of 150 respondents realized the “Growth”-related goals they had when implementing ERP. ERP were more effective at realizing “Operational Efficiency” goals, however with 103 of 122 respondents reporting success.
  • Regarding ERPs “Of those organizations that have completed implementation, less than half (45%) experienced budget overruns. However, those that did experience overruns were an average of 24% over budget. When

you’re talking about an implementation budget, 24% is a lot of money. On average, organizations reported an expected budget of $1,007,767 and an actual budget of $1,247,859.” [1]

[1] 2019 ERP Report, Panoram Consulting Solutions.