Project Documentation: Do You Know the 7 Keys to Getting it Right?

When I am training Project Managers, one of the main concerns I hear is about project documentation. No-one likes the feeling of bureaucracy. But we do know that some record-keeping is necessary.

So, here’s a topic to get every Project Manager’s heart racing… Project documentation. You know you need it, but it’s hardly a favorite!

The danger, of course, is that your project documentation fails to get the attention it deserves. But getting essential documents right is vital. So, you need to make it one of your top priorities.

That’s why, in this article, we look at everything you need to think about. And every big document needs a table of contents…

Contents: The 7 Keys to Good Project Documentation

1. Understand Why Project Documentation is Important
2. Recognize the Role of Project Documentation in Project Control
3. Know What Project Documentation to Use
4. Apply the Basics for Getting Project Documentation Right
5. Format Your Project Documentation Well
6. Manage Rigorous Version Control
7. Plan for Good Document Management 

So, let’s get started!

Estimated reading time: 24 minutes

1. Understand Why Project Documentation is Important

Since no one loves it, the first question we need to tackle is

‘Why should you prioritize project documentation?’

And the simple answer is this:

Project Documentation matters because it helps you manage your project, and to do so accountably. Click To Tweet

So, let’s break this apart a little and list the reasons why good project documents matter. And therefore, why you need to prioritize the time it takes to create and maintain them properly.

1. It’s all about management

Many of our project documents will either prompt or guide your actions on the project. Examples of prompts to action include:

• checklists
• risk registers
• test documents

Examples of guides to action include

• processes
• procedures
• plans

2. Good governance demands a rigorous audit trail

Part of the role of your project documentation is to record what you do and the reasons for your decisions. This allows objective reviewers to assess compliance and draw lessons from your decisions and experiences.

3. Communication is a good thing

A valuable role for some of your documents will be to inform team members, stakeholders, and the governance tiers of your project about what you are doing.

Each of these constituencies will value the information for different reasons. But nobody can make informed decisions or act effectively, unless they have ready access to important knowledge.

4. Preparing a project document stimulates creative thinking

Sometimes the best prompt to think through a problem or a decision innovatively is to discipline yourself to create a document. The structure this process can give to your thinking often opens up new ideas.

5. A good document helps to structures an argument

Likewise, structuring a good document compels you to think through the case you need to make in a rigorous way. Advocacy is a part of your role. You will sometimes need to persuade stakeholders, project steering groups, and even team members. The document you create may be a valuable aid. But often, the real value is in preparing it.

Are You a Project Manager or a Project Monkey?

All this is true and valuable. But it doesn’t set aside that nagging doubt that too many projects become bureaucratic. It seems as if they can easily become a constant round of form-filling and report-writing.

So, I have a simple guide that will remind you to be a Project Manager, and avoid the risk of becoming a Project Monkey.

Project Monkey
‘Monkey see: monkey do’ is an idiom that suggests monkeys don’t think carefully before acting.

A project monkey will see a template and complete it. A Project Manager will ask if the paperwork will help to either:

• deliver the project effectively, to specification, to budget, and on schedule, or
• do so in a transparent and accountable manner

If it will not, a Project Manager will pass on the paperwork and get on with something useful.

2. Recognize the Role of Project Documentation in Project Control

The one thing a Project Manager craves, above all else, is control. Click To Tweet

As a Project Manager, you know the value of Project Plans and Project Controls.

• Project Plans tell us how we are going to do something
• Project Controls tell us how we will stay on plan, get back on plan if we slide, and maintain accountability

Document Management and Version Control are two of your fundamental project controls.

Invest Time Early in Your Project

Like all project controls, it’s a good investment to allocate the time and resources you need to produce good project documentation. Most of this work needs to happen early in your project:

• Some will start in the Definition Stage, but
• You will produce most of your documentation in the Planning Stage.

Create a Reusable Suite of Well-designed Project Documentation

If good documentation is a wise investment, why not consider super-sizing?

Don’t just create the documents you need, but design them so you’ll be able to re-use them next time.

Many of the documents you’ll use on a project will be of value in future projects, with a little bit of adaptation. So, I recommend you invest a marginal additional effort in preparing documents that will be easy to adapt in the future.

The Role of a PMO

One role of a PMO (Project, Program or Portfolio Management Office) is to create and maintain a set of basic project management documentation, that Project Managers can draw down on. Indeed, many PMOs see project documentation as a core part of their function. They will:

• Create and maintain a library of templates and documentation standards
• Play a role in reviewing and authorizing project documents
• Maintain a filing structure and document archive
• Establish procedures for things like version control, archiving, deletion

3. Know What Project Documentation to Use

No-one likes the feeling of a load of bureaucracy. But we all know that some record-keeping is important. So what is the right amount of project documentation? And what is the secret to avoiding unnecessary reports and form-filling?

I’ll suggest:

1. Five absolutely vital forms of Project Documentation
2. And the five most valuable, from the other documentation you might consider

Video or Text?

If you are reading this article, you probably prefer reading, but I’ve also made a video that discusses the ‘Key Project Management Deliverables’…

Getting Project Documentation Right is all a Matter of Balance

Before we look at my suggestions, let’s think about how I developed them. The balance you need to strike is between:

• One the one hand…
  Good governance, transparency, accountability, and an audit trail
• And, on the other hand…
  Speed of execution, reduction of effort, focus on action, and efficiency

I have a simple approach, which would make a nice addition to my list of Project Management rules.

Only add documentation if it either supports good governance, or makes your job as Project Manager easier.

This is basic. As a Project Manager, you have one primary responsibility:

Deliver your Project within the rules your organization sets.

So your Project documentation needs to support this. If it isn’t helping, then it’s just getting in your way!

After all, your job is simple: to deliver your Project. You will, therefore, want to do anything that gets you better project management results.

The Big Question:
What’s the Absolute Minimum Project Documentation You can Get away with?

That, in a nutshell, is the question you want an answer to. So let me answer it…

Assuming you are doing the project for someone else (your organization or a client), then I think you must produce these five documents, some form of:

1. Project definition
2. Budget or business case
3. Plan
4. Risk register
5. Handover/sign-off document

These are spread pretty evenly across the eight essential Project Management steps.

Notice the Prescriptive Term ‘some form of…’

This is what allows you to scale and customize your documents to meet the needs of your project. I am very keen to avoid dictating what form of Project Documentation you will need, because every project is different.

So, what do I mean by ‘some form of…’ for each of these project documents. And how do I justify their prime position? Let’s take a look at each one in turn.

Project Definition / Charter

The first document you produce needs to set out what your project is, and what it is not. It also needs to establish a broad reason why to do the project.

Without this document, the sponsor has no basis to say yes or no to further, detailed research. And, once started, this is the document that tells you, your team, and your stakeholder what you are going to do – and not do.

Business Case / Budget

If your organization or your client is going to invest its money, its time, and its reputation, it needs to be sure this will bring sufficient rewards. A business case sets out the balance of costs and risks, against benefits and value.

Nobody should make a decision that carries any risk without some analysis of the cost and the potential return. This could be anything from an outline budget plus projected payback, to a sophisticated investment appraisal. Many organizations set standards for this. If yours doesn’t, then work with your sponsor to get the level of detail and the form of presentation just right.

Project Plan / Program

For some people, the project plan is the project documentation. The old adage that ‘Failing to Plan is Planning to Fail’ often holds true. So, if you have a plan, why not document it?

While big projects may use sophisticated planning tools, simple ones may only need a table of key milestones. Your plan will show your team and stakeholders what they can expect. It acts as a guide to action and also as a basis for monitoring.

Risk Register

You’re spending someone else’s money. And you are putting their reputation at hazard. Therefore, you need to demonstrate that you are managing the associated risks.

Your risk register is probably your most important Project Document. It acts as a document of record and most of all, as a management tool. At its simplest, it can be a list in your notebook, but for most projects, you’ll probably choose a spreadsheet.

Handover / Sign-off

Finally, once your project is completed, you need to hand its products over to their new owners or managers. So, you’ll need some simple project documentation that records and formalizes this. This will be your evidence that you have done the bulk of your job (prior to closing down your project) properly.

If those are the Minimum, What else is Important?

Our various courses come packaged with a wide variety of project documentation templates to help our students get started fast.

So far, I have listed the project documentation that is most relevant to all projects. In addition to these, you have a vast menu of other tools that can help you both deliver your project and also remain fully accountable.

Once I have the first five in place, what would be my next priorities? They would almost certainly be these five…

Stakeholder Engagement Plan

A simple document to record who my stakeholders are, and how I plan to engage with them in a positive way.

Resourcing Plan

This will be more than just a deployment plan. It will describe what resources you need, their necessary qualities (or specifications), and how you plan to acquire them.

Deliverables List

For me personally, this is probably my favorite piece of project documentation. A list of deliverables lets me tick off each one, as the team produces it. You can also use this to associate quality standards, specifications, delivery deadlines, responsible people, owners, and a dozen other things. A deliverables list could the basis of your project plan, above.

Status Reports

Once your project is underway, people need to know how you are doing. This is important for good governance – oversight and decision-making. It is also a key part of creating transparency and an audit trail.

And finally, it is a means of communicating with team members and stakeholders.

Lessons Learned Review

As a Project Manager, you have a responsibility to your team members. And one part of that is to help them learn and develop as professionals.

Consequently, take time to review what the team has learned together, and document it. This is not so much for the benefit of the organization, as it is for the team members themselves. Often, this will be the last piece of project documentation you will produce for a particular project.

But, of course, if you can make your lessons learned document valuable to your organization… So much the better!

What do You Think?

What do you consider the most important forms of Project Documentation? Let us know in the comments section below.

4. Apply the Basics for Getting Project Documentation Right

The rest of this article contains important detail. But if you are an impatient reader who just wants the absolute basics, here they are, in three steps. 

Step 1: Project Documents are Interim Deliverables

Project documents are interim deliverables. And deliverables are, to be blunt, what you are paid to produce. So, you need to:

• specify,
• schedule, and
• plan for producing them

This means allowing the time and resources you will need. And, that means you’ll need to negotiate for that time and those resources, when you are scoping your project.

Make sure you put the tasks for producing your project documentation into your initial scope statement. Then, build it into your work breakdown structure later on.

It will also help if you consider which project documents are going to be:

• Provisional
  You will continue to review and develop them throughout the project (like stakeholder plans)
• Fixed
  Or largely fixed. You’ll develop these once, and refine them if events render them no longer adequate (like change control procedure)

Step 2: Use Your Project Documents

This should be obvious. But I have seen some gross sins against the priority for utility.

Project Managers sometimes talk the talk by producing all the necessary documents for their projects. But then they forget them, and do the project on ‘gut instinct’. Or, to put it more precisely, they make it up (again) as they go along.

Not only is this a serious threat to good governance, but it undermines team and stakeholder confidence in what is going on.

But worse than that, it is just plain inefficient. It creates wasted effort and mistakes.

Step 3: Make your Documentation Accessible

If your team is to use the documentation it creates, it needs to be able to get at it. And get at it quickly and easily.

So, make sure all your documents are fully accessible to project team members. But, at the same time, you also need to ensure that they are secure, guarding for:

• confidentiality
• data protection
• unauthorized edits.

5. Format Your Project Documentation Well

Perhaps the single most important characteristic of good project documentation is consistency.

Yes, it is nice (even highly-desirable) for documents to have a consistent look and feel. But what matters here is the way consistency can speed up people’s ability to find information, because they know and recognize a format.

This applies equally to the layout of documents – where to find important pieces of information – and to the file formats you use for electronic versions.

Readability is Vital

We write documents to communicate with other people. So, never under-estimate the value of clear writing.

My top tips (from my live course: ‘Compelling, Persuasive, and Powerful Reports’) are to make your documents :

1. Compelling to read
   Do this by creating a simple structure and offering your readers frequent signposts, so they can easily follow your logic.
2. Easy to read by using simple, direct language.
   If you must use jargon or acronyms, always explain them unless you are 100 percent certain that every reader will know what they mean. Even then, spell out acronyms in full, the first time you use them
3. Pleasant to read
   Use neat formatting and plenty of white space
4. As easy as possible to understand
   You can achieve this by using illustrations, diagrams, graphs, and tables, to supplement your text
5. Persuasive
   Do this by separating facts from opinion, and recognizing the need to establish trust and credibility p front
6. Memorable
   Make the key information easy to recall, by emphasizing the key messages a number of times, in different ways
7. Powerful
   Give your documents the power to drive actions by setting out clearly, the decisions or actions you need your reader to take

Presentation is also Important

Think about the layout and formatting of your documents. A good starting place is your corporate style guide, if you have one. Failing this, look for the best and clearest internal documents, and adapt the style they use.

The front page, or cover sheet, is an important part of every project document. It should have on it:

• Project name
• Project Manager’s and Sponsor’s names
• Document name
• Version and date
• Document author

A great way to make sure people get this right every time, is to establish a consistent set of templates for people to use.

6. Manage Rigorous Version Control

Projects change constantly. And so, sometimes, do the people. For all the control you aim to impose, they can be busy, rushed, and even chaotic at times. And, of course, your documents will change too – sometimes frequently.

So it’s important that people know they are working from the right documents.

If a member of the project team updates a document, without telling people, disasters can arise. Two people can be working from different versions of the same document, and implement different and inconsistent work. The best case is inefficiency and wasted effort. At worst case, as with NASA’s Mars Climate Orbiter, is a fatal error that leads to complete failure of the project.

What is Version Control

Version control is a discipline that ensures three things:

1. There is a central register that allows any user to know the status of any document. Crucially, users can establish which version is current and that they can, therefore, rely upon
2. Each document contains unambiguous information that allows users to know its status
3. Users can track changes from one version to another, and so quickly understand the differences that a new version introduces

How to Make Version Control Work

The extent and rigor of your version control will depend on the:

1. Culture of your organizaton
2. Scale, risk, and sensitivity of your project

But the essential elements are:

• Unique Version Numbers
  Every document has a date and version (or revision) number clearly shown. My preference is that this appears on every page – usually in a footer or header
• Simple Version Numbering System
  The version numbering system needs to be simple but clear
  If in doubt, use a simplified form of software versioning:
  • 0.01, 0.02… for draft versions
  • 1.01, 1.02… for first approved versions
  • 2.01, 2.02… 3.01, 3.02… for subsequent small and large revisions
    
    For long projects where you expect many major revisions, I recommend a leading zero: ‘version 02.03’.

• Each document should have a version control table
  This will record the record of versions, the principal changes each one introduces, and the date of authorization
  Ideally, it will also record update authors and authorizers
• Version Review and Authorization
  Develop a procedure for review and authorization of new versions. You will tailor the sign-off procedures to meet the level of rigor your governance needs.
• A central register of documents and versions
  This allows users to easily check what is the latest version of any given document.
• Automated if possible
  There is software that can automate storage, recording, and version marking documents. But, as a minimum, you should build the basics into your document templates.

7. Plan for Good Document Management 

Your project documentation is valuable. So, you should treat your documents as assets that you need to take care of. We will look at two sides to this:

1. Keeping them… and not
2. Keeping them securely

1. Accessibility, Storage, Archiving, Deletion

The first consideration is storing documents so that users can find and access them easily, when they need to. Once documents are no longer current, and users won’t need to access them, you need to think about archiving them. Finally, every document needs a destruction date, to avoid uncontrolled storage costs.

Note: The exception to this is some Government projects in some jurisdictions. There, public archiving maintains some records in perpetuity. This may also be the case with other institutions, so do check procedures with officers of your organization – for example, a Company Secretary.

Do you need a Document Controller?

It’s just a thought. If you have a project administrator, that will help you ensure this gets done well. If you don’t, then consider allocating the role of document controller to one of your team members.

Accessible Storage

Accessible storage doesn’t just mean people can get at documents. They also need to be able to find the ones they need, when they need them, quickly. That means paying some attention to a good structure for your filing system, and a convenient naming structure.

For naming, I suggest a three-part document name:

1. One or two words that indicate the document’s classification – possibly preceded by a work breakdown structure (WBS code)
2. A long name that makes it crystal clear what the document is
3. The version number

Here’s an example:

09-Testing – User Acceptance Test Protocols – v01.03

Dispersed Documents

We’re all familiar with the way big corporations and Governmental bodies can work. Do you recognize this:

• Contracts stored in Legal
• Contractor service level agreements and tender documents stored in Procurement
• Budget approvals stored in Finance
• Network diagrams stored in IT
• …and so on.

There are some organizations whom I don’t suppose will solve this soon!

As Project Manager, you do need a register of project-related documents that are stored outside of your project team’s direct control. Ideally, this would have a post name and current post-holder against each one, so users can get the documents as quickly as possible.

What To Archive

When you archive documents, one question to consider is whether to archive all versions, all major versions, or simply the final version. There is no generic right answer I can offer you. Consider:

• The nature and duration of your project
• Your organization’s policies
• The nature of the documents you are considering

When to Archive

Who will need access to project documents, after the completion of your project? And for how long? Consider whether governance processes will continue – possibly in the form of longer-term benefits realization reviews. And what about future project managers who may need to learn from your project?

When to Throw Things Away

I alluded to this above. Start by consulting your organization’s standard policy. Then assess whether there is a case to make, for a different scheduled destruction date for any of your documents.

2. Document Security

The final set of considerations relates to document and data security.

You may have confidential information relating to:

• staff members and their performance
• contractors and consultants and their commercial terms
• vendors and their pricing
• your organizations strategic plans

So, you need to ask and answer four critical questions:

1. What will you do to enforce version integrity?
2. How will you ensure the physical security of documents?
3. What are your procedures for data protection?
4. How will you restrict the accessibility of confidential documentation?

For More on Project Document Management…

Take a look at our article, ‘Project Document Management: How to Organize and Manage Project Information’.

What’s Your Advice on Managing Project Documentation?

Have you had to manage project documentation? If so, tell us what advice you’d offer our community. And if you haven’t had to do so yet, what questions do you have, that we have not answered in this article?