Everyone in the federal contracting business knows that pulling together a proposal requires a symphony of players, all with different strengths and expertise to cover different areas of the proposal.
Like we’ve explained before, much of that work begins months before the Request for Proposal (RFP) even drops. Now, we want to turn our attention to the actual, physical act of writing the proposal once the Final RFP drops.
Let's Set the Stage
Imagine if you will, it’s 4:57 on a Friday afternoon, half of the staff has already slipped out for the weekend, when “ding” your Outlook goes off and you notice that the email seems to be from a Contracting Officer. Then, upon closer inspection, you realize it’s the RFP you’ve expected to drop every day for the last three weeks. A bunch of attachments of all types: Word, PDF, and Excel, totaling more than 700 pages in all. But no worry, they gave you a full 42 calendar days to respond. Awesome! Of course, it just so happens that Thanksgiving, Christmas, and New Year’s all fall within that 42 days.
OK, it’s not always this bad, but time is always tight. Making the most of the time available to you, most commonly 30 days, is critical.
All the Nitty Gritty Details of Proposal Development
Because this is a highly technical proposal with a 50-page technical response, you expect to have five different technical writers participate, in addition to the technical Book Boss. And these six writers are in addition to the half dozen that will get the Management Volume, Past Performance Volume, and the Cost Volumes ready for submission. Then, throw in 3-5 Pink Team, Red Team, and Gold Team reviewers. Pretty soon, you have a small army of folks who provide input to your proposal response. How do you coordinate the efforts of all these contributors?
Without a tool like OneTeam, Proposal Managers have to become Microsoft Word ninjas, cutting and pasting from the various RFP documents and then compiling feedback from the writers. They usually start by developing an outline for the Technical Volume in Word, and then they cut and paste in the Instructions to Offerors from Section L, the Evaluation Criteria from Section M, and the Statement of Work (or Performance Work Statement) from Section C into each individual section of the proposal.
On top of all this cutting and pasting, they then, in an effort to make it easier for their writers, color code each type of content. Once the L, M, and C content has been completed, the Proposal Manager may include boilerplate information, depending on the process the company follows, to give the writers a starting point, or the writers may get the document with just the blank areas for them to fill in.
Once the five technical writers have completed their portions, the Proposal Manager is back to Word ninja mode, cutting and pasting the various pieces into a master document that will then become the base document for the color review teams. Since the L, M, and C verbiage adds so much length, some Proposal Managers strip all of that out before sending the document to the color team, just so they know where they stand in terms of page count. Because the reviewers need that same L, M, and C verbiage that the writers had to ensure the proposal “answers the mail,” the Proposal Manager who decided to strip it out for page count purposes will send them the version of the document with it still in there. The color team reviewers, however, won’t know this when reviewing and editing since their copy still has the L, M, and C verbiage in it. The story keeps going, but I’ll stop for now.
Take Control of the Proposal Management Process with OneTeam
Is this crazy or what? Yes, it is. But for the longest time, it’s just what we had to do.
Enter OneTeam and its incredible proposal capabilities.
Using OneTeam, the Proposal Manager builds the outline of the proposal in a way similar to what they would do in Word, again cutting and pasting from the RFP documents. But from there, everything gets easier.
Building the outline one time feeds many proposal processes going forward. For this scenario, it lets the Proposal Manager assign each section of the proposal to a writer and then create Writer Packages with the click of a button, creating five separate Word documents that are unique for each technical writer. The OneTeam Word add-in gives the writers the ability to see the Section L, M, and C information off to the right side of the document they’re working in, obviating the need for the Proposal Manager to cut and paste that information into the document itself.
As the writer moves through the sections of the document, the add-in dynamically updates the appropriate Section L, M, and C information for the section the cursor is in. The add-in also provides a proposal outline to the left side of the document the writer is working on, with the writer’s assigned areas indicated as editable and those areas not assigned to her shown as locked. The writer can see the paragraph headings, making it easy to understand the flow of the document. But the writer cannot see any area of the proposal except what is assigned to them.
Using the information in the add-ins, and NOT in the document itself, the writers can focus on the flow of the document, page length, and everything else about making their writing as strong, and as compliant, as possible. When each writer completes their section, they simply save it back to OneTeam.
When the Proposal Manager is ready to compile the writer packages back into one technical document, she simply selects the five (in my scenario) writer packages, tells OneTeam to “Merge Writer Packages,” and in seconds receives a single document ready for color team review. No need to strip out L, M, and C info. No need to worry about writers working in the wrong areas of a proposal. No more Word ninja strategy.
This article has just scraped the surface of the proposal capability that OneTeam brings to federal contractors. Learn more here.