The Three Types of Project Documents

 

All project documentation can be given one of the following classifications:

1. Bridesmaid dress
2. Christmas tree
3. Monument

The first 2 were inspired by a line from Fight Club (about 1/4 of the way down).  Here’s how to tell which type you’re working on, with examples and how much time you should spend on each.

 

Bridesmaid Dress

A bridesmaid dress is important only to the bride, costs serious money and is thrown away after 1 wearing.  A bridesmaid dress document is a document that is just as expensive to create as any other document, whose sole purpose is to fulfill a process requirement, and read only once, if at all.

Like any other project document someone has to spend time filling in the control sections (e.g. version history, links to other docs, approver list, distribution list), in addition to crafting the real content.  The control sections take longer to fill out than the real content.  The content usually comes from a source to which project members already have access and could look up themselves if they really cared.  Project members must attend a meeting to review it.  Real time is spent, not just 1 person’s afternoon.

It is important only to the project manager because she is the one responsible for championing the process.  Mind you, it’s not her fault that it has to be completed, she’s just doing her job.  No one else really cares about it, though.

Only a few lines are relevant; many other pages won’t be read.  Even the relevant sections will be read only once, and only by the people for whom it really is relevant.  It might require 5 people to sign off, but only 1 will actually care about the contents.  Bridesmaid dress documents could easily be replaced with a maximum 10 line email, but no one creates template emails for projects.  Only a 10+ page Word template with a ton of control content will do.

An example is a test stage exit report.  Only the page with the defect status count summary is read by those interested.

As little time as possible should be spent crafting such a doc.  If you are starting from a template leave as many sections “N/A” as you can.  Only fill them out if someone asks, and even then with the bare minimum.

Christmas Tree

A Christmas tree costs time and money to assemble.  But the cost is borne because it is vital to those celebrating Christmas, and everyone benefits.  It’s enjoyed for weeks at a time, but after Christmas is thrown away or put back in the box for another year.

As with any project documentation, it costs real time and money to produce.  The template has all the same control sections as any other doc, like the bridesmaid dress doc, but the content takes much longer to produce than the control sections.  Team members review it, make changes that make it better and really read it before signing off.  People spend serious time on the doc but it is well justified.

A document of this type is a real necessity for the project.  Without it you couldn’t have the project.  People look at multiple sections multiple times throughout the duration of a project because it has useful, important information that project members must reference .  This doc is the first time in which this content appears – it’s not just a summary of other content.  The information feeds people’s efforts.  But it’s context is still limited to the project itself.

At the end of the project, though, the document itself is forgotten.  The content itself should be incorporated into a monument document.  Failure to do so will cause many future headaches because information is spread across multiple documents that no one can find.

An example is project business requirements for an application or system.  There’s nothing for a project to do without requirements.  They’re specific to the project, though, so they only express the changes, not the whole application or system.  By themselves they’re pretty useless to other projects, especially after the same requirement has been changed in a few projects.  They need to be added to a monument document to make sense across projects.

It’s totally appropriate to spend time on a Christmas tree document.  Everyone must remember, though, that it will be tossed aside or put away after the project and that the content must be put into a monument document to stay relevant.  Link to as many other project and monument documents as possible – don’t copy and paste content.  This is a waste of your readers’ time, and you’ll just have to spend time updating your copy when the source content changes.

Monument

A monument costs a lot of money, is relevant to many people and is used and lasts a long time.  Think war memorials, gravestones, the pyramids.

A monument document template has all the control sections of the other two, but are a tiny fraction of the total content.  The cost of producing the information may have been paid in previous projects.  Indeed, if you’re doing things right the content should already exist in Christmas tree documents, short of a complete rewrite of an existing monument document.  You’ll pay some time incorporating and reviewing new information, especially if the new info supersedes old info.  It’s well worth the cost, though, because people will be able to reference this one true source of information years later.

And people will reference it. This will be the authoritative source of knowledge about what a system should do, how it does it, how to test it or how to use it.  It will be your starting point for creating project Christmas trees and bridesmaid dresses.  Folks will actually enjoy reading it because it will be the one doc that others really care about and want to ensure its usefulness.  When you update it you’ll feel like you’re making a real contribution to something that will last longer than your employment at the company.

Which leads into the lifespan of a monument document.  It will be around as long as the thing it describes.  This could span a decade, even in technology.  I personally have worked on live code that is literally 10+ years old.  If a design doc had been written when the code was written people would still be updating it today.

Examples of monument documents are application or system design, or system/application requirements.  It doesn’t have to literally be a document, either.  A database of test cases or requirements would count too.  Really, anything that aggregates project-to-project changes and is kept up to date.

This is where anyone should spend serious time.  This is the most valuable type of document a company can own.  It will cut down on  new hires ramp up time.  It will be invaluable when you rewrite an application 5 years from now.  It will save you from mistakenly asking for a change that will affect changes made last year.  Such documents ARE your business.

This has been a summary of the three types of project document.  Hopefully it will help you spot the differences so that you spend the right amount of time on each one.