(7) Provide responses that are tailored to the instructions and requirements, instead of irrelevant boilerplate text.
It’s easy to fall into the trap of reusing the same proposal responses over and over again. Instead of generating fresh content, many proposal writers get lazy and simply copy content from old proposals and paste it in as content for each and every proposal they write without editing or updating the response.
While it’s a best practice to maintain a proposal library of reusable content, when reusing this content, it should always be tailored to provide a response that is relevant to the specific proposal instructions / performance requirements – otherwise, it’s just fluff. Fluff distracts evaluators from your message.
Used in excess, boilerplate sedates evaluators. When proposals contain mounds and mounds of boilerplate, this is viewed as “padding” the proposal with useless, unsubstantiated, general, and/or vague information. Such generic responses reflect no customer intimacy or understanding.
To avoid the temptation of reusing irrelevant boilerplate text as part of your proposal response, update the reusable content to address a specific customer issue, to provide a value-added approach that resolves this issue, and/or to include more recent and relevant experience. Chances are, since the time you originally wrote the content, you’ve performed additional similar work that can be cited instead of referencing the potentially outdated experience. For example, the number of task orders you’re managing is probably higher, or the number of relevant products you’ve delivered has certainly increased. Boilerplate should always be updated with current facts, statistics, and metrics.
Always ensure each and every proposal response reflects an understanding of the targeted customer environment and the customer’s specific needs. While you may propose the same or similar technical approaches to meet various customers’ requirements and perform associated tasks, ensure that the description of your approach is responsive to the specific SOW / PWS requirements so that your proposal is compliant. For example, many customers typically require very different deliverables for similar tasks.
If your boilerplate approach for a design-related task includes generation of design documents, but the SOW / PWS requirements specify deliverables for high level design documents, detailed design documents, and a design review, then you need to address the additional requirements through an update to your boilerplate response describing your design approach.
One of the most common abuses of reusing irrelevant boilerplate text without repurposing it for the specific proposal involves the management approach, particularly risk management and quality management. Even in these instances, the boilerplate content can be tailored to define risk mitigations for specific contract / program risks associated with schedule, technical, or cost performance, and to meet specific performance standards for the unique quality performance objectives through appropriate quality control procedures, respectively.
Use your boilerplate and proposal “model content” when writing proposals to save time and reuse winning responses, but don’t abuse it at the cost of submitting a proposal that is not compliant, compelling, or customer-focused!
Comments