“I was handed this project. I’m unsure which documents are needed.
Should I create a:
- RAID
- WBS
- Issue Log
- Project Schedule
- RACI
- Network diagram
- Project Budget
- Decision Log
- Project Management Plan
- Change Management Plan
- Risk Management Plan
- Quality Management Plan
- Resource Management Plan
- …
Add 126 more documents!
There’s an endless menu of project documents, and it’s driving people nuts. They don’t know which docs they should create for their project.
And once they start googling, things become even more confusing.
Because on every blog and every forum, they’ll find a different opinion.
One blog claims “You definitely need a Quality Management Plan.”
Another says, “Nothing works without a Risk Management Plan!”
Yet another swears by the benefits of a RAID Log.
Then there are those project management experts in suits who spread their overblown lists of necessary documents on the internet. You have to wonder: Do these people live in the real world? Have they ever managed an actual project?
There are two issues with these “must-have project documentation” lists:
1) Many of the commonly listed documents are only needed for large-scale projects with multimillion-dollar budgets.
Imagine a project for a factory relocation. Of course, you need a Change Management Plan for that. Or think about the construction of a wind turbine. These are highly complex projects with thousands or millions of moving parts. For sure you need a detailed Work Breakdown Structure (WBS) and a Risk Management Plan for that, maybe even a dedicated Risk Manager.
Even I, who has led multimillion-dollar IT implementations, managed with relatively little project documentation. We focused on the essentials, and it worked great. Because maintaining documentation takes a ton of time, and I still wanted to have enough time to focus on my leadership tasks. That’s what we project managers are hired for!
2) The other problem with these document overviews is that they are only relevant for certain types of projects, such as IT projects. Then it makes little sense to use these documents for an HR project.
With this article, I’m trying to convey a different approach to the topic of project documentation.
In this guide, I’ll explain the documents you should definitely create, regardless of the type of project. Whether you work in engineering or you’re leading an IT project, or it’s a marketing or finance topic. It doesn’t matter!
Why did I pick these documents?
The mentioned documents are great because they give you a clear roadmap to setting up your project. They make your job easier and help you know where to put your focus. And that puts you well on your way to a successful project.
As a former Senior Project Manager with over a decade in the trenches managing projects, I had to deal with project documentation every day. I’ve tried what works and what’s just extra paperwork. So, my perspective on necessary documents comes from a practical perspective, and I think you’ll appreciate that.
We’ll look at each document one by one, and I’ll explain:
- Why the document is useful
- What structure the document should have
- What content should go into each document
- How to gather the necessary content
Armed with this knowledge, you can start setting up your project.
Are you ready?
Let’s dive right in.
Why Do We Create Project Documentation?
You may think of creating project documentation as a chore. But actually, those documents we’ll be looking at are an immensely helpful tool that is going to make your life easier.
And the time you invest into their creation will pay off tenfold through the course of your project and will spare you many headaches.
Put simply, we create project documentation to capture key information about our project so that we have a basis for discussion when talking to contributors and stakeholders.
For instance, we can create a schedule and share it with our team, so people will know exactly what they need to work on – and when.
Or we create a budget showing the expected cost, and there will be no confusion as to how much the project is going to cost. Same for the other documents. All necessary information can be found in a dedicated document which people can study or comment on.
This benefit, that you can establish a common understanding of a project through simple documentation is huge. Especially if you consider people all coming from different backgrounds and with their own priorities, which typically makes projects challenging.
That being said, I urge you to take project documentation seriously. Prepare each document with great care, and without skipping any sections just because you are unsure about what to include.
Next, let’s look at the documents you might want to create for your project:
The Essential Documents For Any Project
Documents are covered in no particular order. Later in this article, I will talk about which order makes the most sense.
Documents covered:
Document #1: Project Schedule
Purpose: This is THE document in any project. The schedule shows the steps necessary to accomplish the project goal using a timeline format. In addition, we also include key project milestones – specific markers that indicate the completion of an important activity or deliverable.
Structure & Format: Project schedules come in all sorts of formats – hourly, daily, weekly, monthly — you just need to pick a format that is most suitable for you.
For example, I typically use a weekly schedule format, because it aligns with the way I manage work. I will not tell my team what day the work has to be carried out. I only let people know by when it must be finished, which is usually by the end of the week. If I were to use a daily schedule and some of the tasks got nudged by a day or two, I would constantly have to update my schedule, which would be insane.
Here’s what my schedules look like:
Yes, it’s built in Excel.
There are a few scenarios where you want more granular planning – a construction project for example, where work is planned on a daily or even hourly level, but this is a special category of projects. And unless you work in construction, you can generally safely start with a weekly schedule. There may be particular activities that you may need to plan on an hour-by-hour basis, but these can be shown on a separate plan.
Necessary details: Your schedule should include all project-related activities, broken down on a timeline.
Add key milestones. Examples of milestones could be:
- Project approved
- Concept completed
- Software ready for testing
- Test complete
- Go-Live
- Other helpful information would be the task owner for each task.
How to create a schedule: Building a schedule requires creativity and lots of brainstorming, along with input from the experts you are working with. First you identify the core activities and support activities, and then you bring them in the right order, so that the outcome of one task will feed into the next. This is a tedious and often frustrating process, because you are dealing with so many limitations – people’s availability, concurrent projects, public holidays and so on – still you need to find a workable schedule.
Building a schedule is not something you (as the project manager) do on your own. You prepare a draft and show it to your team and stakeholders. You collect feedback and refine the schedule until it looks good. Building a schedule is a highly collaborative process!
Document #2: Project Budget
Purpose: The project budget shows the total cost of a project. Cost can involve resources consumed in the process, such as human resources or materials used. The budget also includes expenses, such as administrative cost, travel cost, insurance fees or other services.
Because we don’t just care about the planned cost, as project managers we also want to keep track of the actual costs – that is how much we are effectively spending. Comparing planned with actual costs is a necessary duty we carry out on a regular basis to ensure we are not exceeding the approved budget.
Structure & Format: The table format is the ideal structure for all things finance. That’s why you’ll see Excel as the dominant tool for project cost planning and tracking. We usually start by building a planner with the timeline across columns. As with the schedule, you need to decide on the level of granularity: Do you want to plan and track costs on a weekly or monthly level? In my case, the monthly format has been most effective, since I also do the resource planning on a per-month basis.
Another point to consider is the desired cost breakdown.
At the minimum, you want to separate costs by category:
- Resource cost
- Material cost
- Travel expenses
- Admin expenses
- etc.
But you may need to break down costs further: Your sponsor or other stakeholders may want to review cost performance not just for the project as a whole, but on a more detailed level, such as individual project phases or for particular deliverables. Your project budgeting workbook needs to be set up accordingly so that you can pull out the required figures without much effort.
Here is a screenshot of the project budget template I built for myself. I like to show planned and actual costs side by side so I immediately spot any deviations:
Necessary details:
What details should your project budget contain?
- Planned cost & expenses for the project (your original budget)
- Actual costs & expenses, tracked on a continuous basis
- Estimated and actual workload (if you want to keep it in the same sheet, as I do)
How to create a budget:
The project budget is usually the next document you build after you’ve finalized the schedule. The budget is based on the content of the schedule, in particular the nature and duration of project tasks.
When building your schedule, you’ll also estimate the effort for each activity. The resource effort is one of the key components of the budget.
Add other relevant items such as travel expenses or the cost of project-related materials.
Document #3: Project Communication Plan
Purpose: Why do we create a create a communication plan? Here’s the thing: We all agree that communication is critical for a successful project outcome. But the reality is we don’t communicate or engage with our stakeholders enough because we are too busy, fearful of being criticized, too shy to pick up the phone and a million other reasons. But if communication is ignored, the project will suffer. A project communication plan is a ridiculously simple, but insanely effective solution to fix communication in a project environment.
A communication plan lays out how the team will communicate throughout a project.
In particular, this means:
- The type and frequency of meetings that will be held to share relevant information with the team and stakeholders
- Progress updates shared via email and other channels
Apart from facilitating communication with the project participants, another important function of a communication plan is to define an escalation process. The escalation process is activated when the project team is stuck with issues or decisions that cannot be resolved on a project level, and which require management intervention.
Structure & Format: There is no particular format for a communication plan. You can simply outline your communication approach in an email using a few bullet points, and share with your stakeholders. Or you can use any of the Word templates available on the web. Personally, I prefer the tabular layout, as shown in the following screenshot.
This is the template I use:
Take a look at the above example. This is what a communication plan can look like – very simple.
Necessary details:
Include the following points:
- Meeting plan (including purpose of meeting, participants, frequency)
- Planned cycle of progress updates via email and other channels
How to create a communication plan: Basically, you talk to your various stakeholders, such as your sponsor, the steering committee, your project team and the leadership team and agree on a suitable meeting plan. For people who are too busy (or too important) to join your update meetings, you keep them up-to-date via regular email updates.
Document #4: Risk Log
Purpose: Remember what I said earlier, about the documentation part in projects actually serving us as project managers because the process requires us to critically think through each aspect of the project. The risk log (or risk register) is a great example of that.
The document requires us to evaluate the risks that could jeopardize our project and take suitable measures to avoid or mitigate those risks – right from the start.
I recall the risk log inspiring very fruitful discussions inside our project leadership team. It forced us to face reality and look at the potential pitfalls we could run into. Based on that we planned precautionary measures that kept us in safe waters. Had we been as risk-conscious had we not done a risk assessment by completing a risk log? Probably not. The outcome of my projects would have been very different, and probably I would be teaching project management to you here 🙂
Structure & Format: The format of the risk log is pretty much standardized.
Here is a screenshot:
In case you cannot see all the columns:
- Risk ID
- Description of risk
- Risk category
- Impact
- Probability
- Overall risk value
- Mitigating actions
- Responsible (risk owner)
- Due date for mitigating actions
Necessary details:
See the columns above, this is what goes into a risk log
How to create a risk log:
The risk log is completed collaboratively with your team, sponsor and key stakeholders. Invite them for a 1-2 hour risk assessment meeting where you review your project from a risk angle. What are the crucial risks? And how can those be dealt with? Record your results in the risk log and don’t forget to define concrete action steps with a due date.
Risk assessments should be re-performed in regular intervals, because the risk situation may have changed as the project has advanced. Therefore, the risk log is a living document that should be regularly updated.
Document #5: To-Do List
You need to have a good system for keeping track of open tasks and issues, otherwise you’ll soon be wrestling with piles of incomplete work and have to declare project delay.
Whether it’s project tasks, deliverables, admin stuff, communication or leadership tasks, track everything meticulously in your to-do list as if your life depended on it.
The to-do list isn’t a document in the same sense as the others discussed here, but it’s such an important element that I wanted to mention it here.
There are tons of options for managing action items:
- Use any of the popular apps as Asana, Trello, Monday.com, Clickup or Microsoft Tasks, that integrates with Teams. Just pick whatever you find most convenient to use.
- Use Microsoft OneNote for tasks (link)
- Create your own action tracker in Excel
- Grab a template from the web
- Use Outlook tasks
- Use a paper notepad, post-it notes, or whatever you prefer!
I’m using a combination of Excel, a paper-based to-do list and Post-it notes that I stick to my desk. In addition, I will occasionally send myself high-priority tasks to my inbox so I don’t miss them – this is my way of beating procrastination!
Document #6: Project Charter
Purpose: A Project Charter is like an official contract that hosts all the key information about the project we have prepared in the other documents: the project scope, schedule, budget, team setup and other pieces of information.
Rather than having your sponsor pull together all pieces one by one by going through each document, we combine all essential project parameters in a single document – the project charter.
It is common to have the charter signed by the sponsor, representing the formal approval for the team to start working.
Structure & Format:
Most commonly a Word document with the following chapters:
- Executive summary
- Project goal
- Scope
- Timeline
- Project team
- Cost
- Risk
For a real-life project, we may have to add a few more chapters. Read my article about creating a project charter if you want to know more.
Necessary details:
Include all facts about a project that the client or sponsor has to know so they understand what they are getting themselves into. In particular, include the scope, cost, timeline, team setup and responsibilities as well as key risks.
Just complete the sections of a project charter template and you’ll have taken care of the key points.
How to create a project charter:
The project charter is usually the document that you finalize last, because its content basically is a summary of the information from the other documents you’ve prepared, such as the schedule, budget, risk log etc. Once you have completed those docs, you simply take a screenshot of the relevant information and paste it into the charter, along with some comments to provide context. That’s how I do it.
Document #7: Project Org Chart
Purpose: Making a Project Org Chart can really help you. It’s important for everyone on the team to know each other and who’s in charge of what. With an org chart, it’s easy for team members to figure out who’s responsible for a particular area. This makes it clear who to talk to about specific issues. It’s like having a map of the team. And for you as the project leader, it means you don’t have to spend time telling people who to talk to. Team members can just find the right person in the org chart, making things run smoother.
Structure & Format:
Voilà, here is an example of an org chart I built in PowerPoint:
PowerPoint is the easiest way to build an org chart fast.
Necessary details:
Make sure to show also people’s role – not just their name.
Double-check to make sure you have every contributor and stakeholder on the chart and nobody is missing. People can get upset when they can’t find their name on the chart when they actually were told they have a role in the project.
How to create a project org chart:
You assemble a team for your project, and you identify all the key stakeholders that will have a say in the project. These people form your core and extended project team. The project org chart is simply a visual representation of your team structure.
Document #8: Roles and Responsibilities Overview
Purpose:
Clearly defining roles and responsibilities in a project is good for several reasons. Firstly, people tend to forget verbal agreements, especially when it comes to duties they may not naturally enjoy. For instance, a programmer who dislikes communication may quickly forget their responsibility to liaise with members from the functional side. Secondly, without clear documentation of responsibilities, tasks can easily fall through the cracks, because nobody feels responsible for them. This only leads to stress and frustration within the project team, and it’s a huge distraction when a project is already in full swing.
Structure & Format:
No particular structure.
I like to describe the project roles in a PowerPoint presentation, listing the specific responsibilities and duties for each role. I then show the slides to my team during the kick-off meeting, and we go over the tasks again.
Here’s an example for you:
Necessary details:
Descriptions of project roles along with specific responsibilities for each role.
How to create a roles and responsibilities overview:
Define the necessary project roles (project roles are like regular job roles …., but specific to a project)
Determine the specific responsibilities needed for each role to ensure tasks are executed to the desired standard.
I’ve written a separate article about defining roles and responsibilities. Go check it out.
Document #9: Stakeholder Matrix
Purpose:
Imagine being handed a project, and your boss gives you a list of stakeholders to involve. You take the list and get to work. You don’t question the overview because you’re under time pressure and need to move quickly. Everything goes according to plan in the first three months. However, by the fourth month, there are murmurs that not all requirements were considered. Some areas were overlooked, although it becomes clear that they are affected by your project. In the fourth month, things start to heat up. Explosive emails start circulating circulating: “Why didn’t you talk to us?” A handful of other departments demand involvement in the project. You discuss their requirements. And suddenly, the project scope explodes. The timeline falls apart. Everything needs to be renegotiated, and costs skyrocket.
Unfortunately, too many projects end up in this situation.
To prevent this from happening to you, please conduct a thorough stakeholder analysis. My other article will show you exactly how to identify the stakeholders for your project.
You’ll document the findings – a summary of the relevant stakeholders – in a stakeholder matrix (also referred to as a stakeholder register).
Structure & Format:
A stakeholder matrix typically looks like this:
As you can see, it’s not just about knowing who the stakeholders are. It’s about figuring out their relationship to the project and how to best involve them. Once you’re in conversation with your stakeholders, you’ve overcome the biggest hurdle. That’s great. Next, meet with each of them to discuss expectations and specific tasks in the project.
Necessary details:
At the minimum, a stakeholder matrix should show all relevant stakeholders, including their relationship to the project and a plan for engagement.
How to create a stakeholder matrix:
Consider which people or organizational entities have a connection to your project: They may contribute to it, be impacted by its outcomes or hold the authority to approve specific deliverables or actions.
Document #10: Scope Statement
Purpose:
Scope?! This term causes a lot of confusion because it’s such a conceptual term. Just last week, I explained the meaning of ‘scope’ to one of my coaching clients. Read my article What is Project Scope? if you’re not yet fully comfortable with this term. In a nutshell, project scope is what we intend to build, do, or change as part of our project.
The scope statement serves to precisely describe the project scope in words. This way, the customer knows what they’re getting, and the contractor or project manager knows what needs to be done. An important aspect when defining the scope, which is often overlooked, is also outlining the responsibilities involved: clarifying what the project team (contractor) is responsible for and identifying parts that the client manages independently.
Structure & Format:
The scope is typically described in free text format in a Word or PowerPoint document.
Here’s a scope definition example:
The scope definition usually doesn’t exceed half a page. We’re just summarizing the main parts of the project, usually in a few bullet points.
Essential Details:
The scope statement describes the project’s main task, including any additional tasks to be addressed during execution.
How to prepare a scope statement:
You define the scope in conversation with your customer. You clarify what the customer wants exactly. What is the desired outcome? What is the desired change or transformation? From there, you can determine what the project needs to do. And that, precisely, is the scope, my friend.
Document #11: Change Log
Purpose:
In an ideal scenario, we’d hash out the requirements with the client at the project start and then passionately dedicate ourselves to bringing the client’s vision to life until the masterpiece is complete. Unfortunately, reality is different.
As the project progresses, even after the scope has been finalized, additional requirements often emerge. This is quite normal in complex endeavors, and I won’t delve into the reasons here. As project managers, we need a system to track these changes to the project scope. After all, they often lead to additional costs. And we want to clearly distinguish these additional costs from the original budget. So, if the client ever grumbles about the costs, we can say, “Look, originally you wanted four entrance doors for your villa. But then, last month, you also insisted on an additional backdoor to slip away unnoticed when your in-laws approach. And that extra door ended up costing an extra $4000. That’s why we’ve ended up with these final costs” (to give an example from the construction world).
Such changes to the project scope that occur after the project has been approved are called Change Requests. And we track these in a Change Log. This way, as project managers, we don’t have to justify ourselves if the project ends up costing more than planned, even though we did a good job. We simply point the client to the change requests and provide a breakdown of the additional expense.
Here, it’s important to note that every change to the scope (and thus every change request) must be approved by the customer. Don’t start executing unless you have their signature.
Structure & Format:
A simple spreadsheet like the one below serves great as a change log:
Essential details:
Make sure your change log contains the following details:
- Description of change
- Requester (who requested the change)
- Justification
- Estimated cost
How to create a change log:
Changes are recorded in the change log as they arise during the project. Talk to the person requesting the changes for the needed details.
Now we’ve covered all important project documents
These are the docs you should create at the beginning of your project, no matter what kind of project you’re managing. By pulling together the content mentioned, you’re automatically ensuring you’ve covered all the critical areas. And trust me, that level of confidence is priceless!
If your boss thinks everything’s already sorted for the project, that you can skip the whole circus with the documents and dive straight into implementation, then that’s a big red flag. Most likely, nothing is clear, and your boss is under so much pressure that their brain has shut down.
Guess why I’m bringing this up? I’ve been there myself, where my boss, a real smooth talker and persuasion master, maneuvered me into this situation. And as a young, dumb employee, I didn’t see the game that was being played. That’s how you learn 🙂
What’s the best order to create the documents?
When starting a new project, you often find yourself working on multiple documents at the same time. This is because the information in these documents is interconnected. For instance, making a change to the schedule may impact the budget, because prices for goods or services may vary depending on the time of the year.
I tend to follow this order:
- Create to-do list
- Stakeholder Matrix
- Roles and Responsibilities Overview
- Project Org Chart
- Scope Statement
- Project Schedule
- Budget
- Communication Plan
- Risk Log
- Project Charter
- Change Log
What’s nice about this order is that the results from one document feed into the next. This gives you a roadmap for setting up your project.
One more thing.
When you get a new project, it can feel really intimidating at first.
You have to deliver, but you don’t have any plan yet on how to approach the project.
How to structure it.
What needs to be done.
Who you need to involve.
And so on.
The beginning is always overwhelming, and you might have some restless nights.
That’s completely normal.
But as soon as you tackle each topic – clarify the scope, determine the stakeholders, develop a schedule, etc. – you’ll soon have much more clarity.
The process of putting together these documents stimulates your creativity. Before you know it, you have a thousand great ideas on how to approach your project.
You realize which questions still need to be answered, who you need to talk to, where you can get help from and so on. And you see where the project’s particular risks lie.
That’s exactly how I’ve always experienced it.
That’s precisely why I find working with project documents so incredibly useful. It’s a highly stimulating process, and in the end, it all clicks, and you have a well-structured and well-thought-out project.
That’s all for now.
I sincerely hope you found this article helpful to you and I was able to shed some light on a confusing topic. If you have any questions regarding project documentation, just drop me a message here:
Got A Question? Need Some Help?
Have a question about this article? Need some assistance with this topic (or anything else)? Send it in and I’ll get back to you personally.
If you’re looking for good document templates, check out my Project Template Pack! It includes the exact documents shown in this article – plus many more! With it, you’ll get a complete collection of the documents that have allowed me to successfully deliver even the most demanding projects.
