How to avoid getting caught in the proposal death spiral

The proposal death spiral happens when you get to the proposal review and things are so bad that you have to have another review to make sure they’re better, only to find more things to change, and you enter an infinite loop that’s only broken when the deadline comes and you have to submit whatever you have at that moment. When it’s bad, the draft you end up with isn’t much better than the first one. When it’s really bad, people push the changes so close to the deadlines that even the illusion of quality control is given up.

The death spiral is not caused by what you think

You might see symptoms like missed deadlines, writing without any planning, failure to follow your proposal process, or an unwillingness to stop making changes. But the real cause is something else. It’s actually something quite simple and easy to catch. However, fixing it is a bit more challenging.

The cause of the death spiral occurs before writing even starts. And once you’re sucked in, it’s almost impossible to escape. Even if you do escape, the proposal will be damaged goods. There is a line that if you cross it, your chances of winning drop and can never fully recover.

There are two things going on at the start of a proposal. Most companies try to do them at the same time and that is what gets them into trouble. If what you offer is customized, complex, tailored, or a unique solution to the customer’s problem, then designing your offering and writing the proposal at the same time is what causes the death spiral.

Don't engineer your solution or offering by writing about it

It’s natural, once you have the RFP in hand, to think “Now we have to write the proposal,” and to write a response to each requirement in the RFP. If you do a good job, then when you are done you will have something that is compliant with the RFP. You may be expecting the proposal reviewers to want to add some marketing-speak to “make it sell better.” But you may not realize that you have another problem. Bad engineering, defects in your solution, and an offering that is at best ordinary.

It can’t be fixed one requirement at a time or by adding some happy-words on top. That’s like fixing a machine by replacing one random part at a time. The reason you have defective engineering is because you had no engineering methodology beyond writing and the documentation of your design consisted of preparing a narrative. If you engineered a bridge that way, it would fall.

When your reviewers read what you have and realize that’s “it’s not strong enough” they may comment on a variety of presentation issues because that is what they see. But if you fix the presentation, they still won’t be happy, and no one may know why.

The real reason they’ll never be happy is that your approach or offering is the real problem. No matter how you dress up the pig, it’s still a pig. Don’t take that personally. The problem was that by doing what you were asked to do, you ending up performing engineering by writing narratives about it.

Avoiding the death spiral is easy

Design and validate your offering before you write about it. To design your offering, you need a methodology and some way to document it. Engineering methodologies may be formal or informal, and their selection depends on what you are trying to engineer and the people involved. But think like an engineer and don’t try to think in writing.

Once you have your design, you’ll need to record it so that others can review and validate that it’s the best approach. How you document your design doesn’t matter and should avoid being burdensome. Some things may require blueprints, some may require diagrams, some may require a parts list, and some may require a work breakdown structure. If you have to collaborate with others, you should take that into account.

Once you have a documented design, then you must validate that it will meet the customer’s needs and will be better than what any competitor will offer. This validation should involve key stakeholders, independent reviewers, and The Powers That Be so that everyone is bought in.

Only then are ready to describe it in narrative form for the proposal. Once you have a validated offer design, then any changes to the narrative will be related to presentation and shouldn’t force a redesign. Any changes at that point won’t require restructuring your proposal, just how you articulate what matters about your design.

Don't let the deadline trick you into jumping right into the death spiral

Like a reality TV show, what makes waiting until you have a validated offering design a near insurmountable challenge is the deadline. Time management is harder than engineering or proposal development. You can’t spend all of the time available designing and validating your offering. You have to leave some time, probably at least half, to write and review the narrative.

But if you don't allocate enough time to offering design before you write, you'll be jumping right into the death spiral.

What makes the challenge even more difficult is that before you can jump into the engineering, you have to gather and assess requirements. You’ve got the RFP. But most RFPs are a horrible tool for understanding the customer’s requirements. They tend to be vague in key spots and sometimes contradictory in others. You may need to create a compliance matrix just to organize the requirements and work around RFP questions that go unanswered. Reading, parsing, and understanding the RFP takes time.

And RFP requirements aren’t the only requirements. You should have information about your customer, the opportunity, and the competitive environment that you have gathered outside of the RFP. They are also inputs into the design. If you don’t have input or strategies as inputs to the offering design before you start writing, you are inviting the death spiral. Having clarity about the requirements is a necessary ingredient for reliable engineering. On most proposal schedules you may only have a few days to achieve it.

All of this should reinforce that having a draft offering design before the RFP is released is the crucial for ensuring that you beat your competitors. You don’t have to write a draft of the proposal before the RFP is released, but you can help solve the time management problem if you document what you plan to offer so that when the RFP is released you only need to validate the design and describe it.

This in turn requires that you must understand the customer’s requirements before the RFP is released. At this point you should be able to see why the companies that do this have a huge advantage over those that leave themselves insufficient time to design a winning offering before they start writing and thus expose themselves to the death spiral.

Whatever you do, don't cross this line

The line that you don’t want to cross is writing the proposal before you can articulate a valid offering design. Once the offering design is entangled with the narrative, both changes and validation become much more difficult, risky, and time consuming. Because it weakens your ability to consistently focus on what matters in your proposal, any changes to the offering design once it has been turned into a narrative lower you chances of winning. Even if you escape the death spiral, you can’t escape that figuring out what to offer by writing about it produces a proposal that is not fully optimized to win.