You want every proposal to earn the government's highest technical rating, right? Here are eleven ways to make that difficult. Copy them, or email me and I'll send them as a PDF.
In Introductions, I frequently see companies offer information the government doesn't ask for. "We provide excellent customer service... We deliver measurable results..." etc. If the solicitation doesn't ask for it, don't introduce it unless you have a very good reason - like it's as a discriminator. But discriminators should echo throughout your tech volume, and I rarely see that. Problems like this are like bad habits, and they occur when writers copy and paste sections from one proposal to the next.
In "Understanding The Requirement," too many proposals say things which demonstrate no understanding of the requirement. "Agency XYZ does… Its mission is to… Stakeholders look to it for…" Not only do evaluators know these things, they sound like they were Googled for a middle school presentation. You're making statements with no evaluation value. The best way to show you understand the requirement is to demonstrate it with implementation details in your tech approach. But if you feel compelled to make a statement, at least frame it with a message like, "...and you're about to read how we'll help you solve those challenges."
If the government uses the phrase capacity building, don't talk about capability building. If it refers to contractor responsibilities, don’t talk about workstreams. Use the government’s language. If evaluators word-search (I do!) they might miss your phrasing. And they're not impressed if they think you've rewritten the requirement, don’t understand it, or cut-and-paste your approach.
If the government says the offeror shall advise, contribute, capture, and share, it's handing you a golden opportunity to demonstrate capability to meet their requirement. It's telling you what it's looking for and you should describe how you'll do each of those things. Don't collapse all those separate actions into one, like support. If evaluators word-search, they'll miss some of your demonstration of capability. And they might wonder if you understand what’s being asked.
If the government describes three requirements and a word count shows you address them 36, 26 and 18 times, you might have caused a problem. If that’s intentional and you provide a convincing rationale, it might not hurt you. If that’s unintentional and you provide no rationale, it’ll cost you. You look like you’re either not paying attention or like you prioritized the government’s requirements the way you thought they should be. This happens easily when different SMEs author different sections, especially when they recycle previously written content. Do a word search on one you’ve submitted, or one you’re writing, and you might be surprised to see what evaluators see.
Many solicitations use key terms without defining them. Innovation, modernization, lean, customer experience, due diligence, big data, etc. To evaluate well, say what they mean to you for purposes of meeting the requirement. You need not settle technical and management consulting debates about the concept. Your job is to provide your rationale connecting key concepts with the requirement and your solution, and that's what gets evaluated. Let your competition dance around the question and your solution will read as a better demonstration of capability to meet the requirement.
I'm constantly surprised by the number of times I read reference to an approach or method with zero explanation. Statements like, "We use XYZ approach to…" "We use best practices to..." which go on to finish the thought without ever explaining the approach or practice. If you refer to method, you should at least briefly enumerate its components or steps plus explain how you'll apply it. If page space is tight, consider enumerating steps in a small call-out box and devoting more space to describing implementation.
Don't say you'll strive to do something. Say you'll do it. The government says, "The contractor shall...," and your response is, "We will..." Your statements are commitments, contractual obligations the government expects you to perform. Saying you'll strive to perform them makes you sound tentative.
Past performances appear not only as write-ups, but also as references in your technical approach. The latter is an important element in the implementation story you're telling, and in demonstrating capability to meet the requirement. But most often I read references which weaken the relevance of your past performance. To say, "We implemented XYZ method for Federal clients" implies you're capable of implementing it for the agency to which you're proposing. But to say, " We implemented XYZ method for four Federal agencies and will be ready to prevent the following risks for you…" demonstrates capability through the past performance. Which would you score higher?
I see statements like these in every proposal: "We're well-positioned to… we’re proficient at… we're regarded for..." These might be true but unless you say what being well-positioned, proficient, or regarded means for the requirement to which you're writing, evaluators can do nothing with your statement. What's worse, you sound arrogant. If you make a claim, demonstrate it. Don't make evaluators infer what you didn't say. They won't. It's not their job.
Look at proposals to see if your technical approaches demonstrate knowledge or capability. I read approaches which go on for paragraphs and pages describing the components, elements, steps, and benefits of models, methods, and frameworks - but never describe how the offeror will implement them. This tells evaluators you know that certain models, methods, and frameworks are appropriate to the requirement, but not that you know how to use them. If you’re demonstrating know-that while evaluators are looking for know-how, you’re hurting your tech eval scores.
We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.