Storyboards and Content Planning
Storyboards are are a bad way to plan the writing of a proposal. While you can collect useful information that way, no matter what headings you choose it will be a tradeoff between levels of granularity, and coverage of topics. It will also inherently store the information under headings that are different from what is needed by the document, increasing inefficiency. But the issue really shouldn't be about whether or not to use storyboards. It should be about what's the most effective way to plan your proposal content.
Why We Don't Use Storyboards To Plan Our Proposals Storyboards are a planning tool that many people have heard of, but very few have implemented successfully. With storyboards, you complete a form for each item in the outline. The storyboard contains headings for items that should be addressed in each section. Authors complete the storyboards to provide the information that needs to be presented in a section and complete the low-level outline. Stakeholders can add and review information on the storyboards to perfect the plan prior to writing. Storyboards work well for proposals that require brainstorming a unique solution to the customer's problems.
However, storyboards have a number of problems:
They are inefficient, requiring the production of a document that is separate from the proposal itself. Because they are separate from the proposal, they are easily left behind and ignored by authors. They don't work well in a distributed environment with remote authors. There is a limit to the amount of information they can accommodate. Storyboards have one big advantage. If you take a large room and put them up on the walls, you can walk around the room and see the plan for the proposal. This assumes that you have a large room, and that all authors and reviewers are physically co-located. This is often not the case, mitigating the primary advantage of using storyboards.
We prefer a different approach, one that we refer to as creating a Content Plan. We prefer this approach because:
The planning document becomes a set of instructions that the authors follow. It smooths the transition from capture planning to proposal writing by providing a vehicle to carry intelligence forward. Authors work directly in the planning document instead of leaving it behind. Instead of creating extra steps, Content Plans make it easier for the authors. Content Plans can be used with geographically dispersed authors. The Content Plan turns proposal writing into a process of elimination and enables progress to be measured. The Content Plan provides a baseline that enables the proposal to be validated. While many of the goals are the same as storyboards, we find that this approach delivers better and more reliable results.
However, storyboards have a number of problems:
They are inefficient, requiring the production of a document that is separate from the proposal itself. Because they are separate from the proposal, they are easily left behind and ignored by authors. They don't work well in a distributed environment with remote authors. There is a limit to the amount of information they can accommodate. Storyboards have one big advantage. If you take a large room and put them up on the walls, you can walk around the room and see the plan for the proposal. This assumes that you have a large room, and that all authors and reviewers are physically co-located. This is often not the case, mitigating the primary advantage of using storyboards.
We prefer a different approach, one that we refer to as creating a Content Plan. We prefer this approach because:
The planning document becomes a set of instructions that the authors follow. It smooths the transition from capture planning to proposal writing by providing a vehicle to carry intelligence forward. Authors work directly in the planning document instead of leaving it behind. Instead of creating extra steps, Content Plans make it easier for the authors. Content Plans can be used with geographically dispersed authors. The Content Plan turns proposal writing into a process of elimination and enables progress to be measured. The Content Plan provides a baseline that enables the proposal to be validated. While many of the goals are the same as storyboards, we find that this approach delivers better and more reliable results.
The Real Reasons Nobody Uses Storyboards on Proposals Storyboards are one of those things that everyone recommends as a best practice, but hardly anyone actually uses. They are typically implemented as a form, often on oversized paper, that people use to plan proposal sections prior to writing. Authors are typically asked to complete the storyboard forms and then a review is held. Authors are supposed to wait until after the storyboard review to start writing. Very few organizations start with storyboards, and those that try them encounter numerous difficulties. With or without storyboards, you still need to plan what will go into your proposal sections. Companies that don’t use storyboards should be using other methods to plan the content of their proposals. Here are some reasons why nobody (or at least hardly anybody) uses storyboards.
Most RFPs make storyboards unnecessary. Things have changed over the last 20 years. RFPs have become better organized. In the past, the instructions, evaluation criteria, and statement of work did not match up, requiring complicated cross-referencing and numerous judgment calls. Today the parts of an RFP are usually in better alignment and you can respond to most RFPs by simply following the outline provided in the instructions. You still need to plan the content of your sections, but you don’t need storyboards to plan the outline. Storyboards are difficult to format and work with. You can’t fit everything you need on a storyboard on a single 8.5x11” sheet of paper. But even if you can print on 11x17” paper, it’s difficult to work with. For example, field offices, teaming partners, and people at home can’t print that size. If the end users assigned with completing the storyboards can’t manipulate and print them, they will have difficulty completing their assignments and the quality of the content will suffer. Storyboards are difficult to move information into and out of. If you are using tables, boxes, and lines to make your storyboards more like visual forms, then cutting and pasting text into or out of the storyboards usually means difficult and pointless reformatting. Storyboards put too much time and effort into documents that are intentionally orphaned. After all the production effort that goes into preparing storyboards, they get pushed aside when it’s time to create the proposal document. Even though storyboards give you some content to work with, you still start the document from a blank screen. Too often, they are abandoned completely. Storyboards don’t provide good instructions for authors to follow.Storyboards collect information, but don’t provide any guidance for what to do with that information. Storyboards do things like provide an out-of-context place to identify “themes,” without telling the authors where the theme should go in the draft or how to address the theme in their section. Storyboards don’t address everything that should go into a section.Storyboards have headings that address the most important things. The more headings, the more complicated it is to complete the storyboards. Anything left out makes it harder for authors to complete their drafts and creates potential quality issues. Storyboards are not flexible. The information you need to collect varies from one opportunity/RFP to the next. The goals that you are trying to achieve in a proposal can change from section to section. Having one format to use across all proposals, or even across a single proposal, means that in many cases it won’t quite fit. And that means that you are not quite collecting the right information. Storyboards don’t provide a good baseline to compare the draft against. It is so difficult to compare a draft document against a storyboard that most organizations using storyboards don’t use them in reviewing the draft document. The storyboards get left behind and the draft is reviewed on its own. The real problem is that storyboards aren’t providing what people need to successfully plan their proposals. The goal is good; it’s the implementation that has problems. When planning your next proposal, you might want to consider what your planning and validation goals are, and look for better ways to achieve them.
Most RFPs make storyboards unnecessary. Things have changed over the last 20 years. RFPs have become better organized. In the past, the instructions, evaluation criteria, and statement of work did not match up, requiring complicated cross-referencing and numerous judgment calls. Today the parts of an RFP are usually in better alignment and you can respond to most RFPs by simply following the outline provided in the instructions. You still need to plan the content of your sections, but you don’t need storyboards to plan the outline. Storyboards are difficult to format and work with. You can’t fit everything you need on a storyboard on a single 8.5x11” sheet of paper. But even if you can print on 11x17” paper, it’s difficult to work with. For example, field offices, teaming partners, and people at home can’t print that size. If the end users assigned with completing the storyboards can’t manipulate and print them, they will have difficulty completing their assignments and the quality of the content will suffer. Storyboards are difficult to move information into and out of. If you are using tables, boxes, and lines to make your storyboards more like visual forms, then cutting and pasting text into or out of the storyboards usually means difficult and pointless reformatting. Storyboards put too much time and effort into documents that are intentionally orphaned. After all the production effort that goes into preparing storyboards, they get pushed aside when it’s time to create the proposal document. Even though storyboards give you some content to work with, you still start the document from a blank screen. Too often, they are abandoned completely. Storyboards don’t provide good instructions for authors to follow.Storyboards collect information, but don’t provide any guidance for what to do with that information. Storyboards do things like provide an out-of-context place to identify “themes,” without telling the authors where the theme should go in the draft or how to address the theme in their section. Storyboards don’t address everything that should go into a section.Storyboards have headings that address the most important things. The more headings, the more complicated it is to complete the storyboards. Anything left out makes it harder for authors to complete their drafts and creates potential quality issues. Storyboards are not flexible. The information you need to collect varies from one opportunity/RFP to the next. The goals that you are trying to achieve in a proposal can change from section to section. Having one format to use across all proposals, or even across a single proposal, means that in many cases it won’t quite fit. And that means that you are not quite collecting the right information. Storyboards don’t provide a good baseline to compare the draft against. It is so difficult to compare a draft document against a storyboard that most organizations using storyboards don’t use them in reviewing the draft document. The storyboards get left behind and the draft is reviewed on its own. The real problem is that storyboards aren’t providing what people need to successfully plan their proposals. The goal is good; it’s the implementation that has problems. When planning your next proposal, you might want to consider what your planning and validation goals are, and look for better ways to achieve them.
What We Really Need (But Aren’t Getting) From Storyboards We have written about the reasons why nobody uses storyboards to plan their proposals. The first step in developing a better alternative to storyboards is to be clear about what we need from our proposal planning efforts. Here is a list of things you need in order to successfully plan your proposal content.
It should be in a format that will save people time. Section planning should be done in a similar format to that of the draft document to facilitate going from planning to writing. The format of the planning tool should not increase the amount of work required to generate a document. Instead, it should be a simple step to convert the plan into a draft document. It should provide instructions for the authors to follow. Instead of collecting information, we need to collect instructions for the authors to implement. It should provide a container to hold the ingredients for the section.It should hold everything that will go into the proposal section, such as topics to address, requirements to comply with, reminders, points of emphasis, conclusions you want the evaluator to reach, terms to use, placeholders for graphics, etc. It should work like a recipe. Reviewers should be able to look at it and ask “if all of these instructions are followed, will it result in the proposal we want to submit?” In other words, if you follow the recipe, will the dish be what you want to eat? It should provide a baseline to compare the draft against. You should be able to compare the draft against the plans to see if the draft addresses everything it should. In fact, you should be able to use the plan like a checklist to review the draft. It should provide a means to plan the solution as well as the content. Planning how you are going to do the work for the customer or how you are going to complete the project is very different from planning what you are going to write. You need to do both, and one planning tool may not address the needs of both. However, once you have determined what your approach or solution is going to be, you should be able to incorporate it into your plans for writing the proposal. What would something like this look like? It would start off as a shell proposal with all of the headings in place from the outline. Into this shell would go all of the instructions for the authors. These would start with the RFP requirements. These could be direct quotes or referenced by paragraph number. Then you would include everything else: things you need to do to implement your win strategies, things you have learned from intelligence gathering, things that will need to be addressed even though not required by the RFP, points of emphasis based on the evaluation criteria, placeholders for graphics, etc. The result is a document containing instructions (at the bullet level) that works like a “to-do” list or recipe. It is, in effect, a heavily annotated outline. Writing becomes a process of elimination, replacing each instruction with the writing that you incorporate into your text.
When your Content Plan is complete, you can review and validate that it has addressed everything it should. We have taken these ideas and incorporated them into the CapturePlanning.com MustWin Process. We use checklists to make sure that everything has been considered and that the Content Plan is complete. After the Content Plan is validated and turned into a draft of the proposal, we bring it back to review the draft. It is really helpful to compare the draft against the requirements put into the Content Plan.
The real test is whether the approach to planning enables you to plan before you write and whether it enables you to validate the draft. Storyboards aren’t used because people find that they take a lot of work to provide a mediocre plan that generally isn’t suitable for validating the draft against. The real reason to use a more efficient format isn’t simply to lower the effort; it’s to make it feasible to plan before you write. For the process to be successful, it must be clear to the participants (don’t expect them to take it on faith) that the effort saved during writing and getting through the review process is greater than the effort that goes into planning. Storyboards won’t get you there, but a Content Plan that puts everything into the document that they need just might.
It should be in a format that will save people time. Section planning should be done in a similar format to that of the draft document to facilitate going from planning to writing. The format of the planning tool should not increase the amount of work required to generate a document. Instead, it should be a simple step to convert the plan into a draft document. It should provide instructions for the authors to follow. Instead of collecting information, we need to collect instructions for the authors to implement. It should provide a container to hold the ingredients for the section.It should hold everything that will go into the proposal section, such as topics to address, requirements to comply with, reminders, points of emphasis, conclusions you want the evaluator to reach, terms to use, placeholders for graphics, etc. It should work like a recipe. Reviewers should be able to look at it and ask “if all of these instructions are followed, will it result in the proposal we want to submit?” In other words, if you follow the recipe, will the dish be what you want to eat? It should provide a baseline to compare the draft against. You should be able to compare the draft against the plans to see if the draft addresses everything it should. In fact, you should be able to use the plan like a checklist to review the draft. It should provide a means to plan the solution as well as the content. Planning how you are going to do the work for the customer or how you are going to complete the project is very different from planning what you are going to write. You need to do both, and one planning tool may not address the needs of both. However, once you have determined what your approach or solution is going to be, you should be able to incorporate it into your plans for writing the proposal. What would something like this look like? It would start off as a shell proposal with all of the headings in place from the outline. Into this shell would go all of the instructions for the authors. These would start with the RFP requirements. These could be direct quotes or referenced by paragraph number. Then you would include everything else: things you need to do to implement your win strategies, things you have learned from intelligence gathering, things that will need to be addressed even though not required by the RFP, points of emphasis based on the evaluation criteria, placeholders for graphics, etc. The result is a document containing instructions (at the bullet level) that works like a “to-do” list or recipe. It is, in effect, a heavily annotated outline. Writing becomes a process of elimination, replacing each instruction with the writing that you incorporate into your text.
When your Content Plan is complete, you can review and validate that it has addressed everything it should. We have taken these ideas and incorporated them into the CapturePlanning.com MustWin Process. We use checklists to make sure that everything has been considered and that the Content Plan is complete. After the Content Plan is validated and turned into a draft of the proposal, we bring it back to review the draft. It is really helpful to compare the draft against the requirements put into the Content Plan.
The real test is whether the approach to planning enables you to plan before you write and whether it enables you to validate the draft. Storyboards aren’t used because people find that they take a lot of work to provide a mediocre plan that generally isn’t suitable for validating the draft against. The real reason to use a more efficient format isn’t simply to lower the effort; it’s to make it feasible to plan before you write. For the process to be successful, it must be clear to the participants (don’t expect them to take it on faith) that the effort saved during writing and getting through the review process is greater than the effort that goes into planning. Storyboards won’t get you there, but a Content Plan that puts everything into the document that they need just might.