How to implement a proposal process that survives in the real world

Most proposal process "best practices" fail in the real world. In the real world, some companies are centralized and some are decentralized. Some companies are authoritarian and some are consensus driven. In some companies the pre-RFP pursuit and the post-RFP pursuit are organized under the same leadership and in some they are not. Successfully implementing a proposal process requires understanding which practices are a match for your company.

So how do you design a proposal process to survive in the real world?

In some companies, the pre-RFP pursuit process is handled by different staff with different leadership than the post-RFP proposal process. This makes it hard for one to define the process followed by the other, and really difficult to integrate the two. This is a major impediment to companies being able to start their proposals before the RFP is released.

When we designed the pre-RFP phase of our process, we designed it to show companies how to prepare for RFP release. However, if in the real world you can’t get the people who track the pursuit before RFP release to follow the process, it also works as a proposal readiness gap analysis tool at RFP release. You can use it to assess where you should be and where you actually are in terms of being ready to win the proposal. Sometimes after you go through that a time or two and people see that if they are not prepared it will show, and the proposal process shows them what to do to be prepared, you may be able to gain some cooperation. The process not only survives adversity, it mitigates the adversity and encourages improvement over time.

The vital importance of degrading gracefully

When a process adds value (or simply works without breaking) even though it is not properly executed, an engineer might call it “degrading gracefully.”

That’s a concept that we also built into our process for planning the content of the proposal. Sometimes the people working on a proposal have no say when they are called in to start working on the proposal. They may not have time for niceties like “planning.” So we organized our planning into iterations and put them in priority order. If you do all the iterations, you reap tremendous benefits. But if you only do the bare minimum, you still add value. The proposal content planning process shows you how to get the most out of the time you have available.

The key to degrading is whether the process bends or breaks under pressure. Most proposal process implementations break. They simply don't address adverse circumstances. When the best practices don't apply, they offer nothing. This does not reflect the real world of proposals. The proposal process should continue, perhaps in a smaller, more limited form, instead of breaking. Proposal processes should be designed for the least number of resources and requirements to function, instead of being designed around optimal resources or requirements.

Does your process scale?

Being designed around the least number of resources and requirements shouldn't mean that the process doesn't also work well when you have an abundance of resources and all requirements are met. The difference between them is really scale and not scope. It's not what you do, it's how you manage when there is a lot more to coordinate.

The things you need to do to write a winning proposal remain remarkably consistent, even though the way you do them can change radically. The process goals for writing a winning proposal when it's a small proposal, written by a single person, on a tight five-day schedule are quite similar to the goals for writing a winning proposal when it's a huge proposal, written by a large team of people and multiple contractors who have 60 days to prepare the proposal. Is your proposal process scalable, so that it guides every size and shape of the proposals you face, even though the things they do to achieve the process goals are completely different? Can your process adapt to changes in size, formality, participants, subject matter, etc.? 

Lack of time is a common theme in the deadline-driven proposal world. It’s a major reason why instead of true quality assurance, most proposals are lucky to get a single review. One consequence is that they expect that review to do everything and in many cases it ends up adding less value than if the time had been spent working on the proposal instead of waiting for review feedback.

In the real world, all proposals are not the same. A proposal on a seven-day schedule is different from one on a 30-day schedule. A proposal worth a billion dollars merits more attention than a proposal worth a million dollars. When we designed our proposal quality validation process, we focused on what needed to be reviewed instead of how to do the review. This way you can group many things together into a single review, or have several detailed and specialized reviews, depending on the schedule and importance of your proposal. But in both cases, everything that needs to be reviewed gets reviewed.

Different companies have different pain points. Their problems might be related to the pre-RFP phase, the startup of the proposal effort, quality assurance, figuring out what to say, developing effective win strategies, getting people to work together as a team, or any number of other difficulties. Most companies have at least part of the proposal process in place and working acceptably well.

If a proposal process has limited scalability or if it can’t degrade gracefully, then it is liable to fail under pressure. The circumstances that impact proposal development can vary widely. This is a nice way of saying that you have to be prepared for anything. And having a proposal process that can survive the messiness of the real world is a good place to start.