Improving the Proposal Process
If you do a lot of proposals, you can benefit from formalizing your proposal process and studying best practices. A well organized and planned proposal process can eliminate much of the chaos and last minute panic that so often haunts proposal development. Well thought-out proposal procedures will also help you coordinate efforts and help you win more proposals.
5 Keys To A Successful Proposal Process Implementation Having a process defined and documented is only the start. Most companies struggle to get their process implemented. Here are some tips that can help you survive the experience.
Make it easier to follow the process than it is to do the proposal without it. With or without a process, it's not easy to do a proposal. A well designed process, by eliminating the need to reinvent the wheel, will expedite things and make it easier to follow the process than to improvise. A more complex process, requiring more effort and training to follow it, reduces the advantage to the user, increases the perception that the process requires work over and above what is required to do the proposal, and increases resistance to the process. If you find yourself asking people to invest in following the process for an intangible future benefit, your process is too difficult. The process should show people how to do the things they will have to do anyway, and make it easier than coming up with their own solutions.
Prime the pump. Whenever possible, customize process templates and fill-in forms in advance. This lowers the effort to execute the process. Every time someone faces a blank page, the outcome is unpredictable. It also raises the level of frustration and resistance. Set things up so that all contributors have to do is to provide content.
Build training into the process and make it constant. Training should not be a separate once a year or even once a proposal event. Thirty-six five-minute sessions delivered at the moment of need are better than one three-hour session. Each task should come with guidance built in. If you have identified what you want reviewers to validate, then you have the criteria you need to enable contributors to self-review. Think of every instruction paragraph, checklist, or process document as a training tool. Build it into the process so that they don't have to go looking for it. Surround the participants with guidance.
Set expectations. Communicate clear roles and responsibilities at every step to ensure that participants know what they are getting into. No one should ever stop work or feel frustration as a result of not knowing what is expected of them. Process cooperation and acceptance starts with a clear dialog regarding expectations. The process should provide opportunities to raise issues with expectations early and frequently to anticipate and mitigate potential problems.
Ensure participants are capable of fulfilling their assignments. Even if the process defines roles and responsibilities, communicates expectations, and provides guidance, it will fail if participants are not capable of fulfilling their assignments or not are available to fulfill them. When staff are assigned who cannot fulfill their assignments, you are doomed to failure. They need to be helped or replaced as quickly as possible. To ensure the success of your process implementation, you should anticipate that this will happen occasionally and address it during resource identification and shortly after assignment tasking.
Make it easier to follow the process than it is to do the proposal without it. With or without a process, it's not easy to do a proposal. A well designed process, by eliminating the need to reinvent the wheel, will expedite things and make it easier to follow the process than to improvise. A more complex process, requiring more effort and training to follow it, reduces the advantage to the user, increases the perception that the process requires work over and above what is required to do the proposal, and increases resistance to the process. If you find yourself asking people to invest in following the process for an intangible future benefit, your process is too difficult. The process should show people how to do the things they will have to do anyway, and make it easier than coming up with their own solutions.
Prime the pump. Whenever possible, customize process templates and fill-in forms in advance. This lowers the effort to execute the process. Every time someone faces a blank page, the outcome is unpredictable. It also raises the level of frustration and resistance. Set things up so that all contributors have to do is to provide content.
Build training into the process and make it constant. Training should not be a separate once a year or even once a proposal event. Thirty-six five-minute sessions delivered at the moment of need are better than one three-hour session. Each task should come with guidance built in. If you have identified what you want reviewers to validate, then you have the criteria you need to enable contributors to self-review. Think of every instruction paragraph, checklist, or process document as a training tool. Build it into the process so that they don't have to go looking for it. Surround the participants with guidance.
Set expectations. Communicate clear roles and responsibilities at every step to ensure that participants know what they are getting into. No one should ever stop work or feel frustration as a result of not knowing what is expected of them. Process cooperation and acceptance starts with a clear dialog regarding expectations. The process should provide opportunities to raise issues with expectations early and frequently to anticipate and mitigate potential problems.
Ensure participants are capable of fulfilling their assignments. Even if the process defines roles and responsibilities, communicates expectations, and provides guidance, it will fail if participants are not capable of fulfilling their assignments or not are available to fulfill them. When staff are assigned who cannot fulfill their assignments, you are doomed to failure. They need to be helped or replaced as quickly as possible. To ensure the success of your process implementation, you should anticipate that this will happen occasionally and address it during resource identification and shortly after assignment tasking.
50 Signs That It Is Time To Re-invent Your Proposal Process 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.
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.
A Less Painful Way to Implement Proposal Processes Formalizing your proposal process is necessary to achieve consistent quality over time. Having a proposal process can help to ensure that:
People understand their roles and responsibilities Expectations are properly set Time is used efficiently Outcomes are validated Best practices that contribute to winning are followed A fully mature process is difficult to achieve. Even if you can get all the details right, getting everybody up to speed, able, and willing to execute them can be a nearly impossible challenge. The secret is not to jump straight to a detailed process.
A proposal process can be rolled out to an organization in phases. This has a number of advantages:
Because people are not overwhelmed by the details, they are better able to understand and execute the process. Every proposal process must be adapted to the particular needs of an organization and its customers. It is not rational to expect to introduce a complex new proposal process and have it be properly optimized on its first use. It is better to plan a rollout that enables you to work towards a fully optimized process. When you introduce change, the amount of training required will be directly proportional to the amount of detail involved. Proposal processes follow the 80/20 rule. You get 80% of the benefit from 20% of the process. If you focus on putting the right foundation in place, you start getting most of the benefit right away. Your needs will change over time. Implementing a process is not a one-time event. It needs to grow and change as you do. Instead of thinking of your process implementation as a one-time event, think of it as laying a foundation and a set of procedures for continuous improvement. We like to think of it as proposal evolution.
Process Evolution
Once your foundation is in place, you will be able to build on it in phases. For your proposal process, this means start simple and add details over time. Unfortunately, most continuous improvement programs are wishful thinking that never actually produce anything. Your process will only evolve if you make specific plans to add and refine details at planned intervals. Most proposal processes stay the same until a major proposal loses. You must overcome this aspect of human nature by defining where you want to end up and put in place a schedule to implement the steps you will take to get there.
During the initial implementation, it may be sufficient to simply name the process deliverables. For example, you might require certain plans to be created. The format and contents of the process deliverables can be formalized in the future, once you are used to how things work.
Each time through the process, you should target where you want to add detail and improve. Once you are comfortable executing the process, it's time to add detail regarding what should be in each process deliverable. Continuing with the example of proposal plans, once people have adjusted to the requirement that proposals be planned, it becomes easier to implement checklists or other guidance that define what should be in those plans.
Once you have sufficient detail in your process deliverables, then you can standardize the formats. At first, you just want people to have a written plan and you don't care what it looks like. But as soon as that is working, you will want to standardize the format so there is consistency from one proposal to the next. If you handle this right, having a format to follow will make it easier for people to prepare their documents, helping you to achieve acceptance for the process.
Once the format is standardized, you should turn the process deliverables into templates. This will make it much less burdensome to create them, which should be a major goal. It is easiest to achieve compliance with a process when you make it easier to follow.
People understand their roles and responsibilities Expectations are properly set Time is used efficiently Outcomes are validated Best practices that contribute to winning are followed A fully mature process is difficult to achieve. Even if you can get all the details right, getting everybody up to speed, able, and willing to execute them can be a nearly impossible challenge. The secret is not to jump straight to a detailed process.
A proposal process can be rolled out to an organization in phases. This has a number of advantages:
Because people are not overwhelmed by the details, they are better able to understand and execute the process. Every proposal process must be adapted to the particular needs of an organization and its customers. It is not rational to expect to introduce a complex new proposal process and have it be properly optimized on its first use. It is better to plan a rollout that enables you to work towards a fully optimized process. When you introduce change, the amount of training required will be directly proportional to the amount of detail involved. Proposal processes follow the 80/20 rule. You get 80% of the benefit from 20% of the process. If you focus on putting the right foundation in place, you start getting most of the benefit right away. Your needs will change over time. Implementing a process is not a one-time event. It needs to grow and change as you do. Instead of thinking of your process implementation as a one-time event, think of it as laying a foundation and a set of procedures for continuous improvement. We like to think of it as proposal evolution.
Process Evolution
Once your foundation is in place, you will be able to build on it in phases. For your proposal process, this means start simple and add details over time. Unfortunately, most continuous improvement programs are wishful thinking that never actually produce anything. Your process will only evolve if you make specific plans to add and refine details at planned intervals. Most proposal processes stay the same until a major proposal loses. You must overcome this aspect of human nature by defining where you want to end up and put in place a schedule to implement the steps you will take to get there.
During the initial implementation, it may be sufficient to simply name the process deliverables. For example, you might require certain plans to be created. The format and contents of the process deliverables can be formalized in the future, once you are used to how things work.
Each time through the process, you should target where you want to add detail and improve. Once you are comfortable executing the process, it's time to add detail regarding what should be in each process deliverable. Continuing with the example of proposal plans, once people have adjusted to the requirement that proposals be planned, it becomes easier to implement checklists or other guidance that define what should be in those plans.
Once you have sufficient detail in your process deliverables, then you can standardize the formats. At first, you just want people to have a written plan and you don't care what it looks like. But as soon as that is working, you will want to standardize the format so there is consistency from one proposal to the next. If you handle this right, having a format to follow will make it easier for people to prepare their documents, helping you to achieve acceptance for the process.
Once the format is standardized, you should turn the process deliverables into templates. This will make it much less burdensome to create them, which should be a major goal. It is easiest to achieve compliance with a process when you make it easier to follow.
The 7 Principles That Should Guide Your Proposal Process Your proposal process needs to achieve certain goals. You can use these principles to assess your proposal process. After all, if you don't know your goals, it's difficult to achieve them.
Proposal Process Goals
It's all about the customer. The proposal process should result in a proposal that is built from the ground up around your customer. Each proposal should directly address your customer's wants, needs, and preferences. Proposals should not over-rely on re-using pre-written content. Often, the time it takes to properly customize pre-written content takes as long, if not longer, than it would to write it properly from scratch. The proposal process must reinforce the importance of seeing things from your customer's perspective. That way, it's harder to make the mistake of delivering a proposal that simply describes your company/offering or is a collection of brochures and boilerplate stitched together. Opportunity pursuit must be planned and measured. The proposal process must provide a structure to collect the intelligence needed to win an opportunity during the critical period before the RFP is released. Without specific guidance, this critical time is likely to pass without much being achieved. Without a means to measure progress, you will have no way of knowing how far along you are towards achieving your goals during this period. If you don't know whether you are behind where you should be, you probably are behind. Conversely, if your proposal process defines the goals for intelligence gathering and provides a means to measure progress, you are far more likely to achieve those goals and start the proposal prepared with a competitive advantage. You won't get it if you don't ask for it. The proposal process should guide participants at every step. In particular, the process should focus on providing detailed instructions for proposal authors to ensure that everything necessary for a quality proposal makes it into the document. At a higher level, the proposal process should provide a structure to ensure that expectations are properly set before, during, and after every activity. If you don't tell people what you need and how to deliver it, you are far less likely to actually get it. Good proposal managers may do this instinctively, but it will be more reliable if you build guidance and expectation management directly into your process. Proposal quality must be defined and validated. The proposal process should identify what is required for a proposal to be successful and validate every aspect of the proposal to ensure that those requirements are met. A "Red Team" without direction to reviewers regarding what to validate just won't cut it. Your proposal process should incorporate making a list of what needs to be validated to ensure success, and then provide some means to perform the validation of each and every item. If you don't define what needs to be validated to ensure success, you cannot consciously arrive at a proposal that includes everything necessarily to be successful. If it's necessary to the success of the proposal, it's worth the effort to validate it. Plans must be validated. Results should be validated against the plans.Plans should be used to establish a baseline to measure performance against. Assessing results against the plan brings continuity, accountability, and objectivity to the review process. Doing this makes the validation of your plans as important, if not more so, than the validation of the draft proposal. Not doing this increases the likelihood of people ignoring the plans during the execution of the process. In which case, why bother with the plans? Or better yet, why bother with the process? Organizations that have trouble implementing a proposal process are often caught in this trap. If the process validates the results against the plans, then you will improve the quality of the plans as well as the results. Effort should go into the document, and not into the process. The proposal process should make extensive use of templates and checklists. It should be highly streamlined and efficient. Data accumulated during the process should be stored in formats that make it easy to carry forward. Content plans should evolve into the proposal and not be separate documents. Whenever someone has to put something on paper or type something into their computer, the process should be doing something to make it easier. The resources assigned to a proposal demonstrate your company's desire to win. While profitability may be achieved by stretching your resources, doing so on a proposal lowers your chances of winning. If the company wants to win, it will staff the proposal with a sufficient number of experienced and capable staff. Period. This needs to be recognized, since at all levels of the company it will be claimed that resources are not available. But the truth is that the company will make resources available in proportion to its desire to win the bid, as compared to its desire to fulfill conflicting priorities. The shorter and easier way to say this is that if the company wants to win, it makes the necessary resources available. Failure to assign those reasons is prima facie evidence that winning is not the dominant priority.
Proposal Process Goals
It's all about the customer. The proposal process should result in a proposal that is built from the ground up around your customer. Each proposal should directly address your customer's wants, needs, and preferences. Proposals should not over-rely on re-using pre-written content. Often, the time it takes to properly customize pre-written content takes as long, if not longer, than it would to write it properly from scratch. The proposal process must reinforce the importance of seeing things from your customer's perspective. That way, it's harder to make the mistake of delivering a proposal that simply describes your company/offering or is a collection of brochures and boilerplate stitched together. Opportunity pursuit must be planned and measured. The proposal process must provide a structure to collect the intelligence needed to win an opportunity during the critical period before the RFP is released. Without specific guidance, this critical time is likely to pass without much being achieved. Without a means to measure progress, you will have no way of knowing how far along you are towards achieving your goals during this period. If you don't know whether you are behind where you should be, you probably are behind. Conversely, if your proposal process defines the goals for intelligence gathering and provides a means to measure progress, you are far more likely to achieve those goals and start the proposal prepared with a competitive advantage. You won't get it if you don't ask for it. The proposal process should guide participants at every step. In particular, the process should focus on providing detailed instructions for proposal authors to ensure that everything necessary for a quality proposal makes it into the document. At a higher level, the proposal process should provide a structure to ensure that expectations are properly set before, during, and after every activity. If you don't tell people what you need and how to deliver it, you are far less likely to actually get it. Good proposal managers may do this instinctively, but it will be more reliable if you build guidance and expectation management directly into your process. Proposal quality must be defined and validated. The proposal process should identify what is required for a proposal to be successful and validate every aspect of the proposal to ensure that those requirements are met. A "Red Team" without direction to reviewers regarding what to validate just won't cut it. Your proposal process should incorporate making a list of what needs to be validated to ensure success, and then provide some means to perform the validation of each and every item. If you don't define what needs to be validated to ensure success, you cannot consciously arrive at a proposal that includes everything necessarily to be successful. If it's necessary to the success of the proposal, it's worth the effort to validate it. Plans must be validated. Results should be validated against the plans.Plans should be used to establish a baseline to measure performance against. Assessing results against the plan brings continuity, accountability, and objectivity to the review process. Doing this makes the validation of your plans as important, if not more so, than the validation of the draft proposal. Not doing this increases the likelihood of people ignoring the plans during the execution of the process. In which case, why bother with the plans? Or better yet, why bother with the process? Organizations that have trouble implementing a proposal process are often caught in this trap. If the process validates the results against the plans, then you will improve the quality of the plans as well as the results. Effort should go into the document, and not into the process. The proposal process should make extensive use of templates and checklists. It should be highly streamlined and efficient. Data accumulated during the process should be stored in formats that make it easy to carry forward. Content plans should evolve into the proposal and not be separate documents. Whenever someone has to put something on paper or type something into their computer, the process should be doing something to make it easier. The resources assigned to a proposal demonstrate your company's desire to win. While profitability may be achieved by stretching your resources, doing so on a proposal lowers your chances of winning. If the company wants to win, it will staff the proposal with a sufficient number of experienced and capable staff. Period. This needs to be recognized, since at all levels of the company it will be claimed that resources are not available. But the truth is that the company will make resources available in proportion to its desire to win the bid, as compared to its desire to fulfill conflicting priorities. The shorter and easier way to say this is that if the company wants to win, it makes the necessary resources available. Failure to assign those reasons is prima facie evidence that winning is not the dominant priority.
Do You Have a Proposal Process, Or Just Think You Do? If you ask a proposal specialist whether they have a process, they will almost always answer "yes." It would be embarrassing to do otherwise. Yet, if you examine how things actually get done, you'll find most of them are not actually following a process.
A process is more than a series of milestones. Having a kickoff meeting and a red team for every proposal does not mean you have a process. Having a bid/no-bid review does not mean you have a business development process. Generating reports does not mean that you have a business development process.
If it is not implemented and being used, you do not have a process. A document sitting on the shelf that is not followed is not a process.
A process followed by only one person that is not documented is called a habit. It might be a good habit, but it is not a process.
If it is documented, but you are the only one following it, or the only one who knows how to follow it, you do not have a process. What you have is your own way of doing things. Your way of doing things might be effective, but it is not a process.
If it is not documented, it is not a process. And even if you think it is, you can't prove it. Your process should not only be documented to demonstrate its existence, but it should also generate evidence of its completion. Otherwise, how do you know it is being followed.
If you can execute your process without using the process documentation, you don't have a process. And if you do, it's not adding any value. For a process to add value, it must do more for you than what you can do on your own.
Keep in mind that having a process does not mean you are doing things in the most effective way. Having standards to measure success can be more valuable than the process used to get there. Even if you do have a process, you should be able to explain why you need one. Addressing those needs may be more important than having a documented process. For example, among other things, you need to manage expectations, track progress, validate results, provide quality assurance, prevent issues, mitigate risks, and implement best practices. If you are achieving these things, you are probably working effectively, with or without process. Process will help make it consistent and verifiable, but you might be able to live without that if you are getting results. If you have a process and are not achieving these things through it, you might want to re-invent your process.
This gets us to, "what should your process do?" Your process should guide your actions and make sure you don't forget anything. It should be documented in such a way that it enables you to prepare deliverables more quickly than you could without it. It should be something that is useful and followed during execution so that it doesn't grow stale sitting on a shelf. It should enable everyone to understand their role and what will be expected of them. It should provide feedback mechanisms that help avoid defects and missed deadlines before they occur. It should embrace continuous change, because otherwise "continuous improvement" never actually occurs.
Having good work practices and having a process are not the same thing. Unfortunately, having a good process does not necessarily mean that you have good work practices. And having good work practices does not mean that you have a good process (or any process at all). So if you think you should have a process, make sure that you one you have is real. And above all else, make sure that you can explain why you need it.
A process is more than a series of milestones. Having a kickoff meeting and a red team for every proposal does not mean you have a process. Having a bid/no-bid review does not mean you have a business development process. Generating reports does not mean that you have a business development process.
If it is not implemented and being used, you do not have a process. A document sitting on the shelf that is not followed is not a process.
A process followed by only one person that is not documented is called a habit. It might be a good habit, but it is not a process.
If it is documented, but you are the only one following it, or the only one who knows how to follow it, you do not have a process. What you have is your own way of doing things. Your way of doing things might be effective, but it is not a process.
If it is not documented, it is not a process. And even if you think it is, you can't prove it. Your process should not only be documented to demonstrate its existence, but it should also generate evidence of its completion. Otherwise, how do you know it is being followed.
If you can execute your process without using the process documentation, you don't have a process. And if you do, it's not adding any value. For a process to add value, it must do more for you than what you can do on your own.
Keep in mind that having a process does not mean you are doing things in the most effective way. Having standards to measure success can be more valuable than the process used to get there. Even if you do have a process, you should be able to explain why you need one. Addressing those needs may be more important than having a documented process. For example, among other things, you need to manage expectations, track progress, validate results, provide quality assurance, prevent issues, mitigate risks, and implement best practices. If you are achieving these things, you are probably working effectively, with or without process. Process will help make it consistent and verifiable, but you might be able to live without that if you are getting results. If you have a process and are not achieving these things through it, you might want to re-invent your process.
This gets us to, "what should your process do?" Your process should guide your actions and make sure you don't forget anything. It should be documented in such a way that it enables you to prepare deliverables more quickly than you could without it. It should be something that is useful and followed during execution so that it doesn't grow stale sitting on a shelf. It should enable everyone to understand their role and what will be expected of them. It should provide feedback mechanisms that help avoid defects and missed deadlines before they occur. It should embrace continuous change, because otherwise "continuous improvement" never actually occurs.
Having good work practices and having a process are not the same thing. Unfortunately, having a good process does not necessarily mean that you have good work practices. And having good work practices does not mean that you have a good process (or any process at all). So if you think you should have a process, make sure that you one you have is real. And above all else, make sure that you can explain why you need it.
Surviving Quick Turnaround Proposals Most RFPs give you a few weeks to respond; 30 days is pretty typical. However, task orders, commercial RFPs, and various circumstances may leave you with only a week or even less to prepare a proposal. Formal proposals processes require a certain amount of time to execute. Some people think that quick turnaround proposals are simply a matter of following the same proposal process, only doing things faster. Some people are also wrong. You might make incremental improvements by speeding up a traditional process, but you can't take a process built for a 30-day schedule and make it into a 5-day schedule just by doing things a little faster.
The way to make a change that radical is to take your process and identify the goals at every step. Then keep the goals, but throw away the process. It usually doesn't matter how you do it, so long as you achieve the goals.
The goal is not simply to submit a proposal:
The goal of a kickoff meeting might be coordination and facilitation The goal of proposal planning is efficiency and accuracy The goal of a formal review is validation The proposal process must produce a document that is compliant with the RFP, accurate, competitive, well-presented, with winning bid strategies, and do it under deadline pressure.
There are ways to achieve these goals that make sense when you have 30 days. Some of them do not make sense when you only have 5 days. However, you can still achieve the goals of compliance, accuracy, competitiveness, presentation, and winning bid strategies, you just have to do things differently.
One of the key practices of proposal management is to "plan before you write and write to the plan." But what is the goal? It's not to create a separate document called a "plan." The goal is to get the proposal right the first time --- to avoid endless re-writing cycles to get the document where it should be. On quick turnaround proposals, it may be necessary for writing to start immediately --- for those sections that map easily to the RFP and you know what should go into them. For others, writing can begin as soon as you decide what should go into them. You don't want to start writing before you've validated the approaches and win strategies. But you also don't want a lowest common denominator solution that has the entire document waiting for a review of the plan. You may be able to write to approaches and win strategies as soon as you've held discussions and reached decisions. Your goal should be to work in a methodical manner, being able to trace what is written back to your requirements and win strategies --- you may just lack the luxury of time to hold everybody up while you put it in writing.
Traditional proposal processes also put a lot of emphasis on formal reviews or Red Teams. The way most Red Teams are implemented, work comes to a halt as a fully formatted draft is produced, distributed, read, and then a sit-down meeting scheduled. A Red Team can easily eat two days of your schedule.
But what are the goals of the red team?
To validate that the proposal is fully compliant with the RFP To validate that the proposed approaches are the correct approaches to bid To ensure that all corporate qualifications are included To validate that the bid strategies are correct and well presented To ensure the best score according to the evaluation criteria To identify any possible means to improve the proposal You may be able to achieve these goals with procedures that take much less time.
During any draft cycle, you might pick someone to verify compliance and report only on compliance problems. Or you might arrange for an engineer-type to validate the proposed approaches. You can validate the bid strategies through discussion and then all you have to do is make sure the messages come across in writing. You might still choose to do a formal review, but now you need less people and are less subject to major structural changes resulting from the review. If you get the review down to just a couple of people, it is far easier to schedule without disrupting the whole effort. You might be able to eliminate the sit-around-a-table and talk disruption completely.
Here is a hypothetical example of a proposal that demonstrates quick turnaround techniques as opposed to best practices.
Day One. You receive a task order RFP that is a likely bid. So you start work on it. You can always stop if some decides not to bid later. You know who the project manager will be, but you're not sure how staff will be allocated.
You find you can write to the high level task management approach, you just can't write to how staff will be organized until that gets decided. Because the RFP specifies labor categories, you have sufficient descriptions of staffing to draft a roles and responsibilities write-up. As soon as you know whether you will use incumbent, existing, or recruited staff, you can also complete the staffing approach.
Day Two. You schedule a meeting with the proposed Project Manager to discuss the organization and staffing issues. The meeting ends with a hand drawn org chart that shows you which staff will go where.
Because the Statement of Work is well organized, you can approach it as a point-by-point response. Once the first draft is complete, it will be easy to establish compliance, and you can highlight any keywords that are missing.
Day Three. You schedule another meeting with the Project Manager to discuss approaches to doing the work as well as win strategies and the features/benefits of your approaches. These you turn into a two page executive summary that lists your corporate qualifications and describes why the client should select you. You take this summary to the executive sponsor of the bid to validate the win strategies.
You schedule a review for the following day with the executive sponsor and a senior business developer who knows the customer participating. RFP compliance and your approaches have all been validated, but you still want the quality assurance, advice from experienced staff, and buy-in of key stakeholders. You pass out a review copy that is not in its final format, and put it into production in parallel with the review.
Day Four. You get feedback from your reviews. Most of it is resolved by tweaking the presentation of your message in the Executive Summary. You also add some project references and flow-down the changes to the Executive Summary to a couple of applicable sections. The most difficult issue involves changes to how some of the staff are allocated. Some of the comments are already obsolete due to editing in final production. You mark-up the formatted draft from production with your final changes and send it back.
Day Five. You get the final document back from production. You give it a final look over for quality assurance and give a copy to the project manager and executive sponsor for final approval. You get it back and with a couple of minor changes submit the proposal.
The way to make a change that radical is to take your process and identify the goals at every step. Then keep the goals, but throw away the process. It usually doesn't matter how you do it, so long as you achieve the goals.
The goal is not simply to submit a proposal:
The goal of a kickoff meeting might be coordination and facilitation The goal of proposal planning is efficiency and accuracy The goal of a formal review is validation The proposal process must produce a document that is compliant with the RFP, accurate, competitive, well-presented, with winning bid strategies, and do it under deadline pressure.
There are ways to achieve these goals that make sense when you have 30 days. Some of them do not make sense when you only have 5 days. However, you can still achieve the goals of compliance, accuracy, competitiveness, presentation, and winning bid strategies, you just have to do things differently.
One of the key practices of proposal management is to "plan before you write and write to the plan." But what is the goal? It's not to create a separate document called a "plan." The goal is to get the proposal right the first time --- to avoid endless re-writing cycles to get the document where it should be. On quick turnaround proposals, it may be necessary for writing to start immediately --- for those sections that map easily to the RFP and you know what should go into them. For others, writing can begin as soon as you decide what should go into them. You don't want to start writing before you've validated the approaches and win strategies. But you also don't want a lowest common denominator solution that has the entire document waiting for a review of the plan. You may be able to write to approaches and win strategies as soon as you've held discussions and reached decisions. Your goal should be to work in a methodical manner, being able to trace what is written back to your requirements and win strategies --- you may just lack the luxury of time to hold everybody up while you put it in writing.
Traditional proposal processes also put a lot of emphasis on formal reviews or Red Teams. The way most Red Teams are implemented, work comes to a halt as a fully formatted draft is produced, distributed, read, and then a sit-down meeting scheduled. A Red Team can easily eat two days of your schedule.
But what are the goals of the red team?
To validate that the proposal is fully compliant with the RFP To validate that the proposed approaches are the correct approaches to bid To ensure that all corporate qualifications are included To validate that the bid strategies are correct and well presented To ensure the best score according to the evaluation criteria To identify any possible means to improve the proposal You may be able to achieve these goals with procedures that take much less time.
During any draft cycle, you might pick someone to verify compliance and report only on compliance problems. Or you might arrange for an engineer-type to validate the proposed approaches. You can validate the bid strategies through discussion and then all you have to do is make sure the messages come across in writing. You might still choose to do a formal review, but now you need less people and are less subject to major structural changes resulting from the review. If you get the review down to just a couple of people, it is far easier to schedule without disrupting the whole effort. You might be able to eliminate the sit-around-a-table and talk disruption completely.
Here is a hypothetical example of a proposal that demonstrates quick turnaround techniques as opposed to best practices.
Day One. You receive a task order RFP that is a likely bid. So you start work on it. You can always stop if some decides not to bid later. You know who the project manager will be, but you're not sure how staff will be allocated.
You find you can write to the high level task management approach, you just can't write to how staff will be organized until that gets decided. Because the RFP specifies labor categories, you have sufficient descriptions of staffing to draft a roles and responsibilities write-up. As soon as you know whether you will use incumbent, existing, or recruited staff, you can also complete the staffing approach.
Day Two. You schedule a meeting with the proposed Project Manager to discuss the organization and staffing issues. The meeting ends with a hand drawn org chart that shows you which staff will go where.
Because the Statement of Work is well organized, you can approach it as a point-by-point response. Once the first draft is complete, it will be easy to establish compliance, and you can highlight any keywords that are missing.
Day Three. You schedule another meeting with the Project Manager to discuss approaches to doing the work as well as win strategies and the features/benefits of your approaches. These you turn into a two page executive summary that lists your corporate qualifications and describes why the client should select you. You take this summary to the executive sponsor of the bid to validate the win strategies.
You schedule a review for the following day with the executive sponsor and a senior business developer who knows the customer participating. RFP compliance and your approaches have all been validated, but you still want the quality assurance, advice from experienced staff, and buy-in of key stakeholders. You pass out a review copy that is not in its final format, and put it into production in parallel with the review.
Day Four. You get feedback from your reviews. Most of it is resolved by tweaking the presentation of your message in the Executive Summary. You also add some project references and flow-down the changes to the Executive Summary to a couple of applicable sections. The most difficult issue involves changes to how some of the staff are allocated. Some of the comments are already obsolete due to editing in final production. You mark-up the formatted draft from production with your final changes and send it back.
Day Five. You get the final document back from production. You give it a final look over for quality assurance and give a copy to the project manager and executive sponsor for final approval. You get it back and with a couple of minor changes submit the proposal.
11 Questions Your Proposal Process Should Answer People tend to look at their business development and proposal process as a series of steps. Another way to look at it is whether the process answers questions that people have so that they can complete the task. Rather than asking yourself whether your process accounts for all the activity that will occur, instead ask yourself whether your process answers the most important questions. Here is a list:
What do you need to do to be ready to bid? Most bids are lost before they even start. Even people who know that often start unprepared. The reason is that the process doesn't tell them exactly what they should do before the bid actually starts.
How should you go about planning? You need to plan your proposal, but what constitutes an acceptable proposal plan? Who should do what? It takes more than an assignment list for people to know what to do. It takes more than a roles and responsibilities table at the beginning of the process. At all times it should be clear what tasks need to be done and who is responsible for doing them. How will expectations be set? Most of the problems that proposals get into can be avoided if expectations are properly set. What guidance should people get in performing tasks? It's not enough to assign a task. You have to make sure people are capable of fulfilling it. A big part of this is making sure they understand what is required to fulfill the task. Since most of the people working on proposals are not specialists, they often need guidance. A little bit of ad hoc training or a manual is not sufficient. If you want them to be successful, you must make sure they get the guidance they need. If you want to make sure that happens, it must be built into the process. How do you measure and track progress? Feedback to the proposal team is critical in order to know when what you are doing is successful and when it is not. How do you know if things are on track? You need a way to measure progress. And if you want things to stay that way, you need a way to track your progress. How do you estimate and track resources? How many people do you need to prepare the proposal? Where will the work locations be? What equipment and access requirements do you have? Most people just guess at their resources requirements. A major cause of proposal failure is insufficient resources. If you want a systemic approach to solving that problem you must build resource estimation and tracking into your process. What are the deliverables and how should they be prepared? A proposal process requires a number of deliverables such as planning documents, review comments, forms, templates, and checklists. To prevent people from inventing these as they go along, your process should define the deliverables, including content and format. Are people getting what they need, when they need it, and is it in the right format? People have needs. Some of these include food, lodging, recognition, feedback, and information. Does your process address what people need in order to perform their tasks and be successful? With regards to information, you may need to address the format that information is stored in to ensure that it is accessible at the moment of need. What criteria should be used in reviews? If you want reviews to be conducted effectively, you must specify the criteria to be used in performing the review. In order to ensure that reviews have criteria that are specific to the opportunity, the process must address the definition of the criteria and their use. How do you validate that things were done correctly? People often issue assignments and then are surprised when things don't get done correctly. To avoid this, you need to build validation into your process. All work needs to be checked to make sure that it was done correctly. Instead of building your process around one or more milestone reviews, you may need to build it around your need to validate work as it is performed instead. How do you know if you've created the right proposal? If you can't define something, you can't measure it. If you can't measure it, you don't know when it is complete. If you can't define what the right proposal is in terms that are measurable and can be validated, you won't know whether the proposal you have written is the right proposal. "I'll know it when I see it" is not a reliable approach. Your proposal must begin and end with how you define the right proposal.
What do you need to do to be ready to bid? Most bids are lost before they even start. Even people who know that often start unprepared. The reason is that the process doesn't tell them exactly what they should do before the bid actually starts.
How should you go about planning? You need to plan your proposal, but what constitutes an acceptable proposal plan? Who should do what? It takes more than an assignment list for people to know what to do. It takes more than a roles and responsibilities table at the beginning of the process. At all times it should be clear what tasks need to be done and who is responsible for doing them. How will expectations be set? Most of the problems that proposals get into can be avoided if expectations are properly set. What guidance should people get in performing tasks? It's not enough to assign a task. You have to make sure people are capable of fulfilling it. A big part of this is making sure they understand what is required to fulfill the task. Since most of the people working on proposals are not specialists, they often need guidance. A little bit of ad hoc training or a manual is not sufficient. If you want them to be successful, you must make sure they get the guidance they need. If you want to make sure that happens, it must be built into the process. How do you measure and track progress? Feedback to the proposal team is critical in order to know when what you are doing is successful and when it is not. How do you know if things are on track? You need a way to measure progress. And if you want things to stay that way, you need a way to track your progress. How do you estimate and track resources? How many people do you need to prepare the proposal? Where will the work locations be? What equipment and access requirements do you have? Most people just guess at their resources requirements. A major cause of proposal failure is insufficient resources. If you want a systemic approach to solving that problem you must build resource estimation and tracking into your process. What are the deliverables and how should they be prepared? A proposal process requires a number of deliverables such as planning documents, review comments, forms, templates, and checklists. To prevent people from inventing these as they go along, your process should define the deliverables, including content and format. Are people getting what they need, when they need it, and is it in the right format? People have needs. Some of these include food, lodging, recognition, feedback, and information. Does your process address what people need in order to perform their tasks and be successful? With regards to information, you may need to address the format that information is stored in to ensure that it is accessible at the moment of need. What criteria should be used in reviews? If you want reviews to be conducted effectively, you must specify the criteria to be used in performing the review. In order to ensure that reviews have criteria that are specific to the opportunity, the process must address the definition of the criteria and their use. How do you validate that things were done correctly? People often issue assignments and then are surprised when things don't get done correctly. To avoid this, you need to build validation into your process. All work needs to be checked to make sure that it was done correctly. Instead of building your process around one or more milestone reviews, you may need to build it around your need to validate work as it is performed instead. How do you know if you've created the right proposal? If you can't define something, you can't measure it. If you can't measure it, you don't know when it is complete. If you can't define what the right proposal is in terms that are measurable and can be validated, you won't know whether the proposal you have written is the right proposal. "I'll know it when I see it" is not a reliable approach. Your proposal must begin and end with how you define the right proposal.
Past performance record keeping In the past, project references were static summaries that were often kept as a collection of re-use files. With the advent of past performance evaluations, this way of keeping project information may no longer meet all of your needs.
A collection of static files may not provide what you need to know about a project to get the best possible past performance evaluation. For a successful past performance evaluation you need a current contact at the customer that will speak well of your performance. If nobody answers when the evaluator calls, you will get a neutral rating (5 out of 10) and that can ruin your overall score. If the person that answers does not know you, or worse, speaks poorly of you, your score will be even worse.
With a collection of static files, the only way you have to anticipate your past performance evaluation is the input of the project manager. It runs against human nature to advertise your mistakes and poor performance. Also, people have limited, biased, and sometimes selective memories. A better source for project performance information is the status reports that almost every project manager is tasked to provide.
A past performance record keeping system links the static project summary with these reports to provide a project history. This history can be reviewed prior to submitting a proposal that includes the project to identify weaknesses that should be proactively responded to in your proposal.
A past performance record keeping system takes a much larger level of effort to set up than a static project summary system. A record keeping system also presumes access to the records, which may require changes to internal project management procedures — something that may be beyond the reach of a proposal manager and will usually require executive level decisions. With past performance counting for as much as 50% of your evaluation score, there is significant reason to consider taking on the larger effort.
A collection of static files may not provide what you need to know about a project to get the best possible past performance evaluation. For a successful past performance evaluation you need a current contact at the customer that will speak well of your performance. If nobody answers when the evaluator calls, you will get a neutral rating (5 out of 10) and that can ruin your overall score. If the person that answers does not know you, or worse, speaks poorly of you, your score will be even worse.
With a collection of static files, the only way you have to anticipate your past performance evaluation is the input of the project manager. It runs against human nature to advertise your mistakes and poor performance. Also, people have limited, biased, and sometimes selective memories. A better source for project performance information is the status reports that almost every project manager is tasked to provide.
A past performance record keeping system links the static project summary with these reports to provide a project history. This history can be reviewed prior to submitting a proposal that includes the project to identify weaknesses that should be proactively responded to in your proposal.
A past performance record keeping system takes a much larger level of effort to set up than a static project summary system. A record keeping system also presumes access to the records, which may require changes to internal project management procedures — something that may be beyond the reach of a proposal manager and will usually require executive level decisions. With past performance counting for as much as 50% of your evaluation score, there is significant reason to consider taking on the larger effort.
What To Expect When You Are Assigned The Role Of Business Developer Some companies have dedicated Business Developers, and others leave the task to their project managers. Regardless of your background, if you are assigned the role of Business Developer, then your job is not only to find potential bid opportunities, but also to gather intelligence about the customer, the opportunity, and the competition that will be crucial to winning the opportunity.
Once a lead is identified, you must qualify it --- prove that it is real and that it is worth pursuing. Your company should not bid on every opportunity it stumbles across. You can help by gathering the intelligence needed to help your company decide which leads to pursue. Any intelligence you gather that indicates an opportunity is not real or worth pursuing is just as valuable as the intelligence that makes that opportunity look good.
After the lead has been initially qualified, when it is time to begin investing in its pursuit, the company should make a formal review. If the company decides to invest in the pursuit, it will assign a Capture Manager to the opportunity. The Capture Manager will be dedicated to winning the opportunity, whereas a Business Developer will typically continue to focus on identifying new leads. You will need to help get the Capture Manager up to speed on the opportunity, customer, and competitive environment. The Capture Manager will continue to need your input throughout the process.
When the proposal phase begins, the Business Developer should personally make sure that the proposal reflects what the customer wants and what you know about the competition. Your knowledge about the opportunity, customer, and competitive environment goes well beyond what is in the RFP and is vital --- no one can do the job in your place. Business Developers rarely take a writing role in a proposal effort, but if you want to win, you need to make sure that those who do have writing assignments take into account what you know about the opportunity, the customer, and the competition. The proposal that does the best job of speaking to what the customer actually wants (regardless of what it says in the RFP) is the one that is most likely to win. Your job is to give your company that edge.
You will do most of your work before the RFP is released. Once the RFP is released, the customer may no longer be willing to talk to you, so you must anticipate the questions that people will have during the proposal process and get the answers before the proposal even starts. When the RFP is released and people ask questions that you didn't anticipate, try your best to get answers. If the company has to proceed without answers, you may be in the best position to guess what the answer should be.
Preparing the proposal will require addressing many, many tradeoffs. Your understanding of the customer's preferences should be used to help the team make the decisions the customer would prefer. You may be the only one on the team with that kind of insight. Participate in the strategy sessions and offer your insight. Then read the proposal and make sure it speaks to what the customer wants. The technical staff working on the response will have a tendency to completely focus on RFP compliance. Frequently, companies produce technically compliant proposals that don't tell a story or offer the customer any insight beyond what was supplied in the RFP. You need to coach them and give them the information they need to make sure that your story makes it into print. If it doesn't, then all of your careful positioning and work may have zero impact on whether your company wins the opportunity.
Once a lead is identified, you must qualify it --- prove that it is real and that it is worth pursuing. Your company should not bid on every opportunity it stumbles across. You can help by gathering the intelligence needed to help your company decide which leads to pursue. Any intelligence you gather that indicates an opportunity is not real or worth pursuing is just as valuable as the intelligence that makes that opportunity look good.
After the lead has been initially qualified, when it is time to begin investing in its pursuit, the company should make a formal review. If the company decides to invest in the pursuit, it will assign a Capture Manager to the opportunity. The Capture Manager will be dedicated to winning the opportunity, whereas a Business Developer will typically continue to focus on identifying new leads. You will need to help get the Capture Manager up to speed on the opportunity, customer, and competitive environment. The Capture Manager will continue to need your input throughout the process.
When the proposal phase begins, the Business Developer should personally make sure that the proposal reflects what the customer wants and what you know about the competition. Your knowledge about the opportunity, customer, and competitive environment goes well beyond what is in the RFP and is vital --- no one can do the job in your place. Business Developers rarely take a writing role in a proposal effort, but if you want to win, you need to make sure that those who do have writing assignments take into account what you know about the opportunity, the customer, and the competition. The proposal that does the best job of speaking to what the customer actually wants (regardless of what it says in the RFP) is the one that is most likely to win. Your job is to give your company that edge.
You will do most of your work before the RFP is released. Once the RFP is released, the customer may no longer be willing to talk to you, so you must anticipate the questions that people will have during the proposal process and get the answers before the proposal even starts. When the RFP is released and people ask questions that you didn't anticipate, try your best to get answers. If the company has to proceed without answers, you may be in the best position to guess what the answer should be.
Preparing the proposal will require addressing many, many tradeoffs. Your understanding of the customer's preferences should be used to help the team make the decisions the customer would prefer. You may be the only one on the team with that kind of insight. Participate in the strategy sessions and offer your insight. Then read the proposal and make sure it speaks to what the customer wants. The technical staff working on the response will have a tendency to completely focus on RFP compliance. Frequently, companies produce technically compliant proposals that don't tell a story or offer the customer any insight beyond what was supplied in the RFP. You need to coach them and give them the information they need to make sure that your story makes it into print. If it doesn't, then all of your careful positioning and work may have zero impact on whether your company wins the opportunity.
What To Expect When You Are Assigned The Role Of Capture Manager Congratulations! You have the most challenging job in business development. It is also the most important. You must sell not only to the customer, but internally as well. You must know about the customer, the opportunity, the scope of work, project management, budgeting, pricing, contracting, proposal writing, and how to obtain, allocate, and steal resources within your company. You do not have to be the top expert in every one of these areas, but you should be proficient in all of them. And all of your eggs are in one basket, being dedicated to the pursuit of one opportunity. And if you aren't dedicated, then you're being pulled in too many directions and can't give every opportunity the attention it needs.
You will take over a lead that has been identified and initially qualified. You should immediately qualify it yourself, and continue to do so every day. Is it real and is it worth investing in its pursuit? Sometimes the best thing you can do for your company is to terminate a pursuit rather than to invest further in it. The sooner you kill an opportunity that is not worth pursuing, the easier and better it is for the company.
When you are asked to be the Capture Manager for an opportunity you should not say "yes" until you have considered everything above. Do not play unless you have a better than even chance of winning.
Initially, you will work in partnership with the Business Developer who identified the lead. When the RFP is released, you will work in partnership with the Proposal Manager who will lead the effort to develop the proposal document. Throughout the pursuit you will be responsible for making sure that the right intelligence is collected so that you can make informed strategic and tactical decisions. This does not mean you will collect it yourself --- it means you must lead the effort and ensure that you get what you need. You will be responsible for obtaining the resources to complete the proposal and for deciding what to propose. The Proposal Manager will assist you by defining and administering the proposal process. But the process will only be successful if your company brings the right information and resources into it.
To obtain the resources you need to capture the opportunity, you will need to take advantage of everything you know about your organization and the people who work there. Leverage your network. This is where you will be required to apply your ability to persuade internally --- you will need to convince people that your opportunity is worth the effort in order to get the right people assigned.
The most important thing you will do is make decisions:
What should your strategies be? What should your approaches be? What should your pricing be? Be decisive. Many teams go wrong by taking too long to make key decisions or worse by waffling. Lead the team to make decisions, validate that they are correct, and then stick to them. If nothing else, you can help by taking the fall if the decisions are wrong. Since your chances of being wrong are about the same whether you waffle or not, you might as well be decisive so your team can make the most of the strategies and approaches you select. The good news is that for most Capture Managers, if you make enough decisions correctly and win the opportunity, you'll probably get to keep your job.
You will take over a lead that has been identified and initially qualified. You should immediately qualify it yourself, and continue to do so every day. Is it real and is it worth investing in its pursuit? Sometimes the best thing you can do for your company is to terminate a pursuit rather than to invest further in it. The sooner you kill an opportunity that is not worth pursuing, the easier and better it is for the company.
When you are asked to be the Capture Manager for an opportunity you should not say "yes" until you have considered everything above. Do not play unless you have a better than even chance of winning.
Initially, you will work in partnership with the Business Developer who identified the lead. When the RFP is released, you will work in partnership with the Proposal Manager who will lead the effort to develop the proposal document. Throughout the pursuit you will be responsible for making sure that the right intelligence is collected so that you can make informed strategic and tactical decisions. This does not mean you will collect it yourself --- it means you must lead the effort and ensure that you get what you need. You will be responsible for obtaining the resources to complete the proposal and for deciding what to propose. The Proposal Manager will assist you by defining and administering the proposal process. But the process will only be successful if your company brings the right information and resources into it.
To obtain the resources you need to capture the opportunity, you will need to take advantage of everything you know about your organization and the people who work there. Leverage your network. This is where you will be required to apply your ability to persuade internally --- you will need to convince people that your opportunity is worth the effort in order to get the right people assigned.
The most important thing you will do is make decisions:
What should your strategies be? What should your approaches be? What should your pricing be? Be decisive. Many teams go wrong by taking too long to make key decisions or worse by waffling. Lead the team to make decisions, validate that they are correct, and then stick to them. If nothing else, you can help by taking the fall if the decisions are wrong. Since your chances of being wrong are about the same whether you waffle or not, you might as well be decisive so your team can make the most of the strategies and approaches you select. The good news is that for most Capture Managers, if you make enough decisions correctly and win the opportunity, you'll probably get to keep your job.
Proposal Process vs. Checklists Flow charts for business development and proposal processes are useless. Those of you with an engineering background may be tempted to say that "it's not a process unless you can diagram it." But our experience shows that the flow chart for any BD process fails within minutes of meeting the real world. They may be useful as a concept, but little more. A formal process requires a finite, defined scope. You need clear begin and end points for each phase of activity. You need to be able to define the process deliverables. Instead of a sequential set of steps, business development is more like a collection of sub-routines. And while it is at least theoretically possible to diagram it, you may get better results if you focus on process deliverables.
In business development there is this thing that confounds any well defined process. This thing is often referred to as the Customer. The Customer is not required to follow your process. The Customer can:
Issue an RFP (or not) Use a nearly unlimited variety of contract vehicles or methods Change the RFP or the process in midstream Change their mind at any time. And they do. Sometimes it's good to be the customer ;-)
In addition to the Customer to contend with, most companies have separately managed groups for business development, proposal development, and project execution. A process that originates in one group may not be followed by those in another.
It may be possible to craft a process diagram with sufficient decision points and options to cover all of the possible contingencies. But often the process does not get executed in sequential steps. There is a lot of backtracking and iteration that is difficult to impossible to anticipate. In developing a process that adds value to participants you can put many hours into flow charting. Or you could just skip the charts.
Consider the following list of documents for supporting proposal development:
Proposal Manager's Workbook Pre-RFP Progress Checklist Draft RFP Checklist RFP RFP Release Checklist RFP Distribution List Kickoff Meeting Checklist Kickoff Agenda Kickoff Attendees Author Instructions Author Self-Review Checklist Status Log Graphics Log Staffing Worksheet Project Worksheet Cross Reference Matrix Outline Assignments Schedule Annotated Outline Review Plan Production Plan Review Team Instructions Review Team Comment Form Production Checklist Submission Readiness Checklist Submission Checklist Post Submission Checklist If you give one proposal team a well thought out process, fully diagramed, with a detailed process manual to back it up, and you give another proposal team a set of templates and checklists like those shown above, which do you think would execute better? The team with the templates and checklists will execute better because the get their process guidance from the same tools that they use to execute the process.
Once you have worked through all of the plans, checklists, tools, and deliverables used in business development and proposal writing, then you are much better prepared to diagram the process. The next time you are starting a proposal process definition effort, instead of starting off by drawing a flow chart, instead consider starting by creating a set of templates and checklists.
In business development there is this thing that confounds any well defined process. This thing is often referred to as the Customer. The Customer is not required to follow your process. The Customer can:
Issue an RFP (or not) Use a nearly unlimited variety of contract vehicles or methods Change the RFP or the process in midstream Change their mind at any time. And they do. Sometimes it's good to be the customer ;-)
In addition to the Customer to contend with, most companies have separately managed groups for business development, proposal development, and project execution. A process that originates in one group may not be followed by those in another.
It may be possible to craft a process diagram with sufficient decision points and options to cover all of the possible contingencies. But often the process does not get executed in sequential steps. There is a lot of backtracking and iteration that is difficult to impossible to anticipate. In developing a process that adds value to participants you can put many hours into flow charting. Or you could just skip the charts.
Consider the following list of documents for supporting proposal development:
Proposal Manager's Workbook Pre-RFP Progress Checklist Draft RFP Checklist RFP RFP Release Checklist RFP Distribution List Kickoff Meeting Checklist Kickoff Agenda Kickoff Attendees Author Instructions Author Self-Review Checklist Status Log Graphics Log Staffing Worksheet Project Worksheet Cross Reference Matrix Outline Assignments Schedule Annotated Outline Review Plan Production Plan Review Team Instructions Review Team Comment Form Production Checklist Submission Readiness Checklist Submission Checklist Post Submission Checklist If you give one proposal team a well thought out process, fully diagramed, with a detailed process manual to back it up, and you give another proposal team a set of templates and checklists like those shown above, which do you think would execute better? The team with the templates and checklists will execute better because the get their process guidance from the same tools that they use to execute the process.
Once you have worked through all of the plans, checklists, tools, and deliverables used in business development and proposal writing, then you are much better prepared to diagram the process. The next time you are starting a proposal process definition effort, instead of starting off by drawing a flow chart, instead consider starting by creating a set of templates and checklists.
Proposal planning If there is one universal rule for proposals it would have to be plan before you write and write to the plan.
Your proposal should have specific goals and should answer specific customer requirements according to explicit evaluation criteria (whether provided by the customer or assumed). Your outline, themes, and text should all correspond. In most proposals this will only be possible if you plan the proposal’s contents prior to writing.
For each item in your proposal outline, you should plan which customer requirements it will address, which evaluation criteria, which themes, points of emphasis, bid strategies, what projects/experience it will cite, and what graphics/illustrations will be included.
Some proposal specialists use a process of storyboarding to accomplish this. With storyboards, you build the high-level proposal outline and then complete a storyboard for each one. The storyboard contains headings for items such as those listed above. Authors complete the storyboards to provide the information that needs to be presented in a section and complete the low-level outline. The storyboard acts as a data collection tool when working with multiple authors.
Some proposal specialists use annotated outlines, with the proposal outline, RFP, and other items listed above cross-referenced. Annotated outlines can also be used as a data-collection tool.
Regardless of whether you use storyboards, annotated outlines, or some other methodology, you should document your proposal plan in such as way that you can validate it prior to writing. For validation, you may wish to conduct a formal proposal plan review, with subject matter experts and management involved. Once validated, the plan becomes a blue print. In some cases, the plan can be turned into a checklist. This has the advantage of providing guidance to authors and an objective baseline to use during later draft reviews. In any event you want the authors to know what is expected of them to pass the later draft reviews so that they can get it right the first time.
Your proposal should have specific goals and should answer specific customer requirements according to explicit evaluation criteria (whether provided by the customer or assumed). Your outline, themes, and text should all correspond. In most proposals this will only be possible if you plan the proposal’s contents prior to writing.
For each item in your proposal outline, you should plan which customer requirements it will address, which evaluation criteria, which themes, points of emphasis, bid strategies, what projects/experience it will cite, and what graphics/illustrations will be included.
Some proposal specialists use a process of storyboarding to accomplish this. With storyboards, you build the high-level proposal outline and then complete a storyboard for each one. The storyboard contains headings for items such as those listed above. Authors complete the storyboards to provide the information that needs to be presented in a section and complete the low-level outline. The storyboard acts as a data collection tool when working with multiple authors.
Some proposal specialists use annotated outlines, with the proposal outline, RFP, and other items listed above cross-referenced. Annotated outlines can also be used as a data-collection tool.
Regardless of whether you use storyboards, annotated outlines, or some other methodology, you should document your proposal plan in such as way that you can validate it prior to writing. For validation, you may wish to conduct a formal proposal plan review, with subject matter experts and management involved. Once validated, the plan becomes a blue print. In some cases, the plan can be turned into a checklist. This has the advantage of providing guidance to authors and an objective baseline to use during later draft reviews. In any event you want the authors to know what is expected of them to pass the later draft reviews so that they can get it right the first time.
Getting People to Follow Your Proposal Process The story of how one company overcame the struggle for acceptance of their proposal process
In a past life I was helping a company create a new proposal department. The company was more than 20 years old and had gone from being a small business to being part of one of the largest government contractors. They had a history of business units not accepting process guidance from the proposal group. It’s not an uncommon problem. Does it sound familiar?
The old proposal group kept saying things like “if they’d only submit their drafts on time” or “if they’d only listen to us.” They didn’t realize that they were just creating a control drama that they were always going to lose. Their response was to try to fight harder for control. It didn’t work. Though it took years, they ended up losing their jobs over it because they came to be seen as uncooperative instead of being a value-added.
I was asked to create a replacement for the old proposal group. They basically wanted to start over. There was so much negative history, that people had lost perspective. I looked at it as an expectation management problem. The business units had the wrong expectations for what it takes to win a proposal, and the proposal group had the wrong expectations for their role as a value-added support function.
The first thing I addressed was what the business units could expect from the proposal group. This is different from what the proposal group expects from the business units. As I made notes, the list grew beyond what I could fit on a sheet of paper. It was important to me to keep it to one page since I knew I would be swimming upstream to get their attention. So I turned it into a poster. I could present it during meetings and I could post it in the proposal department.
As I presented it, the message evolved. It became, “what you can expect and rely on from us — if you follow the process.” We offered them a choice. The proposal group could give them their best efforts and follow the process informally the way they had always done, or they could follow the process formally in which case everyone would know exactly what they would be getting at every step. The key was that it was that the business units that got to choose.
What I learned from studying peoples’ reactions to this approach is that executive managers desperately want to know what to expect. They’re used to managing projects where deadlines and budgets slip all the time, and even though promises are made with honest intentions, you should pad the numbers because you know that’s how it always goes. When you can communicate clear choices — if you want this, here is how to get it — and then don’t try to force them, they no longer react as if in a confrontation or a power struggle.
Taking this approach requires that you organize and document your process differently from the way most people have theirs. Instead of creating a flow chart of activity or a data flow diagram, the process needs to show expectations and fulfillment.
This experience was very helpful when we sat down to write the CapturePlanning.com MustWin Process. Every activity that it defines addresses who has the lead responsibility and what needs to be accomplished. When you look at it as a whole, it becomes easy to say “If we do it this way, you know what you are going to get.” In fact, the process itself starts with review and acceptance by the Executive Sponsor of the pursuit.
By giving them a chance to opt out you really don’t stand to lose much. If they opt out, it just means doing things the same way you are doing now. Only you have explicitly told them that all they can count on is your best efforts. But when they opt in, then they have chosen to follow the process formally and you start the proposal with half of the battle for process acceptance already won. And while that doesn’t guarantee they won’t change their minds, it’s a set-up that would please most Proposal Managers.
In a past life I was helping a company create a new proposal department. The company was more than 20 years old and had gone from being a small business to being part of one of the largest government contractors. They had a history of business units not accepting process guidance from the proposal group. It’s not an uncommon problem. Does it sound familiar?
The old proposal group kept saying things like “if they’d only submit their drafts on time” or “if they’d only listen to us.” They didn’t realize that they were just creating a control drama that they were always going to lose. Their response was to try to fight harder for control. It didn’t work. Though it took years, they ended up losing their jobs over it because they came to be seen as uncooperative instead of being a value-added.
I was asked to create a replacement for the old proposal group. They basically wanted to start over. There was so much negative history, that people had lost perspective. I looked at it as an expectation management problem. The business units had the wrong expectations for what it takes to win a proposal, and the proposal group had the wrong expectations for their role as a value-added support function.
The first thing I addressed was what the business units could expect from the proposal group. This is different from what the proposal group expects from the business units. As I made notes, the list grew beyond what I could fit on a sheet of paper. It was important to me to keep it to one page since I knew I would be swimming upstream to get their attention. So I turned it into a poster. I could present it during meetings and I could post it in the proposal department.
As I presented it, the message evolved. It became, “what you can expect and rely on from us — if you follow the process.” We offered them a choice. The proposal group could give them their best efforts and follow the process informally the way they had always done, or they could follow the process formally in which case everyone would know exactly what they would be getting at every step. The key was that it was that the business units that got to choose.
What I learned from studying peoples’ reactions to this approach is that executive managers desperately want to know what to expect. They’re used to managing projects where deadlines and budgets slip all the time, and even though promises are made with honest intentions, you should pad the numbers because you know that’s how it always goes. When you can communicate clear choices — if you want this, here is how to get it — and then don’t try to force them, they no longer react as if in a confrontation or a power struggle.
Taking this approach requires that you organize and document your process differently from the way most people have theirs. Instead of creating a flow chart of activity or a data flow diagram, the process needs to show expectations and fulfillment.
This experience was very helpful when we sat down to write the CapturePlanning.com MustWin Process. Every activity that it defines addresses who has the lead responsibility and what needs to be accomplished. When you look at it as a whole, it becomes easy to say “If we do it this way, you know what you are going to get.” In fact, the process itself starts with review and acceptance by the Executive Sponsor of the pursuit.
By giving them a chance to opt out you really don’t stand to lose much. If they opt out, it just means doing things the same way you are doing now. Only you have explicitly told them that all they can count on is your best efforts. But when they opt in, then they have chosen to follow the process formally and you start the proposal with half of the battle for process acceptance already won. And while that doesn’t guarantee they won’t change their minds, it’s a set-up that would please most Proposal Managers.
10 Reasons Why People Should Follow The Process If you want them to opt-in, you need to be able to articulate what's in it for them
Giving people a chance to opt out of your process is actually a powerful tool for getting people to accept your process. When you combine it with giving people a reason to opt into your process, you have a powerful presentation that tells people they can choose either a formal process that will provide them with the benefits below but require a certain amount of discipline, or they can forgo the process in which case they will still get your best efforts. Given the choice, they almost always go for what will give them the best chances of winning.
If you choose to implement our formal process for pursuing this opportunity, you will get the following:
Improved chances of winning. All of the goals, action items, and quality validation criteria in our process are based on being able to articulate what it will take to win. This is achieved by collecting intelligence that answers specific questions, and turning it into action items and criteria that can be used to assess the proposal. Our process structures the flow of information so that the entire proposal is built around what it will take to win and measures quality against it. Formal expectation management. You will know exactly what to expect at all times. In fact, everyone will know what is expected of them at all times. Your staff will know exactly what needs to be accomplished and will be able to refer to our process documentation when in doubt. Everyone will be on the same page. Literately. Roles and responsibilities, plans, action items, progress reviews, and quality validation procedures are fully documented in ways that can be followed during execution. Roles and responsibilities are not only defined at the top level, but are also addressed at the task level. Help allocating resources. Instead of forcing your hand, our process is designed to facilitate decision making. You decide how to invest your resources. You make the tough decisions whether to minimize staffing or invest in the win. The process shows people what needs to be accomplished. The number of resources assigned determines how much they have to stretch in order to achieve them. Once assigned, the process will help get the most out of your resources through its streamlined workflow, efficient expectation management, and quality validation. Opportunities for oversight. You can expect a series of readiness reviews prior to RFP release that will enable you to measure the progress towards being ready at RFP release. You will have multiple opportunities to see the direction the team is going and correct it if needed. Review goals, scheduling, and criteria are all documented. After RFP release, you will have a chance to review documented proposal plans prior to their implementation, use them to measure progress, and use them as specification to compare output against. Clear accountability. A by-product of well managed expectations is that participants are much more accountable for fulfilling them. When expectations are not fulfilled, it is caught quickly so that you can determine whether additional guidance, more resources, or different resources are required. By formally defining quality criteria and measuring progress, we also make proposal assessments far more objective. Avoidance of most problems and quick resolution of those that do occur. If your team falls behind, you will know it right away, and both you and the team will know exactly what needs to be done to get caught up. Every decision, assignment, and aspect of the proposal needed to win will be validated. The process tells people what they need to do in order to be successful before they start, and then measures their progress against it. Quality assurance. When you follow our process, you will know the criteria being used to define quality and how it will be validated. You will have an opportunity to inspect the Proposal Quality Validation Plan prior to implementation to ensure that it meets your standards for quality. You will also be able to confirm that the plan is implemented as promised. An effective workflow. The process takes everything that is needed for a winning proposal and traces them to their sources. All of the steps in the process contribute to making sure that all of the things needed to deliver the right information in the right format to win the proposal flow through the process to the right people at the right time. When people go through the process the first time, they often comment on finding a reason for everything the process asked them to do earlier and are thankful at the end when they have what they need to complete the proposal. Get the proposal off to the right start. By focusing on being ready at RFP release, the process stages everything needed for a quick start the moment the RFP hits the street. If you start the process late, the process itself tells you what should have been done so you can attempt to make up for lost time. Metrics and measurements. Our process for ensuring RFP readiness, proposal planning, and proposal quality validation is specifically designed to enable progress to be measured. By applying the process and tracking these measurements over a number of bids, they can be correlated with your win rate to determine exactly what drives your ability to win and what holds it back. We have written these reasons based on what we know is in our process documentation. You can follow a similar approach using your own. If your process isn’t fully documented, you may not be able to use this approach. Our process documentation is available for purchase and immediate implementation to enable you to get there quickly.
Giving people a chance to opt out of your process is actually a powerful tool for getting people to accept your process. When you combine it with giving people a reason to opt into your process, you have a powerful presentation that tells people they can choose either a formal process that will provide them with the benefits below but require a certain amount of discipline, or they can forgo the process in which case they will still get your best efforts. Given the choice, they almost always go for what will give them the best chances of winning.
If you choose to implement our formal process for pursuing this opportunity, you will get the following:
Improved chances of winning. All of the goals, action items, and quality validation criteria in our process are based on being able to articulate what it will take to win. This is achieved by collecting intelligence that answers specific questions, and turning it into action items and criteria that can be used to assess the proposal. Our process structures the flow of information so that the entire proposal is built around what it will take to win and measures quality against it. Formal expectation management. You will know exactly what to expect at all times. In fact, everyone will know what is expected of them at all times. Your staff will know exactly what needs to be accomplished and will be able to refer to our process documentation when in doubt. Everyone will be on the same page. Literately. Roles and responsibilities, plans, action items, progress reviews, and quality validation procedures are fully documented in ways that can be followed during execution. Roles and responsibilities are not only defined at the top level, but are also addressed at the task level. Help allocating resources. Instead of forcing your hand, our process is designed to facilitate decision making. You decide how to invest your resources. You make the tough decisions whether to minimize staffing or invest in the win. The process shows people what needs to be accomplished. The number of resources assigned determines how much they have to stretch in order to achieve them. Once assigned, the process will help get the most out of your resources through its streamlined workflow, efficient expectation management, and quality validation. Opportunities for oversight. You can expect a series of readiness reviews prior to RFP release that will enable you to measure the progress towards being ready at RFP release. You will have multiple opportunities to see the direction the team is going and correct it if needed. Review goals, scheduling, and criteria are all documented. After RFP release, you will have a chance to review documented proposal plans prior to their implementation, use them to measure progress, and use them as specification to compare output against. Clear accountability. A by-product of well managed expectations is that participants are much more accountable for fulfilling them. When expectations are not fulfilled, it is caught quickly so that you can determine whether additional guidance, more resources, or different resources are required. By formally defining quality criteria and measuring progress, we also make proposal assessments far more objective. Avoidance of most problems and quick resolution of those that do occur. If your team falls behind, you will know it right away, and both you and the team will know exactly what needs to be done to get caught up. Every decision, assignment, and aspect of the proposal needed to win will be validated. The process tells people what they need to do in order to be successful before they start, and then measures their progress against it. Quality assurance. When you follow our process, you will know the criteria being used to define quality and how it will be validated. You will have an opportunity to inspect the Proposal Quality Validation Plan prior to implementation to ensure that it meets your standards for quality. You will also be able to confirm that the plan is implemented as promised. An effective workflow. The process takes everything that is needed for a winning proposal and traces them to their sources. All of the steps in the process contribute to making sure that all of the things needed to deliver the right information in the right format to win the proposal flow through the process to the right people at the right time. When people go through the process the first time, they often comment on finding a reason for everything the process asked them to do earlier and are thankful at the end when they have what they need to complete the proposal. Get the proposal off to the right start. By focusing on being ready at RFP release, the process stages everything needed for a quick start the moment the RFP hits the street. If you start the process late, the process itself tells you what should have been done so you can attempt to make up for lost time. Metrics and measurements. Our process for ensuring RFP readiness, proposal planning, and proposal quality validation is specifically designed to enable progress to be measured. By applying the process and tracking these measurements over a number of bids, they can be correlated with your win rate to determine exactly what drives your ability to win and what holds it back. We have written these reasons based on what we know is in our process documentation. You can follow a similar approach using your own. If your process isn’t fully documented, you may not be able to use this approach. Our process documentation is available for purchase and immediate implementation to enable you to get there quickly.
A Dependable Way To Ensure Process Adoption and a Dramatic Increase In Your Win Rates I had a discussion with one of our consulting partners about an upcoming implementation of the MustWin Process at a large company with multiple divisions and well over 10,000 employees. It’s a non-trivial roll out.
The biggest problem you face in a process roll out like this is user acceptance. It’s even worse when there are multiple divisions involved that over time have developed their own ways of doing things. You’re not just asking them to do something new (new process), but to give something up (their own way of doing things).
And since it’s directly linked to the growth and success of their division, it can be really difficult to convince them to adopt a new process. Even if it’s a better way of doing things, you face user acceptance challenges, and if they're serious enough, they can lead to process implementation failure. Distribution of materials and training help reduce the barriers, but are usually not enough to win them over heart and soul.
That’s when I had an idea that will make a huge difference: metrics. We tend to treat metrics as a beneficial side effect of implementing our MustWin process, kind of like a special bonus that comes with the process. But in this case, metrics are going to be the glue that makes everything work. Metrics will be vital because they are going to become part of the reporting system used in the company.
The way our pre-RFP Readiness Reviews are set up makes it easy to quantify the review results at the individual question level as well as at the review level. We did that on purpose to make progress towards being ready for RFP release measurable. The numbers from the measurements can be formatted as a matrix and tracked using spreadsheets. They can be averaged in total giving you a single number that rates your readiness at each stage, or averaged by category (i.e., customer, opportunity, and competitive intelligence gathering) to show where you have weaknesses.
When senior managers and executives meet to review the status of pursuits, we’re going to modify the format of the reports to include the readiness metrics. Instead of just listing opportunities and subjectively describing their status, they’ll have to report their readiness metrics. In order for people to complete their reports, they'll have to have implemented the process.
This is the secret sauce. You don’t convince them to implement the process, you convince the executives of the importance of reporting metrics and then people come to you to learn the process so they can complete their reports.
In the short term, the reports will show their "readiness" to bid in a quantifiable way. In the long term, the metrics data will become an extremely useful analytical tool for bid/no bid, bid and proposal budgets, pipeline targets, and other key decisions. Only instead of having the metrics be a byproduct of the process, we're making the process a byproduct of getting the metrics they need for reporting.
Instead of scheduling training, begging people to show up, and then hoping they practice what they learn, we expect to have people coming to us to get training in order to complete their reports. And in order to complete the reports, they’ll actually have to do the reviews. In order to show decent numbers on the reviews, they’ll have to be talking to their customers, gathering intelligence, identifying competitive advantages, and positioning their company to win. Life will become so much easier for the proposal managers when people start showing up ready to win their bids. And the best part is, when the win rates go up, they’ll know exactly which efforts drove the increase because of the metrics that they tracked.
The biggest problem you face in a process roll out like this is user acceptance. It’s even worse when there are multiple divisions involved that over time have developed their own ways of doing things. You’re not just asking them to do something new (new process), but to give something up (their own way of doing things).
And since it’s directly linked to the growth and success of their division, it can be really difficult to convince them to adopt a new process. Even if it’s a better way of doing things, you face user acceptance challenges, and if they're serious enough, they can lead to process implementation failure. Distribution of materials and training help reduce the barriers, but are usually not enough to win them over heart and soul.
That’s when I had an idea that will make a huge difference: metrics. We tend to treat metrics as a beneficial side effect of implementing our MustWin process, kind of like a special bonus that comes with the process. But in this case, metrics are going to be the glue that makes everything work. Metrics will be vital because they are going to become part of the reporting system used in the company.
The way our pre-RFP Readiness Reviews are set up makes it easy to quantify the review results at the individual question level as well as at the review level. We did that on purpose to make progress towards being ready for RFP release measurable. The numbers from the measurements can be formatted as a matrix and tracked using spreadsheets. They can be averaged in total giving you a single number that rates your readiness at each stage, or averaged by category (i.e., customer, opportunity, and competitive intelligence gathering) to show where you have weaknesses.
When senior managers and executives meet to review the status of pursuits, we’re going to modify the format of the reports to include the readiness metrics. Instead of just listing opportunities and subjectively describing their status, they’ll have to report their readiness metrics. In order for people to complete their reports, they'll have to have implemented the process.
This is the secret sauce. You don’t convince them to implement the process, you convince the executives of the importance of reporting metrics and then people come to you to learn the process so they can complete their reports.
In the short term, the reports will show their "readiness" to bid in a quantifiable way. In the long term, the metrics data will become an extremely useful analytical tool for bid/no bid, bid and proposal budgets, pipeline targets, and other key decisions. Only instead of having the metrics be a byproduct of the process, we're making the process a byproduct of getting the metrics they need for reporting.
Instead of scheduling training, begging people to show up, and then hoping they practice what they learn, we expect to have people coming to us to get training in order to complete their reports. And in order to complete the reports, they’ll actually have to do the reviews. In order to show decent numbers on the reviews, they’ll have to be talking to their customers, gathering intelligence, identifying competitive advantages, and positioning their company to win. Life will become so much easier for the proposal managers when people start showing up ready to win their bids. And the best part is, when the win rates go up, they’ll know exactly which efforts drove the increase because of the metrics that they tracked.
Case Study: Preparing for Your First Proposal The Chesapeake Story
This is a continuation of a series of articles started in a previous newsletter about a company called The Chesapeake Center. I worked with them while developing the CapturePlanning.com MustWin Process, and they helped test many of the steps and forms. Their CEO, Bob Rogers, was kind enough to give me permission to write about our experience working together.
Start With A Plan
In order to prepare for the first major proposal after we started working together, we began working on the proposal planning documents. To the future Proposal Manager I was training, it seemed like a lot of paperwork. My challenge to her was to tell me which, if any, of the plans would not be needed. I believe that if there is anything in a proposal process you can get by without, then it shouldn't have been there in the first place.
This first proposal would prove to be a major eye-opener because it connected the things we did "up front" with the things we needed later. This proved to be a recurring theme for the entire proposal and one that helped them accept and understand the need for the steps in the process on their future proposals.
It's one thing to read that you should develop win strategies before the RFP is released so you can allocate them to the document, so that the proposal authors can substantiate them and you can achieve a proposal built from the ground up to achieve your win strategies and a competitive advantage. It's another thing to arrive at a draft without anything to discriminate yourself from the competition and see exactly how much better off you would have been had you followed the steps. It's even more clear when you can show them the pages in a written process book that they left blank. Having the reminder in writing also helps to ensure that they get it right the next time.
Lesson Learned: One ounce of doing a proposal is worth several pounds of process documentation if you don't have much experience. Maybe I'll create an exercise for a future proposal course that involves doing the process in reverse chronological order. Start with a finished proposal, and backtrack everything you need to get there. When they're done (and they have to be the ones doing it), they should find that information is created and staged in exactly the same places as are called for in the process.
Not Ready For RFP Release — Déjà vu!
As soon as we tried to complete the planning documents, we found that we didn't have all the information we needed. That is because the pre-RFP steps had not all been followed. This is not unusual at all. I can't remember ever working on a proposal where everyone felt they were fully prepared. In this case, the reason they didn't have all the information they needed was that while they had begun implementing the pre-RFP process, and had started using the forms, they weren't diligent about having pre-RFP Readiness Reviews. They were still learning how. Unfortunately, the result of not having the reviews was that the forms had empty fields that no one had challenged and now they didn't have the information they needed.
It is human nature when a form asks you a difficult question to skip it --- if you can get away with it. The purpose of the Readiness Reviews is to find any holes and figure out how to get them filled so that you will be prepared at RFP release.
What Do You Do Now?
One good thing about the way the process was set up is that it provides traceability. There are specific connections between what they needed after the RFP was released, and the questions on the pre-RFP forms. If you don't have something, you know exactly what it is, where it should have come from, and who should have provided it.
Lesson Learned: Hold Readiness Reviews, make sure all of the questions are answered, and verify that forms are completely filled out. This provides much clearer direction than the more typical "be better prepared for the next RFP."
It also put us in the position of knowing exactly what we needed to research and accomplish. Instead of having to develop a plan from scratch to deal with being unprepared, we had specific action items from the written process sitting in front of us. Because of this, when we had our meeting to validate the proposal plans it was more like a training exercise. Instead of focusing on describing the deficiencies and what to do about them, we focused on the links between pre-RFP and post-RFP success.
Building The Right Foundation
Another thing that became apparent was how much of the plans were re-useable. For example, the schedule page became a template that just needed new dates for the next proposal. The first effort in a new process is always the hardest. Creating the plans for future proposals would be much quicker. The best way to achieve having a written proposal plan for every proposal is to make it quick and easy to do so. The process we followed was designed to deliver the information needed so that it could be cut and pasted onto a template proposal plan in minutes instead of hours. Once they went through one, they saw that it was possible to complete it quickly if they had all the information. This is something they probably didn't believe before (although they were nice enough not to say it out loud). But the best part is that they saw the consequences of trying to do a proposal without having properly followed the pre-RFP steps and how much harder it makes things.
Because future plans would be easier to prepare and the pre-RFP information more complete (due to the Readiness Reviews), it would also be possible to do a better job on the Content Plan. Of all the proposal plans, the Content Plan is the one that I most closely link with success. The more complete it is, the more you know what you are doing and can validate the drafts. On Chesapeake's first proposal, the Content Plan consisted of little more than headings taken from a compliance matrix and placeholders. Many of the themes and win strategies that should have been developed pre-RFP were either missing or did not match up well when allocated to the outline.
Déjà vu All Over Again
When the Content Plan was handed off to the technical staff, it was largely ignored. They did what they had traditionally done and started from their own re-use files. Luckily our schedule called for early draft "check-ins" well ahead of final draft reviews. We had time to re-direct the authors. Sometimes re-directing authors to do something other than what they are used to can be difficult (like pulling teeth). In this case, we were able to clearly show that what was being produced was not RFP compliant. We also took the step of re-allocating what the authors had written to the Content Plan/outline and marked the wholes that needed to be completed. This made it easier for the authors and helped ensure that they understood what was expected.
Because we had created a Content Plan, even if it was a basic one, we had placeholders for themes. The contributors were still struggling with understanding how to write themes. It didn't help that they did business in a commodity market with evaluations based largely on price. They tended to skip the themes.
However, the placeholders in the Content Plan made it easier to approach the themes through a process of elimination. They also made it easier to develop themes that fit the structure of the proposal and to see how the themes added up to the overall win strategies. While the process called for developing win strategies during the pre-RFP period, it's hard to do this when you can't see how they impact the document. Going through the process of linking a list of win strategies to a Content Plan, and then writing to substantiate them and ending up with a document that is built around the win strategies, was really helpful.
Validating The Proposal
Once the writing had sufficiently progressed, we began implementing the Validation Plan. The first thing we discovered was compliance problems. There were many keywords from the RFP missing in the response. They had not checked compliance as thoroughly as the Validation Plan called for. We went down a long list of validation items. Going through the list helped them to better understand what is required to develop a winning proposal.
Lesson learned: Even though the process calls for verifying the Validation Plan at the beginning of the proposal and the items to be validated should be incorporated into the Content Plan, it might also be a good idea to go over the Validation Plan with the writers before they start to help ensure that expectations are clear. This way it is all spelled out for them.
Making changes after the reviews was straightforward --- fix specific validation items and then reevaluate them. It was a process of elimination and they managed to execute it without backtracking or second guessing areas that had passed their evaluation. The result was a smooth production process and a proposal submitted on time.
Waiting For Award
The proposal has not been awarded as of this writing; however, it was a recompete and the finished document better addressed the evaluation criteria, provided more reasons to select them, and addressed compliance in greater detail than their previous proposals. I think they have excellent chances and can't wait to hear the good news.
This is a continuation of a series of articles started in a previous newsletter about a company called The Chesapeake Center. I worked with them while developing the CapturePlanning.com MustWin Process, and they helped test many of the steps and forms. Their CEO, Bob Rogers, was kind enough to give me permission to write about our experience working together.
Start With A Plan
In order to prepare for the first major proposal after we started working together, we began working on the proposal planning documents. To the future Proposal Manager I was training, it seemed like a lot of paperwork. My challenge to her was to tell me which, if any, of the plans would not be needed. I believe that if there is anything in a proposal process you can get by without, then it shouldn't have been there in the first place.
This first proposal would prove to be a major eye-opener because it connected the things we did "up front" with the things we needed later. This proved to be a recurring theme for the entire proposal and one that helped them accept and understand the need for the steps in the process on their future proposals.
It's one thing to read that you should develop win strategies before the RFP is released so you can allocate them to the document, so that the proposal authors can substantiate them and you can achieve a proposal built from the ground up to achieve your win strategies and a competitive advantage. It's another thing to arrive at a draft without anything to discriminate yourself from the competition and see exactly how much better off you would have been had you followed the steps. It's even more clear when you can show them the pages in a written process book that they left blank. Having the reminder in writing also helps to ensure that they get it right the next time.
Lesson Learned: One ounce of doing a proposal is worth several pounds of process documentation if you don't have much experience. Maybe I'll create an exercise for a future proposal course that involves doing the process in reverse chronological order. Start with a finished proposal, and backtrack everything you need to get there. When they're done (and they have to be the ones doing it), they should find that information is created and staged in exactly the same places as are called for in the process.
Not Ready For RFP Release — Déjà vu!
As soon as we tried to complete the planning documents, we found that we didn't have all the information we needed. That is because the pre-RFP steps had not all been followed. This is not unusual at all. I can't remember ever working on a proposal where everyone felt they were fully prepared. In this case, the reason they didn't have all the information they needed was that while they had begun implementing the pre-RFP process, and had started using the forms, they weren't diligent about having pre-RFP Readiness Reviews. They were still learning how. Unfortunately, the result of not having the reviews was that the forms had empty fields that no one had challenged and now they didn't have the information they needed.
It is human nature when a form asks you a difficult question to skip it --- if you can get away with it. The purpose of the Readiness Reviews is to find any holes and figure out how to get them filled so that you will be prepared at RFP release.
What Do You Do Now?
One good thing about the way the process was set up is that it provides traceability. There are specific connections between what they needed after the RFP was released, and the questions on the pre-RFP forms. If you don't have something, you know exactly what it is, where it should have come from, and who should have provided it.
Lesson Learned: Hold Readiness Reviews, make sure all of the questions are answered, and verify that forms are completely filled out. This provides much clearer direction than the more typical "be better prepared for the next RFP."
It also put us in the position of knowing exactly what we needed to research and accomplish. Instead of having to develop a plan from scratch to deal with being unprepared, we had specific action items from the written process sitting in front of us. Because of this, when we had our meeting to validate the proposal plans it was more like a training exercise. Instead of focusing on describing the deficiencies and what to do about them, we focused on the links between pre-RFP and post-RFP success.
Building The Right Foundation
Another thing that became apparent was how much of the plans were re-useable. For example, the schedule page became a template that just needed new dates for the next proposal. The first effort in a new process is always the hardest. Creating the plans for future proposals would be much quicker. The best way to achieve having a written proposal plan for every proposal is to make it quick and easy to do so. The process we followed was designed to deliver the information needed so that it could be cut and pasted onto a template proposal plan in minutes instead of hours. Once they went through one, they saw that it was possible to complete it quickly if they had all the information. This is something they probably didn't believe before (although they were nice enough not to say it out loud). But the best part is that they saw the consequences of trying to do a proposal without having properly followed the pre-RFP steps and how much harder it makes things.
Because future plans would be easier to prepare and the pre-RFP information more complete (due to the Readiness Reviews), it would also be possible to do a better job on the Content Plan. Of all the proposal plans, the Content Plan is the one that I most closely link with success. The more complete it is, the more you know what you are doing and can validate the drafts. On Chesapeake's first proposal, the Content Plan consisted of little more than headings taken from a compliance matrix and placeholders. Many of the themes and win strategies that should have been developed pre-RFP were either missing or did not match up well when allocated to the outline.
Déjà vu All Over Again
When the Content Plan was handed off to the technical staff, it was largely ignored. They did what they had traditionally done and started from their own re-use files. Luckily our schedule called for early draft "check-ins" well ahead of final draft reviews. We had time to re-direct the authors. Sometimes re-directing authors to do something other than what they are used to can be difficult (like pulling teeth). In this case, we were able to clearly show that what was being produced was not RFP compliant. We also took the step of re-allocating what the authors had written to the Content Plan/outline and marked the wholes that needed to be completed. This made it easier for the authors and helped ensure that they understood what was expected.
Because we had created a Content Plan, even if it was a basic one, we had placeholders for themes. The contributors were still struggling with understanding how to write themes. It didn't help that they did business in a commodity market with evaluations based largely on price. They tended to skip the themes.
However, the placeholders in the Content Plan made it easier to approach the themes through a process of elimination. They also made it easier to develop themes that fit the structure of the proposal and to see how the themes added up to the overall win strategies. While the process called for developing win strategies during the pre-RFP period, it's hard to do this when you can't see how they impact the document. Going through the process of linking a list of win strategies to a Content Plan, and then writing to substantiate them and ending up with a document that is built around the win strategies, was really helpful.
Validating The Proposal
Once the writing had sufficiently progressed, we began implementing the Validation Plan. The first thing we discovered was compliance problems. There were many keywords from the RFP missing in the response. They had not checked compliance as thoroughly as the Validation Plan called for. We went down a long list of validation items. Going through the list helped them to better understand what is required to develop a winning proposal.
Lesson learned: Even though the process calls for verifying the Validation Plan at the beginning of the proposal and the items to be validated should be incorporated into the Content Plan, it might also be a good idea to go over the Validation Plan with the writers before they start to help ensure that expectations are clear. This way it is all spelled out for them.
Making changes after the reviews was straightforward --- fix specific validation items and then reevaluate them. It was a process of elimination and they managed to execute it without backtracking or second guessing areas that had passed their evaluation. The result was a smooth production process and a proposal submitted on time.
Waiting For Award
The proposal has not been awarded as of this writing; however, it was a recompete and the finished document better addressed the evaluation criteria, provided more reasons to select them, and addressed compliance in greater detail than their previous proposals. I think they have excellent chances and can't wait to hear the good news.
How To Take Advantage of Proposal Lessons Learned People often hold "lessons learned" meetings after a proposal submission. In my experience, the most positive thing that comes from these is providing people a chance to vent and clear the air. If you really want to use these sessions to improve your proposal quality, you need to re-think how you collect your lessons learned, and what you do once you have them.
Defining and applying lessons learned
For a lesson to be truly "learned," it must result in change. It is not enough to discuss and collect lessons learned. You must do something with what you find out. Issues should turn into action items that will lead to improvements on future proposals. Focus on how lessons learned apply to specific roles in the proposal process, not to individuals.
Consider how the following line of questioning elicits constructive feedback and focuses on positive changes:
Eliciting input after a customer debrief
There is much to learn from a debrief session with a customer:
Does what you learned apply to other/all customers/opportunities or just this one? Did you know enough about what the customer wanted? What questions would have given you the right information? How would you incorporate getting answers to these questions into the pre-RFP process? Did you find out that you had misinterpreted the customer? What questions would have mitigated misinterpretation in the pre-RFP release phase? Were there errors in the production or delivery of the proposal? What steps can you take on future proposals to prevent them? Are there additional steps or guidance that could be added to the process that would address other customer comments? Are there any changes you can make to the Validation Process to ensure a better proposal next time? Improving the effectiveness of the proposal process
In some instances issues arise because the process was not faithfully executed. Had the process been properly followed, the issue would not have come to be, or would have been mitigated. If this is the case, you can ask participants:
Would better guidance or notifications help with executing the process? Would better orientation/discussion and/or training help proposal contributors? If so, when should it occur? If this is not the case, it means that following the process did not prevent or mitigate the issue. In this case, you should ask:
Should you change what information you collect, when you collect it, how you collect it, or how you distribute the information? Should you clarify or change in any way the guidance provided? Should you change what, when, or how you validate the key aspects of the proposal? Evaluating process documentation issues
Consider if the lesson learned feedback impacts your process documentation:
Does the process address the topic identified? If yes: Where is it addressed, and how should the items be changed? If no: Should a new page/topic be added? Does the change have an impact on roles and responsibilities? What can occur earlier in the process to mitigate the issue? During future proposals, how can you validate that the issue has not recurred? Reminder: Keep a list of which process pages and topics you make changes to so that when you release a new edition you can reapply your changes.
Evaluating proposal software issues
Many companies now take advantage of software tools, such as Privia by Synchris, to facilitate workflow automation, proposal collaboration, and document management. If your company takes advantage of a software tool, consider the following line of questioning:
Were participants able to use the system as designed and to its full potential, or did they find the need to work around it? Did participants have sufficient technical support available when and how needed? Can the software issue be resolved through user training or guidance? If yes: Would better guidance or notifications help with executing the process? Are there features in the software that are not fully utilized? Would better orientation/discussion and/or training help? If so, when should it occur? Should it be provided online or offline (in person)? If no: Are there any network, equipment, or configuration issues that should be addressed? Did everyone have access that needed it? Does the workflow require changing? Do any of the templates or files in the workspace require changing?
Defining and applying lessons learned
For a lesson to be truly "learned," it must result in change. It is not enough to discuss and collect lessons learned. You must do something with what you find out. Issues should turn into action items that will lead to improvements on future proposals. Focus on how lessons learned apply to specific roles in the proposal process, not to individuals.
Consider how the following line of questioning elicits constructive feedback and focuses on positive changes:
Eliciting input after a customer debrief
There is much to learn from a debrief session with a customer:
Does what you learned apply to other/all customers/opportunities or just this one? Did you know enough about what the customer wanted? What questions would have given you the right information? How would you incorporate getting answers to these questions into the pre-RFP process? Did you find out that you had misinterpreted the customer? What questions would have mitigated misinterpretation in the pre-RFP release phase? Were there errors in the production or delivery of the proposal? What steps can you take on future proposals to prevent them? Are there additional steps or guidance that could be added to the process that would address other customer comments? Are there any changes you can make to the Validation Process to ensure a better proposal next time? Improving the effectiveness of the proposal process
In some instances issues arise because the process was not faithfully executed. Had the process been properly followed, the issue would not have come to be, or would have been mitigated. If this is the case, you can ask participants:
Would better guidance or notifications help with executing the process? Would better orientation/discussion and/or training help proposal contributors? If so, when should it occur? If this is not the case, it means that following the process did not prevent or mitigate the issue. In this case, you should ask:
Should you change what information you collect, when you collect it, how you collect it, or how you distribute the information? Should you clarify or change in any way the guidance provided? Should you change what, when, or how you validate the key aspects of the proposal? Evaluating process documentation issues
Consider if the lesson learned feedback impacts your process documentation:
Does the process address the topic identified? If yes: Where is it addressed, and how should the items be changed? If no: Should a new page/topic be added? Does the change have an impact on roles and responsibilities? What can occur earlier in the process to mitigate the issue? During future proposals, how can you validate that the issue has not recurred? Reminder: Keep a list of which process pages and topics you make changes to so that when you release a new edition you can reapply your changes.
Evaluating proposal software issues
Many companies now take advantage of software tools, such as Privia by Synchris, to facilitate workflow automation, proposal collaboration, and document management. If your company takes advantage of a software tool, consider the following line of questioning:
Were participants able to use the system as designed and to its full potential, or did they find the need to work around it? Did participants have sufficient technical support available when and how needed? Can the software issue be resolved through user training or guidance? If yes: Would better guidance or notifications help with executing the process? Are there features in the software that are not fully utilized? Would better orientation/discussion and/or training help? If so, when should it occur? Should it be provided online or offline (in person)? If no: Are there any network, equipment, or configuration issues that should be addressed? Did everyone have access that needed it? Does the workflow require changing? Do any of the templates or files in the workspace require changing?
Managing the Transition from Business Development to Proposal The biggest problem with the transition from business development to proposal is that there is any "transition" at all. A proposal is nothing more than the closing of the sales process. It is not a separate process, but the completion of a single process.
Companies do everything they can to disrupt this single process. They bring in new management and new staff. They reassign the previous management and staff. The information collected by the business developers is often discarded or is not formatted in a way that is useful to the proposal. The two phases are managed with different goals and procedures. The business development phase is often managed as if the goal is to achieve the client's permission to submit a proposal and nothing more. The two phases are even incentivized differently. There is little or no integration between them. Business development and proposal development are treated as two different things, until they become two different, unrelated, and not integrated processes.
When you define the proposal as the closing of the sales process, then the portion of the process that occurs prior to RFP release should be aimed at preparing for a successful close. To do this, you need to define what is required for a proposal to win and manage pre-RFP activity to deliver it.
Some of the things required for a proposal to win include:
A positive client relationship Proper positioning of the company and offering An offering that better reflects what the customer wants than the competitions' offerings Customer and opportunity intelligence that enable you to understand the client's preferences and write a winning proposal Competitive intelligence that enables you to outmaneuver the competition A top evaluation score A price that is perceived as the best value One excellent way to approach designing this process is to build it around the questions that you need to answer. For example, you can target your customer, opportunity, and competitive intelligence gathering efforts at the questions you need answers to in order to successfully close the sale with a winning proposal.
This does not mean that the proposal phase of activity directs the business development phase. The proposal is only part of what is needed for the sale to successfully close. The process should be designed and implemented from a perspective that integrates or is above both the business development and proposal activities.
That is why assigning a Capture Manager, in addition to a Business Development Manager and a Proposal Manager, is a best practice. A Business Development Manager typically pursues a portfolio of opportunities. A Proposal Manager is focused on preparing a winning document. The Capture Manager fulfills the need for someone dedicated to the pursuit of the opportunity who can integrate the Business Development and Proposal activities.
A Capture Manager can ensure that the way intelligence is gathered flows into a winning close to the sales process. A Capture Manager is the glue that binds the two parts into a single whole. For this to work, the Capture Manager must be involved once the lead is qualified to help the business development efforts work towards setting the stage for a winning proposal. This means gathering the right information for a winning proposal and doing all the things (other than the proposal itself) that are necessary for a successful close to the sale.
Companies do everything they can to disrupt this single process. They bring in new management and new staff. They reassign the previous management and staff. The information collected by the business developers is often discarded or is not formatted in a way that is useful to the proposal. The two phases are managed with different goals and procedures. The business development phase is often managed as if the goal is to achieve the client's permission to submit a proposal and nothing more. The two phases are even incentivized differently. There is little or no integration between them. Business development and proposal development are treated as two different things, until they become two different, unrelated, and not integrated processes.
When you define the proposal as the closing of the sales process, then the portion of the process that occurs prior to RFP release should be aimed at preparing for a successful close. To do this, you need to define what is required for a proposal to win and manage pre-RFP activity to deliver it.
Some of the things required for a proposal to win include:
A positive client relationship Proper positioning of the company and offering An offering that better reflects what the customer wants than the competitions' offerings Customer and opportunity intelligence that enable you to understand the client's preferences and write a winning proposal Competitive intelligence that enables you to outmaneuver the competition A top evaluation score A price that is perceived as the best value One excellent way to approach designing this process is to build it around the questions that you need to answer. For example, you can target your customer, opportunity, and competitive intelligence gathering efforts at the questions you need answers to in order to successfully close the sale with a winning proposal.
This does not mean that the proposal phase of activity directs the business development phase. The proposal is only part of what is needed for the sale to successfully close. The process should be designed and implemented from a perspective that integrates or is above both the business development and proposal activities.
That is why assigning a Capture Manager, in addition to a Business Development Manager and a Proposal Manager, is a best practice. A Business Development Manager typically pursues a portfolio of opportunities. A Proposal Manager is focused on preparing a winning document. The Capture Manager fulfills the need for someone dedicated to the pursuit of the opportunity who can integrate the Business Development and Proposal activities.
A Capture Manager can ensure that the way intelligence is gathered flows into a winning close to the sales process. A Capture Manager is the glue that binds the two parts into a single whole. For this to work, the Capture Manager must be involved once the lead is qualified to help the business development efforts work towards setting the stage for a winning proposal. This means gathering the right information for a winning proposal and doing all the things (other than the proposal itself) that are necessary for a successful close to the sale.
101 Things Your Business Development Process Should Address It's not the flow chart that makes a process successful. It's not even the process manual (that sits on a shelf) that makes a process successful. What makes a process successful are the tools that people use to execute the process. You need to make it easier for your stakeholders to execute a proposal using your process than it is to execute a process without your process. The tools and job aids you offer will determine how easy that is. Here is a list of 101 things that should be part of your business development process.
Introduction To The Process Descriptions Of Roles And Responsibilities Explanation For What The Executive Sponsor Can Expect Explanation For What The Business Development Manager Can Expect Explanation For What The Capture Manager Can Expect Explanation For What The Proposal Manager Can Expect Explanation For What The Process Administrator Can Expect Explanation For What The Production Manager Can Expect Explanation For What Writers Can Expect Explanation For What Subject Matter Experts Can Expect Explanation For What Reviewers Can Expect Explanation For What Production Staff Can Expect Guidance For Estimating Pursuit Staffing Requirements Guidance For Budgeting And Bid And Proposal Cost Accounting Form For Role Assignments List Of Goals To Be Achieved Before The RFP Is Released Form For Describing The Opportunity Form For Tracking Key Dates Form For Tracking The Contact History Form For Tracking Pursuit Action Items Description Of The Review Process To Ensure RFP Release Readiness Schedule For Readiness Reviews Guidance For Readiness Reviewers Explanation Of Bid/No Bid Considerations Bid/No Bid Decision Form Lead Identification Report Template Criteria/Requirements For Lead Identification Review Lead Identification Report Review Form Lead Qualification Report Template Criteria/Requirements For Lead Qualification Lead Qualification Report Review Form Intelligence Gathering Report Template Criteria/Requirements For Intelligence Gathering Intelligence Gathering Report Review Form Bid Preparation Report Template Criteria/Requirements For Bid Preparation Bid Preparation Report Review Form Capture Plan Report Template Criteria/Requirements For Capture Plan Capture Plan Review Form Teaming and Subcontracting Document Status Tracking Form Win Strategy Worksheet Description Of What To Do While You Are Waiting For RFP Release Sources Sought Release & Response Checklist Freedom Of Information Act (FOIA) Request Guidance Draft RFP Release Checklist Guide To Influencing The RFP RFP Release Checklist RFP Distribution List RFP Release Bid/No Bid Decision Form RFP Question Submission Guidance RFP Question Collection List RFP Amendment Checklist Kickoff Meeting Guidance Kickoff Meeting Agenda Kickoff Planning Worksheet Kickoff Meeting Invitation Template Proposal Schedule Guidance Sample 10, 30, 45, and 90 day Schedules Proposal Schedule Form Staffing And Assignments List Points Of Contact List Bid And Proposal Cost And Time Tracking Instructions Work Location Guidance And Reservation Instructions Equipment Request And Use Guidance Access Guidance (Physical, Network, Software) Proposal Software Guide Sustenance Guidance (Food And Personal Necessities) Lodging Guidance and Reservation Instructions Travel Guidance and Instructions Compliance Matrix/Outline Guidance Compliance Matrix/Outline Template Content Planning Guidance Content Plan Template Content Plan Checklist Production Planning Guidance Production Plan Template Proposal Quality Validation Guidance Proposal Quality Validation Planning Form Proposal Quality Validation Review Checklist Guidance For Managing The Schedule Guidance For Managing Assignments Guidance For Managing Validation Reviews Guidance For Managing Changes Guidance For Managing The Proposal Budget Guidance For Writers Templates For Writers Style Guide For Writers Configuration Management Instructions Instructions For Requesting Graphics Standards For Developing Graphics Tracking Form for Graphics Final Production Checklist Submission Readiness Checklist Shipping Instructions and Tracking Guidance Delivery Guidance Delivery Receipt Post Submission Plan Response To Questions, Requests For Clarification, Deficiencies, And Revisions Debrief Plan Lessons Learned Form
Introduction To The Process Descriptions Of Roles And Responsibilities Explanation For What The Executive Sponsor Can Expect Explanation For What The Business Development Manager Can Expect Explanation For What The Capture Manager Can Expect Explanation For What The Proposal Manager Can Expect Explanation For What The Process Administrator Can Expect Explanation For What The Production Manager Can Expect Explanation For What Writers Can Expect Explanation For What Subject Matter Experts Can Expect Explanation For What Reviewers Can Expect Explanation For What Production Staff Can Expect Guidance For Estimating Pursuit Staffing Requirements Guidance For Budgeting And Bid And Proposal Cost Accounting Form For Role Assignments List Of Goals To Be Achieved Before The RFP Is Released Form For Describing The Opportunity Form For Tracking Key Dates Form For Tracking The Contact History Form For Tracking Pursuit Action Items Description Of The Review Process To Ensure RFP Release Readiness Schedule For Readiness Reviews Guidance For Readiness Reviewers Explanation Of Bid/No Bid Considerations Bid/No Bid Decision Form Lead Identification Report Template Criteria/Requirements For Lead Identification Review Lead Identification Report Review Form Lead Qualification Report Template Criteria/Requirements For Lead Qualification Lead Qualification Report Review Form Intelligence Gathering Report Template Criteria/Requirements For Intelligence Gathering Intelligence Gathering Report Review Form Bid Preparation Report Template Criteria/Requirements For Bid Preparation Bid Preparation Report Review Form Capture Plan Report Template Criteria/Requirements For Capture Plan Capture Plan Review Form Teaming and Subcontracting Document Status Tracking Form Win Strategy Worksheet Description Of What To Do While You Are Waiting For RFP Release Sources Sought Release & Response Checklist Freedom Of Information Act (FOIA) Request Guidance Draft RFP Release Checklist Guide To Influencing The RFP RFP Release Checklist RFP Distribution List RFP Release Bid/No Bid Decision Form RFP Question Submission Guidance RFP Question Collection List RFP Amendment Checklist Kickoff Meeting Guidance Kickoff Meeting Agenda Kickoff Planning Worksheet Kickoff Meeting Invitation Template Proposal Schedule Guidance Sample 10, 30, 45, and 90 day Schedules Proposal Schedule Form Staffing And Assignments List Points Of Contact List Bid And Proposal Cost And Time Tracking Instructions Work Location Guidance And Reservation Instructions Equipment Request And Use Guidance Access Guidance (Physical, Network, Software) Proposal Software Guide Sustenance Guidance (Food And Personal Necessities) Lodging Guidance and Reservation Instructions Travel Guidance and Instructions Compliance Matrix/Outline Guidance Compliance Matrix/Outline Template Content Planning Guidance Content Plan Template Content Plan Checklist Production Planning Guidance Production Plan Template Proposal Quality Validation Guidance Proposal Quality Validation Planning Form Proposal Quality Validation Review Checklist Guidance For Managing The Schedule Guidance For Managing Assignments Guidance For Managing Validation Reviews Guidance For Managing Changes Guidance For Managing The Proposal Budget Guidance For Writers Templates For Writers Style Guide For Writers Configuration Management Instructions Instructions For Requesting Graphics Standards For Developing Graphics Tracking Form for Graphics Final Production Checklist Submission Readiness Checklist Shipping Instructions and Tracking Guidance Delivery Guidance Delivery Receipt Post Submission Plan Response To Questions, Requests For Clarification, Deficiencies, And Revisions Debrief Plan Lessons Learned Form
The proposal lifecycle Proposals written in response to Federal Government RFPs are typically given 30, 45, or 60 days for submission. Proposal schedules tend to be proportional — something that happens at the mid-point on a 30 days schedule will probably happen at the mid-point if the schedule is 60 days. The phases of activity in the proposal lifecycle are generally the same as well. Because time is limited, and the clock is ticking towards the deadline, most people try to front-load their schedules as much as possible to maximize the time available for actual writing and final production at the end of the proposal.
Pre-RFP. Be consistently successful requires starting ahead of RFP release. There are a number of things that you can do to prepare. RFP Release. Once the RFP hits the street, the deadline clock is ticking. If you have properly prepared prior to release you should be able to immediately act. At lot of proposals that go bad do so by taking too long to get started. If you have a formal bid/no-bid process you’ll want to decide within a day or two of RFP release so that you can schedule a kick-off meeting to get started on the proposal. At the kickoff meeting you’ll introduce the team, present the schedule, describe the proposal process, and get people started working. Pre-writing. Writing and re-writing until “you get it right” is a recipe for proposal disaster. That is why most formal proposal processes include a pre-writing phase to detail what needs to be written. Whether you use annotated outlines, storyboards, or something else it’ll typically consume the first 25% of the available schedule. These are normally followed by a review to ensure the quality of the subsequent draft. Draft production. When it’s been thought-thru ahead of time, writing proceeds more quickly. Production of the first draft typically takes the next 25% of the available schedule. Red Team review. While different people define color-team review labels differently, most people are familiar with a Red Team review as a (sometimes the only) formal review of the proposal by a team of senior managers (who were not the proposal writers). For it to be effective it must be a complete draft of the entire proposal (all writing complete). Ideally, the Red Team review should take place at about the half-way point on the schedule, but they often get pushed back. In any event it should be completed by the 75% point to allow time for recovery. A last-minute review can be worse then useless. Red Team recovery. A good Red Team will find things that are missing or must be fixed. You need to allow at least 15% of the available time to make these changes. Final Production. Sometimes the proposal enters final production section by section, some organizations wait until the entire document is ready. Some organizations allow changes while the document is in final production some do not. Typically 10% of the available schedule is required for final production. Submission. Don’t forget to allow time to get it there, whether you are submitting to a office in town or via FedEx. It is not unusual to submit two copies by different routes to ensure that it gets there on time. Extensions. The complexity of most RFPs usually results in questions that get submitted and answered in writing. If there are a lot of questions or the answers require significant changes, they may also include an extension to the deadline. Count on the answers to the questions disrupting the schedule (such as coming out the day before the Red Team review). In some cases there are multiple extensions, not only prolonging the agony, but wreaking havoc with the proposal budget as work typically continues around-the-clock until the deadline comes no matter how many extensions. The good news is that all proposals (eventually) end. And some of them you win.
Pre-RFP. Be consistently successful requires starting ahead of RFP release. There are a number of things that you can do to prepare. RFP Release. Once the RFP hits the street, the deadline clock is ticking. If you have properly prepared prior to release you should be able to immediately act. At lot of proposals that go bad do so by taking too long to get started. If you have a formal bid/no-bid process you’ll want to decide within a day or two of RFP release so that you can schedule a kick-off meeting to get started on the proposal. At the kickoff meeting you’ll introduce the team, present the schedule, describe the proposal process, and get people started working. Pre-writing. Writing and re-writing until “you get it right” is a recipe for proposal disaster. That is why most formal proposal processes include a pre-writing phase to detail what needs to be written. Whether you use annotated outlines, storyboards, or something else it’ll typically consume the first 25% of the available schedule. These are normally followed by a review to ensure the quality of the subsequent draft. Draft production. When it’s been thought-thru ahead of time, writing proceeds more quickly. Production of the first draft typically takes the next 25% of the available schedule. Red Team review. While different people define color-team review labels differently, most people are familiar with a Red Team review as a (sometimes the only) formal review of the proposal by a team of senior managers (who were not the proposal writers). For it to be effective it must be a complete draft of the entire proposal (all writing complete). Ideally, the Red Team review should take place at about the half-way point on the schedule, but they often get pushed back. In any event it should be completed by the 75% point to allow time for recovery. A last-minute review can be worse then useless. Red Team recovery. A good Red Team will find things that are missing or must be fixed. You need to allow at least 15% of the available time to make these changes. Final Production. Sometimes the proposal enters final production section by section, some organizations wait until the entire document is ready. Some organizations allow changes while the document is in final production some do not. Typically 10% of the available schedule is required for final production. Submission. Don’t forget to allow time to get it there, whether you are submitting to a office in town or via FedEx. It is not unusual to submit two copies by different routes to ensure that it gets there on time. Extensions. The complexity of most RFPs usually results in questions that get submitted and answered in writing. If there are a lot of questions or the answers require significant changes, they may also include an extension to the deadline. Count on the answers to the questions disrupting the schedule (such as coming out the day before the Red Team review). In some cases there are multiple extensions, not only prolonging the agony, but wreaking havoc with the proposal budget as work typically continues around-the-clock until the deadline comes no matter how many extensions. The good news is that all proposals (eventually) end. And some of them you win.
The proposal lifecycle (realist’s version) The RFP just came out. A couple of days ago. We didn’t tell you because we weren’t sure we were going to bid it. But we want to pursue it so now we’re trying to put a team together. First we have to decide which solution we’re going to bid. We just wanted to give you a heads up so you can be prepared. Oh, you want a copy of the RFP? I’ll see if I can get you one. How long will it take you to write the proposal?
A week after the RFP (on a 30 day schedule) was released you have the RFP, a draft outline, and the key players around a table for a kickoff meeting. All except the subcontractors, who are responsible for critical sections. You hash out assignments and give the authors three days to complete the storyboard forms you pass out. You get your first objections that there’s not enough time that it would be better if they just wrote their sections. You stick to your guns and explain why the storyboards are important.
Three days later, only half of the storyboards are done. The storyboard review meeting, instead of reviewing the plan for writing the proposal becomes a discussion about assignments and competing priorities. The storyboards are complete a day or two later and section writing starts. You give the authors four days for writing. When you check progress two days later, you find:
Most people have set the storyboards aside and are not using them as a map of the section A couple of people haven’t even started yet One section has changed the solution and not told anyone else At least one person doesn’t like the flow of the RFP and has come up with a better way to organize their section. Four days later only some of the sections are ready. You have three days to read them, edit them, and prepare for the Red Team review.
On the day of the Red Team, you have a draft of most sections. In a couple, you’ve only got the outline from the storyboard. The Red Team participant from one of the subcontractors shows up with their section. In addition to only being halfway complete, the half you have doesn’t fully address the RFP requirements.
The Red Team takes two days and gives the proposal a passing grade.
25 Four days after the proposal is at a stage you would consider a decent first draft. You distribute copies of the “Final Draft” to give participants a last chance to make changes. You give them two days. An executive decides that one of the sections needs to be re-written. Changes drift in over the next three days.
You begin final production, except for the section being re-written, applying formatting templates and inserting graphics. The re-written section comes in the day the proposal is due. You format it roughly and let it pass without graphics. When you produce the final formatted copy for QA prior to shipping, the same executive wants to review the other sections. You strenuously object, but are overruled. The executive promises to limit the review to typos and things that are “critical”. An hour before the proposal is due, with the rest of it packed into boxes, the executive hands over the last changes. They include wording changes and overlook a typo or two you saw when packing the proposal but didn’t say anything about. With only 45 minutes ago, a car leaves to deliver the proposal. You pray that they don’t get a speeding ticket (or worse) and blow the delivery.
They make the delivery and don’t bother to tell you until the next day. You’re not concerned because someone else has an RFP they want “some help” with…
PS: In an alternate version, the proposal gets extended 6 times, ends up taking 4 months, with the final answers to questions coming in the week that it is (finally) due.
A week after the RFP (on a 30 day schedule) was released you have the RFP, a draft outline, and the key players around a table for a kickoff meeting. All except the subcontractors, who are responsible for critical sections. You hash out assignments and give the authors three days to complete the storyboard forms you pass out. You get your first objections that there’s not enough time that it would be better if they just wrote their sections. You stick to your guns and explain why the storyboards are important.
Three days later, only half of the storyboards are done. The storyboard review meeting, instead of reviewing the plan for writing the proposal becomes a discussion about assignments and competing priorities. The storyboards are complete a day or two later and section writing starts. You give the authors four days for writing. When you check progress two days later, you find:
Most people have set the storyboards aside and are not using them as a map of the section A couple of people haven’t even started yet One section has changed the solution and not told anyone else At least one person doesn’t like the flow of the RFP and has come up with a better way to organize their section. Four days later only some of the sections are ready. You have three days to read them, edit them, and prepare for the Red Team review.
On the day of the Red Team, you have a draft of most sections. In a couple, you’ve only got the outline from the storyboard. The Red Team participant from one of the subcontractors shows up with their section. In addition to only being halfway complete, the half you have doesn’t fully address the RFP requirements.
The Red Team takes two days and gives the proposal a passing grade.
25 Four days after the proposal is at a stage you would consider a decent first draft. You distribute copies of the “Final Draft” to give participants a last chance to make changes. You give them two days. An executive decides that one of the sections needs to be re-written. Changes drift in over the next three days.
You begin final production, except for the section being re-written, applying formatting templates and inserting graphics. The re-written section comes in the day the proposal is due. You format it roughly and let it pass without graphics. When you produce the final formatted copy for QA prior to shipping, the same executive wants to review the other sections. You strenuously object, but are overruled. The executive promises to limit the review to typos and things that are “critical”. An hour before the proposal is due, with the rest of it packed into boxes, the executive hands over the last changes. They include wording changes and overlook a typo or two you saw when packing the proposal but didn’t say anything about. With only 45 minutes ago, a car leaves to deliver the proposal. You pray that they don’t get a speeding ticket (or worse) and blow the delivery.
They make the delivery and don’t bother to tell you until the next day. You’re not concerned because someone else has an RFP they want “some help” with…
PS: In an alternate version, the proposal gets extended 6 times, ends up taking 4 months, with the final answers to questions coming in the week that it is (finally) due.