As we are all aware, "text library" is just another name for "boilerplate or database," information written at some time in the past for another use and now repurposed for a current pursuit. Personally, I have a few problems with the use of such a resource.
- Knowing these libraries exist can lead to procrastination of proposal teams, or of firms making the actual Go/No Go decision, because they feel a good portion of the proposal text is already written.
- Believing that significant portions of the text are already written may convince people to submit on opportunities that really should be a No Go for their firm because they believe the cost of (and therefore the loss due to) the effort is lower.
- People may forget to "search and replace," so you run the risk that a section of your new proposal may reference the wrong client name, location, or project being pursued.
- People may forget that even when you select material from the text library, you still have to edit the text to be completely responsive to the RFP. Many a submittal has been tossed because the team missed answering some questions that were not asked in the previous RFP.
- As your text library expands, even if you have time to reorganize and update whenever needed, that library gets more and more difficult to use, especially for newcomers to the firm's marketing staff, because there is just too much similar information.
- People may throw in "everything, including the kitchen sink" because the material already exists, rather than limiting themselves to just what the RFP asks for, which can make the required information more difficult for the selection team to find, or give the committee the feeling that your proposal is non-responsive.
In the early 1990s, I worked in the branch office of a large, national A/E firm that had just purchased Oracle for use as a marketing database. The principal in my office was very much of the "don't give them any information they didn't ask for" school of proposal writing. However, the corporate headquarters marketing staff seemed to believe in the philosophy of "never give a man 10 pages when you can give him 110 pages." So they used a lot of information, especially resumes, exactly as they came out of Oracle, with no tailoring. One proposal that included resumes of only six people, had a staffing section of more than 75 pages (i.e. they included the firm's senior electrical engineer, with his complete 17-page resume).
In another instance, a potential client asked about our transportation capabilities. Because the client never specified a transportation mode, headquarters marketing staff included project descriptions for municipal roads, state and US highways, airports, light and heavy rail, and bridges -- and included a full dozen project descriptions for each.
We used to joke that clients didn't READ proposals or SOQs; they WEIGHED them! Whether you call the resource a text library, a database, or boilerplate, this capability to store and retrieve virtually endless amounts of information has made it possible to produce huge documents full of material that wasn't requested, in amounts sure to make the client put the document down and go on to the next submittal.
Please be aware that I'm not saying that these information repositories are not useful and beneficial, because they can be. But I do recommend that firms establish "rules" or "guidelines" for their use.