When does too much proposal process hurt your proposals?

A sound proposal process not only increases efficiency and improves win rates, it is also one of the few things that can give people working on a proposal hope that the next proposal won't be so bad. Proposal specialists make everything about the process. And that's a good thing.

But you have to get the process implemented. And this is where most proposal specialists struggle. It's also where non-proposal specialists struggle, because they too often recognize the need for a proposal process, but usually have even less insight on where to start implementing one.

Most people have the wrong instincts when it comes to putting a proposal process in place. This is true of proposal specialists and non-specialists alike. If you try to identify step one and work sequentially from there, you're already in trouble. If you try to identify all the steps between the start and the end, you're on the path to failure.

The proposal process is not sequential. It more closely resembles object-oriented programming. It's a collection of event-based routines that get called as needed, possibly in parallel, and with an uncertain number of iterations. And all proposal procedures must adapt to the circumstances of the bid. One unusual statement in the RFP can break a proposal procedure.

And yet, people often try to flowchart the proposal process.

If you attempt to build a procedural proposal process that can be depicted by a flowchart, it will break in practice. It creates a process that can't actually be followed as written and requires someone to modify it on the fly. In reality, it degrades into people making it up as they go along. It provides a way of doing things instead of a process. It teaches people that the process doesn’t need to be followed with any precision. This is what most companies have, and it creates a constant struggle.

This is a big reason why we created the MustWin Process that is part of PropLIBRARY. We were tired of processes that couldn’t survive reality. So we created one that works in the real world, and isn’t based on procedures or flowcharts.

What people should have instead of a flow chart is a set of goals. And each goal should have a scope definition and a set of criteria that define success for that goal. Take away the technical sounding jargon and the proposal process becomes a collection of goals with a description and checklist for each. Just to be helpful, you might create resources and job aids for each goal as well. This is more jargon for adding some forms and templates. 

Just keep in mind that it’s not the forms and templates that are the process. They are just tools. And keep in mind that you are not creating a set of forms and templates that are required to be filled out. 

The process is defined by the goal and the success criteria checklist. The materials you have to help people achieve the goal are assets and not mandates. You have to resist the temptation to define the process as procedures and work products. 

The most important part is to have the right goals. The goals you choose will determine the behavior of the participants. Here's an example: Should the goal be to create a content plan, or to create a set of instructions that can be used for quality validation and for writers to follow? Both parts of that describe the same deliverable. But the latter version will get the desired results while the first one will result in people cheating and saying they created a "content plan" that’s a mere shadow of what’s really needed.

When you tell this to a group of people, don't be surprised if they enthusiastically receive it and immediately start trying to create a flowchart for their goals and the activities needed to accomplish them. It's hard for them to overcome what they've been taught about processes. Their instincts push them towards policies and procedures instead of success criteria and assets to help achieve them. This doesn’t just apply to proposals. How many “Agile” software developers really follow a modified waterfall methodology?

When implementing a goal-driven proposal process, too much detail is a problem. First, it will slow down your rollout. Second, it will break. Third, when people fall back on waterfall design for the proposal process, they create a bad proposal process.

What you want is to be able to clearly  articulate your goals and success criteria. You can actually start rolling out with just that. It’s simple and easy for people to understand and accept. When people know the goals and can measure whether they've accomplished them, they can figure out what they should do to accomplish the goals. And without waiting for the forms, templates, et. al., your current proposals can benefit and your win rate can start improving. You can roll out your job aids over time as you create them.

There are three things that I really like about this approach:

1. Anyone can use it to begin implementing a proposal process. You don't have to be a proposal specialist, let alone a recognized proposal process geek like myself.
2. There is no excuse for not having a working proposal process. You can't blame not knowing how to use Visio for having an out-of-date flowchart. You can't blame not having enough time. You can't blame having an immature organization. You can have the start of a working process by the end of the day.
3. Process acceptance does not require people to agree on a bunch of steps. All you need to do is get everyone to agree on a half-dozen or so goals. Then help them achieve the goals that they agreed to. With this one change, your process shifts from a burden you are assigning to others and becomes an asset that helps people.

Once you have your goals and checklists, you're not done. You're only getting started. Eventually you will need to think through the flow of information and create job aids that gather information, assess it, and transform it into what is needed to accomplish each goal. But you can discover what that should be and how to create each form or template over time. You can evolve your process. A process that evolves is much better than a process that breaks.