When you need a writer who understands what you're talking about.

No Proposal is ever Done, You Just Run out of Time – What Does it Mean?

No Proposal is ever Done, You Just Run out of Time – What Does it Mean?

Proposal writing is a race against time

It’s been said around so many proposal writing tables, real and virtual, it’s almost an axiom of proposal development, “No proposal is ever done, you just run out of time.” What does it mean for your proposal development process, though, and how does it affect your authors and editors?

Implications for Schedule, Resources and Commitment

First, the obvious implication is that proposal writing starts full tilt and picks up from there, reaching pure insanity during the last days before “pens down.” This means you have to budget time and other resources accordingly. It also means you have to engage the kind of staff, employees, team members and consultants, who will be willing to do what it takes to meet not just the submission due date, but your intermediate deadlines. Otherwise, no matter how hard your team works at the back end, they’ll never catch up with the backlog of things left undone, partially done, or done at an early draft level.

Is “Good Enough” Really Good Enough?

Another saying, often considered one of the rules of good engineering, is that “Perfect is the enemy of good enough.” In proposal development though, “good enough” is a moving target. What’s good enough at Pink Team would be unacceptable at Red Team. What’s good enough at Red Team could be pure disaster if submitted as the final response. So, should you require your authors to provide final-submission-worthy text as their first draft? Only if you don’t want to ever have a complete draft – ask your authors for perfection and they’ll never submit anything.

Haskins and Sims say about development processes generally: “The idea is to get it good enough to begin, and then improve rapidly, rather than trying to get everything right from the beginning… managing acceptable losses… is different — and, ironically, much safer — than trying to prevent failures altogether… We need to see those losses not as failures but as investments in the future. To succeed, we have to make it cool to fail in the right places, as long as it’s recoverable, and as long as we learn from the failures and adjust.

What are “Acceptable Losses” and “Failures in the Right Places” in Proposal Writing and What Aren’t?

In proposal writing, “acceptable losses” and “failures in the right places” include having too much detail in a section, so you need to trim it, or too little, so you need to add some. They include having a heading in an early draft followed by a bulleted list of things the section will ultimately include, so reviewers can weigh in on the intended content, even if not on the actual text. They also include text that a subject matter expert (SME) still needs to verify, as long as you capture this in comments so you don’t forget to ask the SME to do it.

So, if the above are “acceptable losses,” are there “unacceptable losses” or “failures in the wrong places”? Yes, even in the early draft stage, and they get worse as you get further into the schedule. Letting your authors write before you’ve agreed on the outline, or changing outlines in midstream; failing to provide the right SME, or providing SMEs too late to support the schedule; and possibly worst, letting precious time dribble away while your authors wait for review comments or permission to continue writing. You usually have 3-4 months from draft RFP release until submission deadline, and you can count on your competitors using every last bit of that schedule. If your proposal manager doesn’t have the right process in place to avoid these and other irrecoverable failures, you’re wasting your team’s time and effort, and your money. Your competitors are working hard to get their “good enough” as close to “perfect” as they can, and making sure that even if their proposal is not truly “done” when they run out of time, it’s as close as humanly possible. Can you afford to do less?

Share Button