Here’s a topic to get every Project Manager’s heart racing: project documentation. We know we need it, but it’s hardly a favorite!
The danger, of course, is that your project documentation fails to get the attention it deserves. Because 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.
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.
Many of our project documents will either prompt or guide your actions on the project.
Examples of prompts to action include checklists, risk registers, and test documents
Examples of guides to action include processes, procedures, and plans
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 the compliance and draw lessons from any mistakes you make.
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, if they do not 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, the structuring a good document requires 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 that 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. Some will start in the definition stage. You will produce most of your documentation during the planning stage.
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.
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…
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.
Most of this article contains important detail. But for an impatient reader who needs the absolute basics, here they are, in three steps.
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, and 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. 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, in terms of confidentiality, data protection, and unauthorized edits.
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 est 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.
Do you want a reliable set of templates, and haven’t the time to create templates for all the project management documentation you’ll need? Then take a look at ours. They are all editable.
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. 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 organisation like Company Secretaries.
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.
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 – v1.03
We’re all familiar with the way big corporations and Governmental bodies can work. Do you recognize this:
I don’t suppose some organizations will solve this soon. As Project Manager, you do need a register of project-related documents that are stored elsewhere. 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 organizations 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 relate to document and data security.
You may have confidential information relating to:
So, you need to ask and answer four critical questions:
I don’t want to bore the pants off you by padding this article out with a list of 20, 30, 50, or more project documents you may need. Because I don’t think that would be good value. But I do have one though, so let me know in the comments if you want it.
But I did write a short article in which I set out my top five most important project documents, and my second five too. Take a look at:
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 13 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.
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.