Technical documentation and proposals have bits and pieces that can be recycled and used over-and-over again.  It’s like the old saying goes, “Why reinvent the wheel.”  If you have written pieces and figures that you can reuse, then do it.  These recycled pieces are called “boilerplates.” However, you have to ensure that you don’t use them without ensuring that it works in the documents.   Here are ten boilerplates that are often reused, where to store them, and a warning that can’t be ignored:

Common Boilerplates

There are sections in different documentation that are the usual suspects when it comes to reusing them again:

1. Introduction – If you are working on a project, you have written an introduction for it. Therefore, use it for all the documents in that project.
2. Document Purpose – Every project is unique.  However, you can use a document purpose for the same kind of documentation type in different projects.  For instance, a Risk Management Plan has the same purpose regardless of the what kind of project it is.
3. Document Scope – The scope is similar to the purpose.  Same document type in different projects will usually have the same scope. Tweak it and reuse.
4. High-Level Figures – A high-level figure that depicts the overall project can be placed in the beginning area of any project.
5. Management Approach – In proposals, you usually have a section discussing how you will manage a project.  More than likely, they will be pretty similar because you usually don’t have different ways of managing different projects (the word to remember is usually).
6. Past Performances – If you have a project with the same scope, then reuse past performances.
7. Project Background – In documents, like Concept of Operations and Requirements documentation, you will discuss the background of the project. Same project; same background.
8. Technical Solution Training – You will usually have a basic training plan for your projects.
9. Deliverables – In proposals or project management documents, you will discuss the deliverables that you will give to the client. You will usually have a basic package, so have it handy to use over again.
10. High-Level Tables – Similar to figures (don’t know why I didn’t put them together).

Of course there are more, but these are the ones that I see more often than any kind.

Where to Store Boilerplates

Boilerplates don’t work if you don’t have them in a place that the entire team can reach.  Therefore, you need to have a central document repository where you can track them.  Regardless of which type of repository you use, you have to ensure that it has these features:

• Document Name – You have to name your documents in a way that are easy to identify by just looking at them. For instance, “X Project Document” is not good cause you don’t specify what kind of document it is.  “X Quality Assurance Plan” is a better name.
• Document Description – A mini description (think Twitter’s 140 characters) to identify even better.
• Date and Time – Show the latest date and time, so users can know when was the last time it was updated.
• Version – There can be different versions, so input the version here.
• Version Recovery – If someone makes a mistake, like erases the document, then have a place to restore older versions of the documents.
• Audit Trail – The worst mistake a team can do is not having a way to look at who made a change, what change it was, and the time it was done. Audit trails ensures that everyone is accountable for any changes to the modifications they make.
• Project Name – If you have manage a lot of projects, then have a repository for each project.  For the boilerplates that span across projects, have that in its own area.
• Document Category – This is optional, but useful if you maintain a lot of documents. If it’s a proposal, then specify that. Is it for Development, then mark it.

Boilerplate Warning

Yes, it is great reusing bits-and-pieces of documents, but you also have to be careful. The worst is not reading (and re-reading) your document to ensure that everything is 100% the way you want it. Make sure that your boilerplates flow with the rest of the writing, and that it isn’t clunky and easy to identify. You never want to do things blindly cause that can be your downfall.  Also, don’t think because you have boilerplates that you don’t have to do your research and write yourself. I see this more in proposals where companies just think they can take this and that from other areas. It’s obvious and annoying.

Boilerplates rock, but you have to be cautious.

Written by: Shevonne on February 7, 2011.
Last revised by: Shevonne on March 3, 2011.

Tags: boilerplates, document repository, recycle documents, reuse writing, reusing documents