Jump to content
captureplanning.com

Carl Dickson

Administrators
  • Posts

    327
  • Joined

  • Last visited

Everything posted by Carl Dickson

  1. 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?
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. There are a lot of bad examples of proposal outlines out there on the Internet. And many of them come from textbooks! Here is an example. Take a look at this proposal outline derived from an “Advanced Technical Writing” course offered by a university: Then forget you ever saw it. You don’t want your proposal to be organized like this because it: Forces the decision maker to read halfway through it before they find out what you are proposing Patronizes the decision maker by describing their own background to them and then telling them what their problem is Saves the conclusion for the end, when that should be the place where a proposal starts You see variations on this outline all over the place, probably because that's what people learned in school. The biggest problem with the outline above, and the reason why it increases the odds of losing your proposal if you follow it, is because it is not written from the decision maker’s point of view. All the headings do is categorize information. The primary goal of a proposal is not to deliver information or to be descriptive. The primary goal is to persuade a decision maker. Instead of delivering information, you need to help the receiver make their decision. This may involve delivering some information, but it is in a specific context and is not simply descriptive. The difference is vital. The best way to understand how to write a proposal is to put yourself in the shoes of the person making the decision. When someone asks you to do something, what do you need to see in order to reach your decision? The decision maker starts with questions and looks for answers. They don’t read your proposal. They look for answers. When you are the decision maker, your questions might include: What am I going to get or what will the results be? What do you want (from me)? How much is it going to cost and is it worth it? What will it take to make it happen? What could go wrong? Why should I believe you? Now pretend that you are receiving a proposal from someone who wants you to do something, approve something, or buy something. Think about the first thing you want to read. If you weren’t expecting to receive a proposal, it might be “What do you want (from me)?” If you were expecting the proposal, then the first thing you'll probably want to know is “What am I going to get?” This is closely followed by “What do I have to do to get it?” and “Is it worth it?” If you agree that it’s worth it, you’ll want to dig deeper and find out what it will take to make it happen. At that point you start looking for things that could go wrong and will want to make sure you can trust the person or company who brought you the proposal to deliver what they promise. If this is what the decision maker is looking for, then that is what your outline should be. You can use the questions above as your outline, but it's even better to use statements that summarize the answers. If you're writing a proposal in response to a written RFP that specifies how they want the proposal organized, you must follow their outline. However, the evaluator still has the same questions and they still need to find the answers in your proposal. An excellent way to exceed the RFP requirements without increasing the cost of your solution is to do a better job of answering these questions, especially the ones they forgot to ask. To win your proposal, you need to provide the decision maker with the answers they need and then motivate them to accept your proposal. You outline should be organized to meet their needs.
  19. Responding to the RFP is only part of what needs to go into a winning proposal. Consider: Evaluation criteria should be taken into consideration everywhere relevant in your proposal. The customer, opportunity, and competitive intelligence you have gathered that should be incorporated into your responses. The major components, features, and corresponding benefits of your offering. Your strategies for winning. All the themes and discriminators that provide the customer with the reasons they should select you. The points that you would like to emphasize in your response. The recommendations you would like to make to the customer. Any calls to action or things you would like the customer to do after reading your response. Any graphics, tables, appendices, and other exhibits or attachments you may want to include. Anything else you can think of that should go into your proposal. Each of the items above should be allocated across the outline for your proposal so that you know where they should be addressed. A compliance matrix is only part of what you need to plan your proposal writing. One approach you can take is to expand the compliance matrix into a comprehensive cross-reference matrix and include columns for each of the items on the list above. The only problem with this approach is that your matrix will quickly outgrow the paper size you are printing to. You need to cross-reference everything that will go into your proposal; you just can't (practically) use only a table to do it.
  20. Developing a Content Plan for a proposal typically starts with creating an outline. For proposals that are based on complex RFPs, the outline is based on an RFP compliance matrix. A compliance matrix is a table that shows where the various RFP requirements are addressed across the outline for the proposal. The first column of the matrix is the heading for the proposal. Each section of the RFP also gets a column. Each row in the matrix links each proposal section with one or more RFP requirements. RFP requirements can be entered into the matrix cells either as full text or just the RFP paragraph numbers (depending on the length of the RFP). A compliance matrix serves three purposes: It shows you what requirements must be addressed in a given section. It enables you to validate that all requirements have been responded to. It makes it easier for you (and potentially your customer) to understand the RFP and how to navigate your response to it. Creating the outline and the compliance matrix go hand-in-hand. If the RFP contains instructions regarding how to organize the proposal, you should start there. Next, add items to the outline until you have a place for everything you need to address. Because any given requirement or topic may impact the outline in multiple places, creating a compliance matrix can get complex. For example, if the customer asks you to address risk, but doesn't provide a specific place to do it, you may need to address risk throughout the proposal in a variety of contexts (technical, management, staffing, etc.). Parsing the RFP for individual requirements and then using the matrix to allocate every single requirement to one or more specific proposal sections can be a daunting task --- analogous to untangling spaghetti. Because of the vagaries of language, judgment calls may be necessary regarding where some items are relevant. As you complete the compliance matrix, you will modify your outline, probably many times, until you have the right balance of: Following the customer's instructions regarding organization A rational organization of information that will answer all of the customer's questions A clear, easy to navigate structure for the proposal document Complete compliance with all requirements An organization that is optimized against the customer's anticipated evaluation criteria and approach A presentation that best reflects your offering Your outline is not complete until it accommodates all of the requirements and other topics you need to address in your proposal.
  21. Black Hat reviews are a little like Red Team reviews in that I have never seen two people conduct them the same way. However, the subject of a Black Hat review is very different from that of a Red Team review. A Black Hat review is a competitive assessment to consider who the competition is, what their strengths and weaknesses, and how you should position against them in your proposal. The best Black Hat reviews score your company and your competition against the anticipated evaluation criteria. There are many techniques for acquiring and assessing competitive intelligence. These range from simple SWOT (Strengths, Weaknesses, Opportunities, and Threats) analysis to more sophisticated methodologies. The technique you use is less important than your diligence at implementing it. However, like risk assessment and quality assurance, if you don’t implement a formal methodology, you won't consistently get good results. Also, any assessment is only going to be as good as the data it's based on. Gathering good competitive intelligence takes time. If you simply bring all the stakeholders into a meeting and ask them what they know about the competition, you will not get the best data to work with. You must collect and validate competitive intelligence data throughout the lead qualification and capture phases of the pursuit if you are going to have solid data to assess at a Black Hat review. The key to a successful Black Hat review is to translate what you know about the competition into action items. And those action items should not simply be to fill in the holes in what you should know. The action items coming out of a Black Hat review need to affect your capture and proposal strategies in ways that will impact your odds of winning. Otherwise, it’s an academic exercise that doesn’t affect your chances (this is a fancy way of saying “a waste of time”). One set of action items that should come from a Black Hat review relates to teaming. A Black Hat review should tell you which companies are strong where you are weak and therefore make good teaming candidates, because you are more likely to win together than you are if you remain apart. It can also show you who you might want to take off the street by teaming with them. It may be better to give up a portion of the revenue by teaming with someone than it is to risk losing all the revenue in competition. Or not. A good Black Hat review should help you assess this quantitatively, by showing the effect on evaluation scoring of different teaming scenarios. That’s another reason that formal competitive assessment methodologies can be valuable. They help you look at things objectively by providing the means to rank and score the competition. Finally, a Black Hat review should help you finalize your win strategies. Win strategies cannot be developed in isolation from your competition. It's not enough to simply articulate to the customer why they should select you. You must also be able to say why they should select you, rather than your competition. A Black Hat review can help you formally position yourself against the competition instead of just guessing, the way most people (including your competitors) do.
  22. Reviewing a proposal involves a lot more than assessing compliance, style, and checking for typos. Here is a list of questions that reviewers should consider: Proposed Solution. Will it work? Does it fall within risk tolerances? Is it price-competitive? Is it best-in-class/best-value? Have all the benefits of the solution or approach been pointed out. Have all the features been sufficiently tied to the evaluation criteria in order to ensure credit? RFP Compliance. Note any ways that the section does not adequately address an RFP requirement. Make sure all RFP requirements are addressed, especially anything relevant in Sections C, M, and L as well as any other sections that might contract relevant requirements. Call attention to anything that might contradict an RFP requirement. Score. Give the section a grade according to the evaluation criteria, as if you were the client. Bid Strategies. Does it reflect the correct bid strategies? Additions. Note anything missing that should be added to the section or any parts that require additional detail. Deletions. Is there anything that really shouldn’t be there or that a client might find patronizing? Is there anything redundant or superfluous (We disagree with “tell them what you going to tell them” introductions and simply delete them). Is there anything that can be taken out that will make it easier for the evaluator to get through your proposal? Changes/corrections. Note anything that is not accurate or requires changing. Experience. Has all relevant corporate experience been mentioned? A lot of times proposal reviewers are senior managers and may be aware of project experience that didn’t occur to the proposal team. Themes. Are the themes for this section adequately highlighted? Graphics/Illustrations. Are there a sufficient number of graphics in the proposal? Is there anything in the text that could be enhanced through illustration?
  23. The most important tool for ensuring proposal quality at most companies is a Red Team review. A Red Team can turn a proposal that is destined to lose into a winner. However, the Red Team review process can be cumbersome, confusing to writers, and highly ineffective if not handled appropriately for the situation. When to hold a Red Team Review When to review a proposal presents a dilemma. The later the Red Team review, the better the shape the review document is in. However, a late review may not leave sufficient time to fix problems. The best way to handle this dilemma is to have one or more short reviews early in the proposal writing process. Types of Proposal Reviews While a traditional red team evaluation can be effective under the right circumstances, other methods are available. If the proposal is on an extremely tight schedule, for example, companies may wish to employ review approaches such as: running red teams, single person reviews, and internal reviews by members of the proposal team who were not involved with the preparation of the section being reviewed. The traditional red team is normally tasked with (1) evaluating and recommending improvement fixes and/or (2) evaluating and scoring the proposal according to the solicitation evaluation factors. Evaluating-and-Recommending-Fixes Red Team: An evaluating-and-recommending-fixes red team reviews the proposal for a broad range of factors, including: Compliance Completeness Responsiveness Presentation Sell The team makes recommendations on how deficiencies can be fixed. Although this red team does not have the customer expertise to formally score the proposal in accordance with the solicitation evaluation factors, it is helpful to provide an informal quality score (excellent, good, marginal, and unacceptable) of each section for general evaluation purposes. Customer-Evaluation-Simulation Red Team: This red team attempts to simulate the customer's formal proposal evaluation process. This red team measures the proposal by: Evaluating each solicitation requirement, listing proposer benefits and deficiencies, and identifying needed clarifi- cations for each solicitation requirement providing a specific score to each evaluated proposal section/subsection according to the solicitation evaluation factors. In order for this red team to score a proposal effectively, its members must have a comprehensive understanding of the customer's requirements including the budget for the proposed work and political agendas. This type of red team should include recent employees of the customer. Running Red Team: When a proposal is on an extremely tight schedule, a running red team is often an effective method of proposal evaluation. When a writer completes a section draft, he or she immediately gives it to the running red team for a quick response evaluation. Selecting Red Teams and Preparing for Proposal Evaluation For the most effective red team reviews, it is essential to select the right individuals, to ensure that they are adequately prepared prior to the actual proposal review, and to prepare the proposal properly for the review. Composition of Red Team: The foundation for an efficient red team is a team of skilled, experienced reviewers. Red team members comprised of all outsiders will generally be more objective than one with company members. Avoid using senior company executives on the red team unless they agree to give full-time effort to the review. The most important member of a red team is the red team manager. The ideal individual is someone totally familiar with the proposal review process, the proposal preparation, and the customer's requirements. Red team members normally include: Outside proposal professionals Customer specialists Employees who thoroughly know the bidder's capabilities, products, services, and past performance history Subject matter experts Red team members should be limited to those individuals who Can spend not only sufficient time evaluating the proposal but who can also assist the proposal team in making fixes. If early reviews (blue teams, pink teams, etc.) are used, the reviewers should be the same as those on the red team. One important review often omitted is the cost volume review. Many contracts are lost because of major inconsistencies between the proposal technical and cost volumes. Red Team Planning Procedures: The red team evaluation should be planned early. The proposal manager and capture manager should jointly select the red team manager. The capture manager, proposal manager, and red team manager should then determine the type of red team to be used, its exact function, and a list of desired red team members. Red team members should be provided with copies of the solicitation as soon as possible. In addition, it is beneficial to provide reviewers with red team procedures and evaluation forms prior to the evaluation. Red team procedures should include a breakdown of tasks for each red team member and a schedule for red team activities. Sample red team evaluation forms include: Proposal Deficiency Form Proposal Comments Form Proposal Scoring Form Preparing the Proposal for Red Team Evaluation: The most important thing in preparing a proposal for review is having it complete. If important text and graphics are missing or incomplete, the review is a waste of time. To ensure that the red team will understand the proposal, it is also important to write the proposal for the reviewer and to have totally completed executive summaries and section introductions that contain all major themes and discriminators. I recommend that the proposal be given a hard edit prior to red team review. I used to believe that significant editing prior to red team review was a waste of time. However, earlier this year I had a proposal assignment that changed my mind. I was managing two proposals that were similar in type and content and that were written concurrently by the same authors for the same federal customer. One of the proposals had a shorter due date, and we did not have the time to edit it prior to red team review. The reviewers of the unedited proposal came back with comments mostly relating to minor editing. However, the reviewers of the edited document were able to identify real deficiencies and weaknesses. In addition to having the text and graphics complete before the review, a detailed compliance matrix should be included. This compliance matrix should be in a check-off-list format that follows the requested information of the solicitation proposal instructions, evaluation factors, and statement of work. Red Team Evaluation I have found it better to have the red team members located together during the review than to have them separated. Continual discussions among the red team are important in recommending solutions. When I have worked with red teams where members were not co-located, the resulting recommendations were conflicting. After receiving the proposal, the red team evaluation procedures will include: Final assignment review Finalization of review schedule Coordination with proposal team for debrief and follow-up actions Review of total proposal against the solicitation requirements In-depth review of assigned sections, noting deficiencies and strengths, identifying needed clarifications, providing recommendations, and completing evaluation forms Compilation of comments into single book Debrief of proposal team. Reviewers should avoid general comments like, "motherhood," "marketing baloney," and "re-write." Be specific in making comments and recommendations. The red team should meet and prepare a formal debriefing to The proposal team. The presenters should emphasize only the major points relating to deficiencies, weaknesses, and strengths: minor issues can be documented on written evaluation forms. The red team should concentrate their presentation on a realistic approach to improve the proposal. Comments written in individual books should be combined into a single book. Post-Red Team Evaluation Actions After the red team evaluation, the red team members should assist the proposal team in making the recommended fixes. When this responsibility is understood in advance of the review, the red team comments will invariably be more realistic. The proposal manager is the person in charge of the proposal and he/she will have final say on accepting and implementing any red team recommendations.
  24. If you look at any proposal process, you will find the review phase to be at the heart of it. The review phase verifies that the proposal was written correctly. The planning phase helps ensure that the writing phase can successfully pass the review. Because the purpose of a proposal process is to improve quality, and quality is achieved through reviews, the proposal process serves mainly to prepare the document for review. The Proposal Quality Validation (PQV) methodology addresses the need for many types of reviews throughout all stages of the proposal. The basic approach to implementing PQV is to define the specific outcomes that you want and to plan a validation review to ensure that they are achieved. Recently I was considering how to integrate PQV into the overall proposal process. While thinking about it, I realized that every outcome desired during each phase of the proposal should be validated. Proposal Quality Validation isn't just for the review phase, it's for the entire effort. Traditional proposal processes treat the review phase as something that comes after writing and before production. With PQV, it is easy to extend the "review phase" much earlier into the process. This is usually a key goal of proposal managers, but difficult to achieve. Because PQV starts by validating the proposal plan, it already starts before the writing. In fact, PQV starts before the RFP is even released because it can be used to validate the readiness of proposal preparations. You could begin applying PQV the moment a lead is identified to ensure that it meets the specifications for pursuit. Like many things in PQV, these are things that you should be doing anyway. PQV helps you formalize them and make them part of an overall process. Here are some key attributes of PQV and how it impacts the overall proposal process. Phase/Activity PQV Impact On The Proposal Process Lead Identification and Qualification Validates that the opportunity is worth pursuing and corresponds to your strategic and tactical goals. Intelligence Gathering and Business Development Validates that you are ready to start the bid and have collected the information you will need to win. Proposal Start-up Validates the proposal plans prior to writing. Proposal Writing and Review Validates the execution of the plans by making sure that what was produced reflects what was planned. Proposal Production Validates the assembly of the final document to make sure it is accurate and ready to submit. PQV covers each phase of activity. It also forces you to identify the criteria by which you judge the quality of performance within each phase. It not only gives you the process, but also the tools to measure progress and performance within the process. It also provides a common basis for approaching each phase and brings everyone onto the same page regarding how to approach process within their areas of responsibility. Curiously, I developed PQV because the color team model has failed to produce effective results consistently. If the review process is the heart of the proposal process, and the review process is flawed, I wonder if that isn't a big part of the reason why people have been struggling with their proposal processes. I also wonder if a more effective review process might just lead to better results with the overall proposal process.
  25. The problems run far deeper than the lack of guidance that color team labels provide us with. The real problem is the lack of purpose and guidance in the color team model. The color team model does not add up to a completely validated proposal, because it was not designed to do that. Color team reviews were designed around a sequence of milestones. The reason they cannot be made to work is that you cannot define the scope of the reviews in such a way that they meet the need of the proposal for validation. People have been unwilling to get rid of color teams because the need for quality proposals is supreme, and an ineffective attempt at it is perceived as better than no attempt. Is this the best that the industry can come up with? We can throw out the "red team" but keep the goals. Indeed, we must throw out the Red Team in order to achieve the goals. The Red Team review in particular, and color team reviews in general, were created with good intentions. But they fail in implementation. If Red Teams are good in principle but can't be implemented effectively in practice, then I question whether they are any good. Without positive results after 20 years, Red Teams certainly can no longer be considered a best practice. Does it make sense for the entire industry to accept a process that no one can implement with consistent success? In spite of the good intentions, and in spite of the need, color team proposal reviews are a waste of time and resources. Even with Color Teams, the need for proposal validation is going un-met. It's time to drop Color Teams and replace them with some real validation. Call it evolution. What we really need... Well defined review scopes that validate specific items A methodology that defines the review requirements according to the needs of each particular business and proposal An approach that incorporates guidance for review team members Approaches for conducting reviews that better fit what circumstances require Less impact on proposal workflow ? reviews that can be conducted without freezing the baseline or requiring a wasted production cycle A way to determine what level of review is sufficient Traceability from issue through validation Quality assurance and quality control (they are two different things) Reviews that add value Reviews that help the proposal win How to Turn Down a Request for a Red Team From now on, when I am asked "When will we have the Red Team," I will answer:

Sign-up for our free newsletter and you'll be able to download our free eBook titled "Turning Your Proposals Into a Competitive Advantage" on the next page.

Sign up
Not now
×
×
  • Create New...