The only must-have project documents you need (with 9 templates)

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 which budget was going to pay for it.

Oops.

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 (one article I found said you need 22 “essential” documents!! I’d never get any work done if I wrote that many). 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, not on spending hours making the project team review files.

So let’s talk about the essentials.

These are the nine documents that every project needs:

1. Business case
2. Project charter
3. Project plan
4. Schedule
5. RAID log
6. Status report
7. Budget tracker
8. Lessons learned review/retrospective
9. Project closure document

Below, we’ll look at each of these in more detail (don’t worry, none of these have to be huge documents — I’ll tell you now that some can just be an email!).

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.

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, summarizes the problem the project is going to solve, reviews the cost benefit analysis of doing the work and sets out the project goals.

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!

[lasso ref=”btg-emails” id=”22482″ link_id=”267976″]

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’.

This includes a risk management plan, quality plan, project communication plan, implementation plan, scope management plan, resource management plan and any other subsidiary plans.

Even if these individual documents are short, the overall goal is a comprehensive plan for how the management of the project will happen.

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:

• Risks
• Actions (and/or Assumptions)
• Issues
• 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 (especially potential risks and actions — I’m in those tabs of my file nearly every day). 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 key 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.

Project reports 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 in the lifecycle; the first is your lessons learned documentation.

Lessons learned documents might not actually be documents. You could store your lessons learned in a database, Sharepoint site 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 for future projects 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 items from the risk register, issues log 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.

This article first appeared at Rebel’s Guide to Project Management