Developing a Technical Solution is a Capture Activity and Frontloads your Proposal Effort.
The technical approach is the meat of your proposal and is often scored the highest in best value, trade off analysis evaluations. It has to be innovative and make your proposal stand out from the competition. However, it takes a longer than you might think to develop a custom solution for a specific customer and set of requirements. Waiting to start until the final request for proposal (RFP) is released means you’re behind, and you’ll have a difficult time focusing on solution development with all of the other activities going on during a live proposal. Corners get cut when you wait for the final RFP to start brainstorming.
You Need RFP Requirements to Start With.
Capture is the time for you to do the majority of your thinking and planning before the RFP is released, but you won’t have the RFP to work with. There are a few options available to you: 1) use the draft RFP that you don’t anticipate changing much, 2) use the old RFP if this is a re-compete, 3) if you don’t have either, then you need to develop your own RFP by using another RFP from this contracting office for instructions and evaluation criteria combined with similar statements of work for similar services. The key with these three scenarios is that you have to update the requirements based on your customer discussions about this work and intelligence gathering activities. We have done each of these scenarios in the past, and oftentimes we are not 100% correct. However, all the pre-work and planning created a solid baseline to build upon, and we were able to adjust easily when the Government threw curveballs during the final RFP.
Interview Subject Matter Experts (SME) Individually to Tease Out the Technical Solution.
If you have scarce access to technical experts, or brainstorming meetings are not feasible, you can develop a technical solution by interviewing SMEs individually. This is a less preferred approach, but it’s better than reusing old boilerplate approach that many companies resort to. Interviewing SMEs requires a proposal writer to have a solution architect’s mind to tie everything together. The key here is to ask your SMEs to explain things to you in detail because they are experts who know the subject matter inside and out. If you don’t understand what they’re talking about then the Government evaluators may not either. We cover interviewing techniques in detail in our Advanced Proposal Management class.
Use the Preferred Solution Development Approach: Brainstorm in a Group.
The preferred approach is to brainstorm in a group; its where people build off of one another’s ideas to create something that is greater than the sum of its parts. You should invite the right SMEs to the meeting, and have them sink their teeth into what the customer is really looking for. However, this issue becomes how we can maximize this precious time, as the SMEs are expensive, and busy.
Unstructured group brainstorming is flawed. You can go on for hours mulling over different subjects, drawing on whiteboard, and producing zero usable proposal material. Often the technical solution that results from an unstructured brainstorming meeting lacks persuasive power, is bland, and shows no innovation.
The solution is to use facilitated brainstorming with post-it notes on whiteboard or mind mapping software accessible to the entire team, so that everyone could collaborate in the cloud.
The sequence of a successful brainstorming starts with the warm up. We recommend using “stories of brilliance” – anecdotes of times when the team has come up with a brilliant solution or solved a difficult problem in the past. After a couple of team members tell such stories, it gets the team into a creative mode.
The next step is to generate massive quantity of ideas without judgement, using the requirements document that we discussed earlier as a guide. Every idea is good at this point. This process can be chaotic, and one outspoken team member may dominate the discussion. If this is the case, use silent idea generation where you ask your team to avoid saying anything and write down and reorder ideas on post-its. If you use discussion method, tell your team to write down more ideas or edit others’ ideas, while others talk to keep from interrupting. The key here is getting the detail; the post-it notes are there to remind us of the idea, but we need to capture the detail in a document. During this step, you don’t have to be sequential. If people have ideas about other sections, then you should capture that too. The creative part of your brain is random, and the more we can embrace a structured randomness (see below on how to implement this) the better our creative process will be. Don’t allow your team to edit as you brainstorm, that’s next.
After generating the ideas, we then want the group to order, sort, prioritize, and weed our ideas. This step happens only after you have gotten the bulk of your ideas written down in sufficient detail for another person who was not part of the brainstorming can understand what we’re talking about. Editing uses a different part of your brain, so we want to keep the two tasks separate in the process to get the best and fastest results. We cover proper brainstorming techniques in our Writing Persuasive Federal Proposals class.
How you brainstorming matters and depends on what information and talent you have available in the room. Here are five ways to brainstorm in a structured manner to embrace structured randomness.
Five Ways to Use Structured Brainstorming and Start Productive Technical Approach Development
1. Start with a project schedule.
If your project is a project that has a beginning, middle, and an end, you may want to develop a full project schedule first. You plan out the project execution in detail, include predecessors and successors for all activities, look for parallel activities and time savings, define a critical path, and resource-load your schedule if you can. You can then describe your schedule in your narrative, and your writing will go a lot faster.
2. Start with a flowchart.
In a process-based program where many steps are involved, you can develop a flowchart/workflow for every step in the process. This will allow you to focus on innovation and improvement when you can see the process at a glance. The creative ways that you find efficiencies and shortcuts will showcase your innovations in your proposal. Proposals are all about products and services being better, faster, cheaper, and/or less risky.
3. Start with a graphic.
Many times, on complex programs/projects with multiple moving parts and complex environments, it is useful to show to the customer in your proposal your concept of operations graphic (CONOPS), or OV-1 (a high-level operational concept graphic). You can start conceptualizing the graphic by developing the action caption or “take-away” of the graphic. Then you should lay out all the key elements of the program, all the stakeholders and processes, and anything else of importance to the successful program implementation. For example, you could include your customer’s challenges, your solution, and what constitutes a vision of mission success.
4. Start with win themes.
A proven proposal practice is to develop win themes early. Your win themes development generally starts with the proposal themes based on your capture intelligence that are applicable to the entire proposal – you must address every instruction and evaluation criteria. You would then move on to developing themes for every area of the statement of work. As you brainstorm on your advantages, you should focus on a Hot Button-Benefit-Feature-Proof-Action sequence. In other words, you document the customer’s hot buttons hidden in the requirement. Then, you would turn this hot button into a benefit desired by the customer. Your feature is the solution you offer based on the requirement to deliver that benefit. If you cannot come up with a feature, you have an action item that would allow you to do so in time. The actions you take to add those features is your gap analysis. Remember to add proof points to back up your claims and finish your win themes.
5. Start with a technical solution checklist.
Checklists enable disciplined decision-making. We specifically covered checklists in our video blog on this page. Checklists help you reduce tangents during discussions and shave hours off your brainstorming sessions. They also enable reuse of past successful solutions without the pitfalls of boilerplate.
With structured technical solution brainstorming, your capture effort will enable you to be prepared for the RFP issuance, and use your valuable SME resources wisely. Register for our Advanced Capture Management class to learn how to do this yourself, or call us at (301) 384-3350 for help developing solutions during capture.
Contact us to learn more.
