When people working on proposals encounter a problem, they often try to improve their process to resolve the issue. When issues persist, they often blame them on failure to adopt the process. Many organizations struggle for process acceptance and reach a plateau where they can't improve the process because they can't completely implement it. They never realize that the process was flawed from the beginning and is the cause of their problems, not the cure.
Instead of incremental improvements to their process, they really need to start over. Instead of holding on to the process as they initially conceived it, they should re-invent the process to address the organizational realities required for it to succeed.
If many of the items below apply to your organization, it may be time to re-invent your proposal process:
- The process calls for storyboards but you never actually do them
- Days after the process has started, you still don't have enough people assigned to actually do the proposal
- When you need to have a second review because the first one didn't go well, you invent a new color to name it with
- The process consists of a kickoff meeting and a red team
- The capture manager finds out about the process at the kickoff meeting
- Staff cannot execute the process without training
- Staff have to be persuaded to follow the process
- Executives don't bother to follow the process
- People involved in the process do not understand what is expected of them
- People involved in the process are not capable of performing what is expected of them
- When you're doing a proposal by yourself, you don't bother to follow the process
- You don't use the process for "small" proposals
- The outline changes after writing has started
- You regularly have unanticipated change cycles
- You can't get people to stop making changes to the proposal
- The process starts at RFP release, or worse, it starts some days after RFP release when someone gets around to telling you about it
- You are the only one aware of the process
- The process doesn't measure progress
- The process doesn't define what a quality proposal is
- The process doesn't measure quality
- You have trouble preparing the documents required by the process
- The process adds to the time it takes to complete the proposal
- Reviews are not effective
- You don't find out about problems until deadlines are missed
- The process requires investing "up front" for an intangible return "later"
- The process is not documented
- The process is defined as you go along
- The execution of the process is different from the written procedures
- You frequently find that exceptions to the process are justified
- The process is more about production than it is about winning
- By the time you're ready to start work, staff have already started writing the first draft
- People in field offices have never heard of the process
- People do not see the process as helping them complete their assignments
- The only guidance writers get is what is in the RFP
- You have a review (probably called a Red Team)
- If you have more than one review, there is no integration between them
- Reviewers get no written guidance
- Reviews do not have an assigned leader
- Reviewers are not required to add value to the proposal
- You decide how comments should be collected when you get to the review
- The reviewers are the same as the writers
- The process requires everyone to be physically present/co-located
- You have post-proposal lessons learned meetings, but never formally change the process as a result
- You finish the proposal and you're not really sure what's in it
- You're adding themes and win strategies at the end of the effort
- Conflicts revolve around edits instead of message
- Proposals are regularly delivered at the last possible minute
- You routinely have a mad crunch at the end with rapid last minute changes displacing your final quality assurance checks
- You find yourself saying "if people would only follow the process, all these problems would go away" multiple times a day
- The pricing proposal is almost never done early enough to check and make sure that it actually agreed with what you promised in the technical approach
If these apply to you, then you need to ask yourself if your current process is serving everybody's needs. Chances are that it is not and that you would be more successful by designing a process around an assessment of everyone's needs instead of the conventional wisdom regarding how proposals "are supposed" to be done.
Fulfilling your needs for planning, coordination, expectation management, resource allocation, quality validation, etc. are far more important than how you go about it. If your current process is not fulfilling those needs, stop beating your head against a wall and start over with a fresh approach.