With the US Federal fiscal year coming to an end, we’re seeing a big uptick in the proposal review process. As you scramble to get your proposal in, try to make time to check for 3 types of ‘bad language’. Bad language that, if left in your proposal, can increase program delivery risk and lower your pWin.
To give a sense of what I mean, take a look at this statement:
“Ensure continued full continuity of IT support operations through a seamless transition from the existing contractor.”
There are 3 immediate issues:
- ‘Ensure’ is a guarantee.
- ‘full continuity’ is not quantified
- ‘seamless’ is clichéd & not quantified
And what about this opener in an exec summary:
“Our focus is on rapidly developing solutions that result in valued outcomes for our clients by exploring new models of the future while providing direction and promise over the paradigms of the past.”
“paradigms of the past”! What kind of impression does this leave?
Of course, it’s really tedious to check for this type of bad language in MS-Word. CTRL+F becomes your best friend as you do ‘repeated searches’. But it’s a catch 22 deal, most of us are really right on time, so manually searching docs for ‘dictionaries of banned terms’ is likely unrealistic. But if you’re serious about your proposal review and winning Government business, you can’t avoid removing content like this.
How can you do it? At the end of this post, I’ll provide some search automation options for flagging this ‘crappy language’ really quickly.
But first, let’s cover out the 3 types of ‘bad language’ that you need to identify.
Check 1: Cliches and ‘over the top’ language
Recognize any of these from your proposal?
“We are a world class provider of…”
“Thinking outside of the box…”
“Best of breed solution…”
“Value-added proposition…”
“In today’s highly competitive marketplace…”
These are examples of meaningless marketing boilerplate. Trite statements and clichés damage your credibility and do nothing for your case.
To fix this, use a list of clichés like this list from one of our previous posts in 2011.
Check 2: Deliverability – proposal delivery risk and cost
Requirement statements that are not testable or measurable may result in unintended consequences. These can include product/system defects, components built outside acceptable tolerances, and systems that meet the proposal guidelines, but not the intent of the SOW or RFP.
There are unsupportable claims, superlatives, overly inclusive or unnecessarily negative terms or firm guarantees not required in the T&Cs. If you inadvertently make a promise or guarantee that you cannot deliver on, it exposes you to legal action during program delivery or re-negotiation at a later stage.
There are a number of risk categories to check:
- Proposal Measurability: These are phrases or terms that are not sufficiently concrete or open to different interpretations. They are really hard to measure and test. Examples: “high”, “low”, “earliest”, “latest”, “accurate”, “eligible”, “heavy”, “light”.
- Optional: These phrases suggest doing more than what is stated or running the risk of scope creep during program delivery, especially for IT programs. Examples: “might”, “may”, “could”, “should”, “possibly”, and “probably”.
- Imprecise & Subjective: Different individuals may interpret terms differently. Examples: “typically”, “correctly”, “correct”, “convenient”, “clearly”, “easy to use”, “acceptable”, and “unacceptable”.
- Open Ended: Items such as ‘e.g.’ imply there are more elements to consider, but they are not listed. It is unclear, and your proposal could be seen to be hiding important elements from the reviewer. Examples: “e.g.”, “for example”, “for instance”, “etc.”, “but not limited to”, “including”.
- Unachievable – Too Specific: These are statements that look compelling but are generally not realistic in the real world and need specific measures outlined to be testable. Examples: “24 x 7”, “7 x 24”, “100% uptime”, and “100% availability”.
Check 3: Credibility
Your credibility is not enhanced by a number of credibility killers.
Here are examples of language with poor impact:
- Grovelling, poor tone: Examples: “we are pleased to”, “honored to”, “delighted to”, “for your consideration”.
- Leftovers: Many proposals are copied from past proposals. Leaving in the old customer name or old proposal id is a credibility killer. Scan for all references to the wrong customer or products.
- Poor Preparation: Before signing off on documents, scan them to ensure they are clear of these terms. Examples: “to be completed”, “TBC”, “TBD”, “TO DO”, “TODO”.
With so little time, how do you fix this?
You might think that scanning for these proposal-killing elements is difficult and time-consuming during a proposal review.
It is! (at least doing so manually).
But the risk of not doing so is something you need to be conscious of.
First, the easy bit, decide what your baseline ‘Bad Language’ dictionary will be. Use as a basis, dictionaries like this list from one of our previous posts in 2011.
Now how do you actually check your proposal? Here are some approaches we’ve seen:
- Manual check: the most obvious option but one that is hardest to do well. It’s very time-consuming and not practical in the real world.
- Create MS Word Macros: We’ve seen some who have created MS Word macros to codify the dictionaries of illicit terms. This works well if you have IT support or you can knock up some code yourself. Many proposal managers don’t have the time for that. But if you can get help from your IT colleagues they may be able to help.
- Use a solution like VT Docs: Now, if you’re a VisibleThread user, it’s already baked into the product. You select your proposal in VisibleThread, click on the Quality Analysis tab, and use a specific dictionary. Start by using our pre-defined quality list ‘Bid – Review Scan V6’. If you want to customize it further, just go to the dictionary location and edit OR import new terms from a CSV (comma-separated) file, editable in Excel. See how it works with this short video
Whichever approach you use, the goal is to make sure your proposal is credible and defensible.
Takeaways:
Here are some quick takeaways:
- There are 3 categories of ‘bad language’ that you need to check for prior to submitting a proposal.
- If not addressed, bad language exposes you to credibility issues and program delivery risk.
- If you only have MS Word, try getting help from your IT support colleagues to build macros.
- If you’re a VisibleThread user, just run a ‘Quality Dictionary’ scan with the ‘Bid – Review Scan V6’ dictionary.
