The question, “What’s the best way to document a project?” often comes up at PMI meetings I attend and in conversations with clients. Every project is different in one way or another: methodology, technology, size, features, requirements, stakeholder needs, to name a few. The answer isn’t so simple, but here are a few ideas that will make your documentation process better.

Determine YOUR Needs

What information do you need to capture? How will it be used in your process? Who is your audience(s)? What types of documents do you need? These questions will give you distinct needs to address.
Document Examples

• A Project Charter may be needed for initiation and to describe the project to upper management. It may need to include business strategies or information on ROI.
• A Statement of Work might outline what resources are required
• Functional Requirements describe the project in detail.
• A Work Breakdown Structure or detailed Task List may be useful for estimating cost and time budgets
• A Timeline is used to chart progress against a baseline schedule.
• Status Reports keep everyone informed.
• Work Orders are effective for distributing work to team members.
• Change Control Forms create standard operating procedures.
• Lessons Learned prove to be valuable for saving information for future projects.
• A Project Plan probably consists of a number of the above documents and acts as the “bible” for your project.

Please note: there are numerous variations on all these documents.

Don’t Reinvent the Wheel

There are a multitude of resources available that have outlines, templates, forms and practices others have used to get you started – no need to start from scratch. Look online; project management web sites have resources, often for free. You can get templates and forms from PMI or other PM organizations. Ask your peers for help. They’ll gladly give you samples of what they have found that works well.

After you find something that looks appealing modify it to suit your needs. Don’t be afraid to change it as you use it. Constant improvement is part of any management process.

Make Sure it’s Easy to Create and Edit

I’ve seen too many templates where you spend almost as much time formatting and fighting the template as writing specifications. Documents should be helping the project, not hindering it. Make sure your template is easy to use when writing and quick to edit. Efficiency is a big part of making the documentation process effective and worthwhile.

Make Sure it’s Easy to Read

The whole point of writing documentation is to communicate. Make your message as easy to understand as possible and is well designed:

• Formatting – use type styles and sizes to create a visual hierarchy. Have consistent headers, subheads, lists, tables, footnotes, and other text elements.
• Organization – partition the document into logical sections where one section is dependent on its predecessor. The document should flow.

Keep Redundancy to a Minimum

An effective set of project documents do not repeat information. Each one has its job and together creates a whole set. Having information repeated in several documents creates big problems with revisions that affect the redundant information. Write so revisions will be isolated as much as possible and use inheritance.

Inheritance is when a document is a child of another document and information presented in the parent document is carried over to the child. Inheritance can eliminate the need for redundant information. As part of the child document, include a section that tells the reader what information is inherited and where it can be found. Do not copy things down.

Only Write What is Sufficient

Perhaps this is the biggest contributor to creating effective documentation. Only create the necessary documents that are needed for that project and only write them to the necessary level of detail. Just because you have the same templates available for each project, each project shouldn’t have the same documents. Templates are there to save time and provide standardization, but should also be flexible enough to accommodate a variety of circumstances. Consider only what is required to memorialize the project in print:

• What the team needs to complete their work
• What stakeholders need before, during and after the project
• Any compliance issues for regulatory organizations

Creating useful documentation is part of any project, but it should not be such a burden that the means does not justify the end. After a few competed documents and revisions, the process should be second nature. If it isn’t, take a look at problem areas and fix them. Don’t carry bad practices forward and don’t be afraid to innovate. Kaizen!