9 Essential Project Documents (With Templates)
(This post contains affiliate links. Read my full disclosure.)
I picked up a project from someone else not that long ago and I was three months into my management of it before I realized there wasn’t a project charter.
There were lots of other documents that all had a degree of overlap with a charter, but not an actual charter. That meant there were some key things missing from the project’s paperwork and the most important thing missing was who was going to pay for it.
That was a bit of a headache to sort out.
Project management can create a lot of paperwork, and it’s not always the stuff you want or need. In this article we’ll define what you really need and how to use it.
So, what documentation are we really talking about? Let’s define.
Project Management Documents: A definition
We can define project documents as:
The documentation created by a project manager in order to adequately manage, control and deliver the project.
What project documents do you need?
If you look in the project management standards and methods, you’ll find a ton of documentation mentioned, but do you really need it all? Honestly, for most projects you don’t.
If you are building a massive Olympic park or a military battleship, then there are higher standards for documentation, but for most projects done in office-based environments by small, medium and even large-ish firms, your time will be best spent on getting the basics right.
So let’s talk about the essentials.
These are the nine documents that every project needs:
- Business case
- Project charter
- Project plan
- RAID log
- Status report
- Budget tracker
- Lessons learned review/retrospective
- Project closure document
Below, we’ll look at each of these in more detail. I’ve organized the project management documents by phase so you can see the order in which they are typically created. And I’ve pointed out how to get templates for each of those so you don’t have to start from scratch.
As you read through the descriptions and learn more about what these documents are for, have a think about how they might be relevant to your project. Your business case is just a few lines in an email? That’s fine. Don’t create documents for the sake of it. It’s the concept behind the document that is important, not the length of the file itself. As long as they exist, and are written in some way for the archives, then that’s enough.
Ready to dive in? Let’s go.
Get copies of all these project document templates in one easy-to-use bundle with notes and guidance. Created by project managers, for project managers, this set of project document templates will help you manage your projects successfully.
1. Business Case
At the Concept or Idea phase of a project, someone comes up with a bright idea. That is written down into a formal project proposal or business case.
The project business case is the document that kicks off the whole project. It’s written to explain why the project should happen and it summarizes the problem the project is going to solve.
But here is where my definition of project documentation falls down: the business case is normally written by someone other than the project manager.
So who writes the business case?
In my experience, business cases are put together by the business owner who wants the change — the person who ultimately becomes the project sponsor.
However, it’s far, far easier to manage a project if you have had some involvement at business case stage because you understand the drivers and objectives better.
The business case should be comprehensive and persuasive with enough detail to justify the investment required for the project.
Having said that, the business case could be as simple as an email to an exec asking for permission to go forward with an initiative. If you were building an Olympic stadium, that level of informality wouldn’t be enough.
Be reasonable and pragmatic – there’s no point in creating overkill documentation at this point. It will just make people wary of what admin is to come.
Once the business case is approved, you can move forward into the Project Initiation phase.
2. Project Charter
The most important piece of paperwork in the Project Initiation phase is the project charter document.
You need this: it gives you the authority to act as project manager for the project. It’s your mandate to run the project and it’s the document that turns the project from an idea into an actual program of work, with allocated owners (and agreement on funding).
Without a project charter document, your project doesn’t formally exist!
Templates to help you set expectations, get information, request updates and manage issues. Aimed at Business Analysts but easily customizable for all project roles.
Project charters can be short or substantive. I prefer to use a fully-rounded version that in our terminology we call a Project Initiation Document. It includes everything you need to know about what you’re starting with.
Once you’ve got clarity on what the project is going to do, and the context in which it is going to operate, it’s time to move into the Planning phase.
3. Project Management Plan
There are two project planning documents created in the Planning phase. The first is the project management plan.
This is a huge document. In fact, it’s probably not one document (although I have bundled it together in the project management plan template you can find here).
In the past I have always managed it as separate documents but together they form ‘The Plan’.
More recently, my projects have been operating under a formal PMO structure, and much of what goes in a project management plan is basically repeating the formal processes.
Note: only create a planning document if you need it
There’s no point creating a plan document just to say, “We do it the way the PMO mandates, just like every other project in this company.” In that case, I have one over-arching project management plan document and it references corporate standards.
The plan covers everything you need to know and do to manage the project including things like managing project tolerances, variances, the change control approach, how you will assess quality and so on.
4. Project Schedule
The second project planning document that is important in the Planning phase is the project schedule.
Frankly, most people say ‘project plan’ when they mean ‘project schedule‘.
The project schedule sets out all the tasks, who is going to do them and when they are going to be done. It also tracks dependencies between tasks.
You can use software to organize the project timeline for you. There are hundreds of different project scheduling tools – most organization have something. The trouble is, it might not be perfect for what you want to use it for.
I create project schedules in Microsoft Project, Teamwork and Excel, because I use them for different things.
For communicating top-level milestones, I create a version of the schedule in Microsoft PowerPoint using the Office Timeline plugin.
However you choose to document your project schedule, the important thing is to keep it up to date.
5. Project RAID Log
We’re now moving into the fourth phase of the project, the Execution phase. At this point, you’ve got a number of important project documents. The first we’re going to look at for this phase is the RAID log.
RAID stands for:
- Actions (and/or Assumptions)
- Dependencies (and/or Decisions).
I use the term ‘RAID log’ to cover all the different logs relating to the project. That includes all the elements in the list above, plus changes. RAAIDDC is harder to say, though.
It pays to have a register of all these items. Your project RAID log is an important document that lets you can keep track of everything.
Read next: Everything you need to know about RAID in project management.
It’s easier to create than you’d expect as you only really need a few important fields:
- Item ID, so you know what line you’re talking about when you discuss the content with your team
- Item name
- Item description
- Action required
- Owner: don’t forget this or no one will take responsibility for doing anything about it
- Last updated date.
You can pretty much use that format for all the different sheets and trackers within your RAID log.
A RAID log can be part of your project management software or you can do what I do and maintain a project workbook spreadsheet that includes RAID and a lot more.
6. Project Status Reports
Project status reports are another critical document during the Execution phase. You are busy doing the work, so you need to tell people what work is going on. They also help you track what’s going on.
Project status reports cover a range of different scenarios. You have:
- Formal project board reports
- Weekly information team updates
- Formal reporting to the PMO
- Ad hoc reports whenever a stakeholder asks for something.
And so on. Project managers spend a lot of time reporting.
OK, these are a collection of documents rather than a single document. But they are really important because they’re the mechanism you use to get information to your stakeholders on a regular basis.
They are the formal written record of progress. And if they are any good, your stakeholders should take action as a result of reading them.
7. Project Budget Tracker
Finally for the Execution phase, you have a project budget tracker, another important project planning and control document.
Your project budget is a different sort of document — it includes less text, and a lot more numbers.
However, it helps to have a text-y document to go with the calculations that sets out information about contracts, procurement and the financial processes you’re expected to follow. You can wrap this into your project management plan.
The budget tracker needs to show you what you have forecasted to spend i.e. “the budget” and what you have actually spent. You can then get the spreadsheet to do the heavy lifting and work out the variance.
Variance is the difference between what you forecasted and what your actual spend was.
If you are overspent, you can identify the line items where this has happened. If you are coming in under your forecast, you may have some flexibility to add more items into scope.
Or you may have to hand the money back — different Finance departments and project sponsors will have different priorities!
8. Lessons Learned Review
As we carry on our review of project management documents by phase, we come to the final phase of your project: Closure. There are two project closure documents that are important at this point; the first is your lessons learned documentation.
Lessons learned documents might not actually be documents. You could store your lessons learned in a database like CornerThought or wiki, or some other searchable format.
Read next: Everything you need to know about lessons learned in project management.
I still produce formal end of project lessons learned documents though, and then copy the key lessons into any other system that requires them.
The lessons learned paperwork forms part of your project closure work. It only becomes a useful reference if you share it with the people on this team so they’ve got something that codifies the lessons they learned while working with you.
Equally, it should be shared with other project managers or they won’t benefit from what worked and what didn’t work.
9. Project Closure Document
Finally, during the Closure phase you should produce a formal project closure document.
This document summarizes:
- What the project delivered
- How the project performed against time, cost, quality and scope measures i.e. were you late, over-budget or struggling to get a quality result?
- Any outstanding risks, issues and actions at the point of closure
- The location of project files
- Anything else the person receiving the handover needs to know.
Of all the documents, this is the most important one to get formally signed off and approved. Without the project sponsor agreeing to the project being closed, the project is not closed.
You’ll end up doing ad hoc work and support for months. (Don’t ask me how I know.)
Choose the Documents That Work For Your Project
The most important thing to remember is that this is a guide. Tailor the project documentation you need so that you can best manage your project.
You need a detailed procurement plan? Make one. You don’t need a budget tracker as there is no external spend? Don’t create one and leave it blank; that’s a waste of your time.
Don’t get hung up on what you need to have – just use the above as a guide for what most projects of on-the-larger-side-of-small-but-not-gigantic have.
Less admin time spent creating documents that don’t add value means you can free up more time to lead your team. It’s more important that you do the work on the project. Onerous paperwork is no fun for anyone.
Grab document templates for these nine project documents you’ll be able to control your project without too much bureaucracy.
Pin for later reading:
Thanks for this article .. templates is very important in construction project management
This is superb. I am a scientist and have no training in PM. However, I’ve managed many small projects before and have now been asked to lead a project with multiple contributors and stakeholders. This advice will be with me through the project.
Thanks, Brian! Glad you found it useful.
Awesome Liz…. Thanks a ton. It was indeed very helpful.
Very nice and helpful to beginners.
Great! Can you please provide some templates?
I need to know the contents of a project
(student portal software)
I am looking for closing documents to close out a project, and possibly turn the project over from the PMO group to the managing group. Possibly maintenance documents (high level and detail level) Something to keep on file that would help outline the plan to turn project over to a working team.
Very helpful, thanks for uploading such valuable material.
I was curious. Some other heavily mentioned documents from my reading include Stakeholder and Communications Management plan. Is there any particular reason those were not included?
Hello Gary. Stakeholder Management and Comms plans are normally sub-plans of the Project Management Plan.
Hey elizaberth…i seam to be at cross roads here…..my company is trying to come up with a master plan for the next 10 to 15 year to come.apparently a request for proposals from specialised companies for which only one company expressed interest and submitted their proposals and unanimously, this company has been awarded a contract to do a master plan.i am now feeling confused because my company managemnent has tasked me to do a project document for this project in which i feel my role should be purely that of contract managent. please guide me….
is it real
ly me to do the project document? what reallly are they asking me to do
Why don’t you ask them what they think your role is? From what you have said it seems silly that the specialist company is doing the plan and they’ve also asked you to do the same work. You need to get clear on what your roles and responsibilities really are.
Also, as a project manager, I personally would not be putting together a plan for the next 15 years. That’s a strategic plan. Project plans have a much shorter horizon – you can’t plan detailed tasks for Year 14, you don’t know what progress will have been made by then.
Hi, just stumbled on to this page from a google search. Great summary of the PM required docs! Very helpful!
What about the requirements specifications and technical specifications, and any other actual project deliverable docs (not just the PM docs) – where would they place in the list of required docs.
I think these are project specific, and specs and requirements are the next level down from the statement of work. Once you know what you are doing at high level, you then dig into it in more detail. Thanks for commenting!
Yes, thank you so much. “Dig in” would mean “Decomposition”. Kindly correct if wrong
Yes, that’s right. It means ‘break down into smaller parts’.
Looking forward to seeing how you set up your Project Charter if you write an article about that subject. The initiation questions seem similar in what you are wanting to know and understand.
Chloe, that’s absolutely right. These are the questions that you’d ask early on in the project to feed in to the Project Charter.
Comments are closed.