When does having 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 effectively implemented. And this is where 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 or how to balance the inevitable trade-offs.

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. Most often people hedge and speak in terms of "phases" to imply sequence while making up the details as they go.

The proposal process is not sequential. A big part of it is reactionary, requiring you to adapt to what's in the next RFP, which is usually different in important ways from what was in the last RFP. The way the RFP reads can change the sequence of your process, the applicability of any step, or some or all of the details in your process. 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, which, is typically what we see. Every company says it has a proposal process, when in reality they kind of have a way of doing things and sometimes parts of it are even written down and once in a while things play out the way they are supposed to. This creates a constant struggle as people try to reconcile when to ignore the process and when to follow it. It sets the precedent that the process is subject to interpretation.

The clearest sign that you have too much proposal process or the wrong proposal process is when it is not achieving your goals. But you have to be honest about that. Clinging to your process because working without any process would be a disaster is not the same as having the best proposal process. Having a process does not mean you are doing everything you should to maximize your win rate.

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 flowchart 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 to make it easier for people to achieve their goals during the process.

This flips the script. People do not serve the process. The process serves the goals that people have.

Just keep in mind that it’s not the forms and templates that are the process. They are just tools to achieve goals. Also keep in mind that you are not creating a set of forms and templates that are required to be filled out in accordance with procedures.  Instead, you are creating tools that help people achieve their goals.

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. That is assembly line thinking and actually gets in the way of the continuous problem solving that proposal development really is.

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 next goal be to start writing or to create a content plan that enables us to determine what the proposal should be? Is it to get something written so people can review it, or is it to create a set of criteria that can be used for quality validation and for writers to follow? How you write your goals will determine whether you get the desired results. Well-written goals are also more resilient than steps and procedures. Large proposals, small proposals, and even proposals for different markets all tend to have similar goals. RFPs tend to change the content, but not the goals.

When you start explaining your proposal goals 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 and call it a "hybrid?"

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 old habits 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 having a flowcharting app. 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.