Can this 5-layered approach to proposal development transform how you manage your proposals?

Writing a proposal requires transforming the information you have to enable the customer to make a decision in your favor. The larger and more complex the proposal, the more people that will be involved. Throw in a tight, unforgiving deadline and you’ve got a complicated undertaking that involves getting people to understand how the transformation will take place, being capable of making the transformation, doing it by the deadline, and doing it so well the outcome is successful.

When herding cats and going from proposal to proposal, it's easy to forget the big picture. It's easy to slip into being a traffic cop instead of a guide. It's easy to start focusing on deadline enforcement instead of winning. It's easy to lower the bar by throwing re-use at it instead of raising the bar. Sometimes it's a good idea to take a step back and think about what you need to accomplish instead of how to turn the proposal process into a mechanistic, assembly line driven production effort.

Here are six proposal management process considerations to help you focus on what's important:

1. Are you trying to manage people to assemble a proposal or lead them to the win? A good place to start is to determine what your role really is. What kind of proposal manager do you want to be? Are you simply trying to crank out submissions as quick as they throw them at you, or are you trying to change the company and everyone in it to turn it into a winning organization full of constantly increasing opportunity? That can be impossible to do if the organization has a culture that works against it, so it's a legitimate choice.
2. Getting the information needed to do the job. Proposals will starve without the right input. But what is needed changes over the proposal lifecycle. Try creating forms, checklists, and other information products to collect the information that proposal writers will need to write a great proposal.
3. Information products that assist in the transformation. Within each activity, information products can gather input, provide guidance, help achieve quality assurance, and prepare for the next activity. The proposal that gets submitted is the ultimate information product you produce, but it is not the only one. Proposal writing doesn't take place in one step. You can help people think through what the proposal should be and get it right on the first draft. You just have to guide them through it, by showing them what to consider and then turning it into a plan or blueprint for the proposal.
4. An approach to issue management that is sufficient for the complexity of your environment. Proposals can be seen as an exercise in problem solving. Typical problems include, but are in no way limited to, tasking assignments, tracking progress toward meeting the deadline, answering questions that people have, filling gaps in the offering, interpreting the RFP, etc. Each issue must be discovered, tracked, and resolved. And the nature of those issues also changes with each stage in the proposal lifecycle. Successful proposal management is not simply a matter of issuing assignments. Issue management is required to mitigate the risks that can cause proposal failure. Where this often goes wrong is that people start with a simple list of items they cross off as they go. This breaks down if you also need to track who is assigned each issue, who they need helping them, whether there will be follow-up, what inputs they need to resolve it, deadlines, severity, impact, etc. It helps to be able to sort, filter, track aging, etc.
5. Implementing the right processes, tools, and techniques required to create and validate the information products you create. This is the area that gets the most attention. But process design, tool selection, and technique development really depend on the nature of your proposals. What you need to track issues on a proposal with dozens of people involved is different from a proposal with three people involved. The same is true between a proposal with a table of contents that fits on one page, and a table of contents that requires five pages. The problem with most tools is that they don’t meet the needs of proposals because they don’t map to the outline and cover the needs across the proposal lifecycle, or they aren’t useable by the entire team. The problem with most processes is that they aren’t self-explanatory to the people doing most of the work and they aren’t consistently followed because the RFPs are all different. Techniques are usually a personal matter, leading to the illusion that winning proposals requires a hero instead of a routine.
6. Implementing proposal quality validation. In each stage of the proposal lifecycle, what do you need to ensure everything is valid or was done correctly before you move on? How will you instead of steps. Structuring your process around accomplishing goals instead of steps can enable people to flexibly figure out what needs to be done. Instructions provide guidance that steps do not. Every part of your process should address:
   1. What information do you need to accomplish the next goal?
   2. What will you do with the information? 
   3. How will you store, transform, and present the information to make accomplishing the next goal easier?
   4. How will you track everything to completion?
   5. How will you define your proposal quality criteria and use them to validate the information products you create?

   For the goals, input requirements, products, and issue tracking requirements across five stages in the proposal lifecycle. You can quickly build a proposal development operation off just this table alone, if you have to. But you can also use it to identify your gaps, set priorities, and mature your existing process.