Proposal Boilerplate - FEDERAL SECTOR REPORT - a newsletter for public sector agencies, contractors, and grantees

FEDERAL SECTOR REPORT

October 1996
(c) P2C2 Group, Inc.

PROPOSAL BOILERPLATE

Having a library of reusable text for proposals is indispensable. It can often cut the cost of proposal development dramatically. Grueling deadlines are less difficult. Source materials can be pre-edited so that techno-talk has already been transformed into English. The proposal manager, who is often a generalist, can draw upon reliable source material for exotic technical discussions that only a scientist or engineer could write.

When the P2C2 Group writes proposals for clients, it does so with the intention of adding to our client's storehouse of reusable modules. Taking this approach actually improves the quality of the immediate proposal, because we write thorough statements which provide a complete answer or solution, rather than cryptic responses limited to idiosyncratic requirements of RFPs. (Of course, when doing so, we must be absolutely sure that the information also scores a bulls-eye on the solicitation's evaluation criteria as well.)

If a government solicitation requires an unusual organization of text, we may actually write two versions of the information modules-one which is in a generic format (using the client's editorial standards), and the other formatted for the specific RFP. Over time, this saves money because it is difficult to "reverse engineer" an odd-ball format for reuse in future proposals.

Both in proposal development and management of boilerplate, the P2C2 Group emphasizes version control and descriptive information about each document. Particularly now that 32-bit operating systems free us from the old 8-character constraint (i.e., FILENAME.DOC), we give documents long names which include a functional name, the agency for which is was prepared, part of the solicitation number, the year, and the iteration number -- such as ProjRes_SCUBA_NAVSEA_00281.1996.v3.doc, which would designate a project resume (contract summary) for a project named SCUBA, prepared for NAVSEA in response to an RFP number ending with 00281, authored in the year 1996, containing version 3, in the format of a Microsoft Word .doc. We also add descriptive text to the "properties" dialog box under the file menu ... to enable key word searches and to identify the author. (Corel WordPerfect 7 has similar capabilities, as does some of the more specialized graphics and project management software.)

Be sure to use standard file extension names (such as .ppt for PowerPoint or .jpg for a JPEG graphic image) so you automatically know what kind of object it is.

The emphasis on version control may sound a bit extreme ... until you search for a particular module in a library with 500 or 1,500 file names. To avoid insanity, you will probably restrict the on-line library to read-only status, with a librarian authorized to maintain naming conventions and approve revisions to boilerplate files. You can also organize your modules into subdirectories -- such as Resume, Tech_Approach, Graphic, Proj_Resume, Flow_Chart, Org_Chart, GANTT, etc. In addition to these modules, you will want to organize another section of the library by proposal -- a subdirectory containing all files which support a particular proposal.

Establishing or improving your proposal boilerplate requires serious planning and follow-through. Here are some general rules:

1. Just as the public library has a classification system, you need to organize your library of boilerplate: general technical approaches, specific technical methods/procedures, technical diagrams and flow charts, literature reviews, management plans, business proposal material, project schedules and GANTT charts, contract summaries (project resumes), experience by client/agency, and descriptions of special capabilities and/or laboratories.

2. Users must be able to "check out" information either by segment or by an entire proposal volume. On-line retrieval is efficient-but use this only if you have implemented security safeguards and an on-line search system. (We are speaking of industrial security and not suggesting that you place classified documents on-line for public access.)

3. Boilerplate should always conform to your standard editorial style for your proposals. Failure to conform to this rule means that you will pay again for editing and formatting every time you use the material.

4. Boilerplate should conform to your software standard for word processing, spreadsheet, graphics, and project management software. You may also want to consider software that has been customized to support proposal development. If there is a good reason why the original source document cannot conform to your software standards, then convert it at the time of first re-use. (Some boilerplate is never used a second time, and there is no need to go to the expense of converting odd-duck materials. However, inform users of the availability of these non-standard documents in case they need to use them for a proposal.)

5. Your best talent should prepare complex technical sections. Having one or two other senior technical specialists review the material is a wise quality check. Adding weak modules to your proposal library can reduce your chances of winning.

6. Boilerplate should enter your library after comprehensive review (such as the final revision after red team review), i.e., after review for marketing, PR, and editorial quality as well as technical accuracy. (Have you heard the one about the engineer who used sexist language and made his company look bad?)

7. Be sure to maintain a database of characteristics about boilerplate: Original author, date of origin, authors of significant updates, agency to which it was first submitted, and the proposal title in which it was first used. Not only does this enable you to maintain version control, it gives you a chance to check for materials that may be outdated. Having the author's name provides a means to request an update or adaptation.

8. There should be a librarian in charge of the boilerplate. This may be a part-time duty, and the individual does not need to have a master's degree in library science. However, the librarian should care passionately about classifying, indexing, and protecting the boilerplate ... and helping users find what they need to win.

9. Persons who use the proposal library should be reasonably sophisticated so they do not use material out of context. Without guidance, a neophyte can turn into a Sorcerer's Apprentice who pieces together a real nightmare.

10. Users of the boilerplate are responsible for turning in edited, publishing-quality updates. The library should always be growing and improving in quality.

11. The library may contain multiple versions of boilerplate since it is often adapted to a variety of unique competitive requirements. Again, version control and ability to identify the purpose of a particular version are important.

12. Expect to invest in training users of boilerplate-how to search and locate information, tips for adapting it appropriately, and standards for editorial style and version control.

Sometimes it is necessary to be pushy to maintain an up- to-date boilerplate library. One of my favorite tactics: Require employees to update resumes and submit it on disk before conducting an annual salary/performance review. A similar tactic is to require project managers to submit updates to their project resumes at the time of their performance reviews.