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…
So, let’s get started!
Estimated reading time: 24 minutes
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 TweetSo, 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.
Many of our project documents will either prompt or guide your actions on the project. Examples of prompts to action include:
Examples of guides to action include
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.
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.
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.
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.
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:
If it will not, a Project Manager will pass on the paperwork and get on with something useful.
As a Project Manager, you know the value of Project Plans and Project Controls.
Document Management and Version Control are two of your fundamental project controls.
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:
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.
If you don’t have a PMO, and haven’t the time to create templates for all the project management documentation you’ll need, take a look at ours.
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:
Take a look at this short video…
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:
If you are reading this article, you probably prefer reading, but I’ve also made a video that discusses the ‘Key Project Management Deliverables’…
Before we look at my suggestions, let’s think about how I developed them. The balance you need to strike is between:
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.
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:
These are spread pretty evenly across the eight essential Project Management steps.
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.
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.
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.
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.
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.
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.
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…
A simple document to record who my stakeholders are, and how I plan to engage with them in a positive way.
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.
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.
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.
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 consider the most important forms of Project Documentation? Let us know in the comments section below.
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.
Project documents are interim deliverables. And deliverables are, to be blunt, what you are paid to produce. So, you need to:
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:
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.
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:
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.
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 :
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:
A great way to make sure people get this right every time, is to establish a consistent set of templates for people to use.
If you don’t have a PMO, and haven’t the time to create templates for all the project management documentation you’ll need, take a look at ours.
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.
Version control is a discipline that ensures three things:
The extent and rigor of your version control will depend on the:
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:
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.
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 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:
Here’s an example:
09-Testing – User Acceptance Test Protocols – v01.03
We’re all familiar with the way big corporations and Governmental bodies can work. Do you recognize this:
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.
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:
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?
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.
The final set of considerations relates to document and data security.
You may have confidential information relating to:
So, you need to ask and answer four critical questions:
Take a look at our article, ‘Project Document Management: How to Organize and Manage Project Information’.
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?
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 14 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
What are Assurance and Audit in Project Management? Your Awesome Guide
Robust Project Definition: How to Build it and the Components you Need
I Don’t Like You – Trust and how to Deal with the Toughest Form of Resistance
Planning Performance Domain: How to Plan a Solution to Meet Your Goals
Session expired
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.