How to Use Docmost for Project Management: A Documentation Guide

TL;DR

• Project management documentation is the set of documents that record a project from start to finish.
• Most projects need documents across five phases: initiation, planning, execution, monitoring, and closure.
• Every document needs an owner, an update schedule, and one place where the team can find it.
• Docmost holds the documents, while your tracker handles the schedule and day-to-day task tracking.

A director who joined the project late asks the room why the scope grew in week six. You know there was a reason, you were there. But the decision came out of a call, and the follow-up is somewhere in a chat thread, a ticket comment, or a recap email you're no longer sure anyone sent. So you scroll while the director (and probably the board) waits, and the longer it takes, the more it shows how unorganized your team is.

It's even worse when the person who made the call has moved on, and the reasoning went with them. Nobody wrote it down, so it's gone. Then the next project starts, and you spend the first morning hunting for the last charter, trying to piece together what the team decided last time. You're not doing anything wrong. It's just that when a team is busy delivering, nobody thinks to manage the documents properly.

Project management documentation fixes that by giving each of those answers a page before anyone asks. And this guide shows how, by following one small project from kickoff to closure: a team redesigning its company website, with a project lead, a designer, a developer, a content writer, and a sponsor from marketing. For each phase, you'll see the document the team writes, what goes in it, and the Docmost page that holds it. You'll also see how the pages link to each other, so the next "why did we do that?" has an answer on file.

The table below lists the core documents for each of the five phases and the question each one answers.

What Is Project Management Documentation?

Project management documentation is the written record of a project: the plans you made, the decisions you reached, where things stand, and how it all turned out. You'll also see it called project documentation, and the two terms mean the same thing here.

Good documentation does three things for your team:

• It gives the whole team one place to check, so nobody has to rely on what they remember from a meeting.
• It shows who owns what, including who owns each risk, who approved a change, and who's accountable for each deliverable.
• It keeps what the team knows when people leave, so a new team member can read the charter and the decision log instead of tracking down the person who moved to another project.

Project Documentation vs. Technical, Process, and User Documentation

Project documentation is one of four kinds of documentation a team keeps. The table below shows what each kind covers and who reads it.

Project Management Documents by Phase

The sections below explain what goes in each document, phase by phase.

Note that most documents aren't finished once you write them down. For example, you update a risk register every week, and further down you'll find a schedule for how often to update each document. If your project is small, you won't need every document, and the section on what to document will help you choose.

The website redesign examples below are made up for illustration.

The "Initiation Phase" Documents

Initiation is where the project gets its purpose and its decision makers. The documents here are short, and they're the ones people go back to when the project goes off course.

Project Charter

A project charter is the document that formally starts the project. It confirms the project exists and gives the project lead the authority to use the organization's people and money on it.

Your charter should include:

• Purpose and goal
• Scope and what's out of scope
• Sponsor and who makes decisions
• Key stakeholders
• High-level timeline and budget
• Success measures, constraints, and assumptions

In the website redesign, the goal will be to replace the current marketing site with a redesigned one that's easier to navigate.

Out of scope: rewriting the product documentation.

Sponsor: head of marketing.

Owner: the project lead. The sponsor helps write the charter and gives the final approval.

Business Case and Project Proposal

The business case explains why the project should go ahead. It usually covers the problem you're solving, the options you looked at (including doing nothing), the pros, cons, and cost of each option, and the one you recommend. A project proposal does a similar job when you're trying to win support for the project in the first place.

Stakeholder Register

A stakeholder register lists everyone with a stake in the project. For each person, write down:

• Their name
• Their role
• How interested they are in the project
• How much influence they have
• How and how often they want to hear from you

Check it before you send an update so the right people get it.

The "Planning Phase" Documents

Planning turns the charter into something the team can work from. These documents define the work, who does it, and what could get in the way.

Scope Statement and Statement of Work

A scope statement explains what the project will and won't do. It lists the deliverables, what's in scope, what's out, your assumptions, and the acceptance criteria that tell you when a deliverable is done. When someone asks for something new halfway through, this is the page you look at to see if the request is part of the project.

For the redesign, one acceptance criterion is that the sponsor has approved every website page before launch.

A statement of work is a formal agreement you use when people outside your organization are involved, such as a contractor. It sets out the scope, the deliverables, the timeline, and who's responsible for what before any work starts.

If your project starts from product requirements, see our guide on how to write a requirements document.

Project Plan, Schedule, and Work Breakdown Structure

Three related documents describe how the work will get done:

• The project plan combines your smaller plans into one document, covering areas like scope, schedule, cost, communication, and risk.
• The schedule sets the planned start and finish dates for tasks and milestones.
• The work breakdown structure breaks the project's scope into smaller pieces that are easier to manage.

Keep the detailed schedule in your tracker and link to it from the plan page. That way there's only one version of the start and end dates.

Communication Plan

A communication plan lists who gets which updates, how often, and where. It can be as simple as a table like this one:

Risk Register

The risk register is where you list what could go wrong before it does. For each risk, write down a short description, how likely it is, how big the impact would be, the owner, your planned response, and the current status.

Here's a risk the website redesign team logs early on:

Owner: the project lead keeps the register, and each risk has its own named owner who watches it and acts on it.

RACI Matrix

A RACI matrix is a table that shows who is Responsible, Accountable, Consulted, and Informed for each task or deliverable. Tasks go down the side, people or roles go across the top, and each cell gets one letter. R means Responsible (does the work), A means Accountable (does the final review before the work counts as done), C means Consulted (gives input), and I means Informed (is kept up to date).

Here's the website redesign team's version:

Each row has exactly one A. The sponsor is Accountable for design approval, and the project lead is Accountable for everything else. Also, make a note to update the matrix whenever roles change.

The "Execution and Monitoring Phase" Documents

Once work starts, documentation shifts from planning to recording. These documents show how the project is going and what's changed since the plan was written. Monitoring means keeping the risk register, schedule, and budget up to date as the work goes.

Project Status Report

A status report is a regular update for your sponsor and stakeholders. It sums up:

• Progress against the plan
• What's done and what's coming next
• Risks and issues
• Budget and schedule
• Decisions or changes

Many teams also give the whole project a color, such as green for on track, yellow for a warning, and red for a problem. Keep the report short, and agree with your sponsor on what goes in it.

A redesign status report might read:

Overall status: Yellow Progress: Designs are approved and development has started. Next: Build the remaining pages. Risks and issues: Page copy is late. Decision needed: The sponsor decides whether to add a review round.

Owner: the project lead writes it, and the sponsor may sign off on it.

Issue Log

The issue log is where you track problems that are already affecting the project. For each issue, write down what happened, the impact, the owner, the plan to fix it, the date it needs to be fixed by, and the status.

The difference between a risk and an issue is timing. A risk might happen, and an issue already has. When a risk comes true, move it from the risk register to the issue log and give it an owner.

For example, say the page copy for the website redesign arrives late. The project lead moves the risk from the register to the issue log, names the content writer as the owner, sets a new copy deadline, and notes what the delay does to the launch.

Change Request Log

A change request is a formal ask to change the plan, such as the scope, budget, or schedule. The change request log keeps every request in one place: what's being asked for, who asked, how it affects scope, budget, and schedule, the decision, and the date. Each approved change ties back to the scope statement, so you can see how the project grew from what the charter first described.

For example, in week six, the sponsor asks for a blog section. The project lead then logs the request and notes that it adds pages and delays the launch. The sponsor approves it, and that decision goes in the decision log below.

Decision Log

A decision log records each key decision, who made it, who was consulted, when it was made, and why. Include the reason every time, since that's what someone looking back will need. Our guide on how to document product decisions has an entry template you can copy.

The blog section decision looks like this:

That one row answers the director's question from the start of this guide, about why the scope grew in week six. The decision, who made it, and the reason are all in one place.

The "Closure Phase" Documents

Closure documents wrap up the project and make sure what the team learned stays with the organization.

Project Closure Report

The closure report is the formal end of the project. It compares what the project delivered with what the charter said it would do. It should cover:

• How the project's results compare with the plan
• Final deliverables and whether they were accepted
• Lessons learned
• Recommendations for future projects
• Handoff notes for whoever takes over
• The sponsor's sign-off

Once the project is done, you can export its whole space from Docmost as Markdown or HTML, with or without attachments. It downloads as a ZIP file. The import and export guide has the steps.

Postmortem and Lessons Learned

A postmortem looks back at what happened and why. Write a short summary, a timeline of key events, what went well, what went wrong, and action items, each with an owner.

The redesign team's short version: what went well was that the RACI settled who approves design. What went wrong was that copy arrived late. The action item is to agree copy deadlines at kickoff, owned by the project lead.

Lessons only help if the next team can find them, so keep them somewhere people search across projects instead of burying them in one project's pages. See how to keep lessons learned findable across projects.

What Should You Document in a Project?

You don't need to write everything down, but some things always belong in a document:

• Decisions made with a client or sponsor
• Anything a legal or compliance team may need to review
• Changes to scope, budget, or schedule
• Steps the team will repeat

Skip one-off messages and notes nobody will look at again.

How Much Detail Each Audience Needs

The same project needs different levels of detail for different readers. Executives want the overall result, but your team wants the specifics.

How Often to Update Project Documents

Documents go out of date fast once a project gets busy. But a simple schedule can keep each one current:

The easiest way to stick to this is to update documents during meetings. If you have a weekly status meeting, update the risk register and issue log in that meeting instead of afterward.

How to Organize Project Management Documentation in Docmost

Docmost is a wiki, so each document becomes a page your whole team can read and edit together. The setup below keeps every document in one predictable place.

How to Set Up Pages by Phase

Give each project its own space in Docmost. A space keeps a project's pages, people, and permissions together. If you haven't created one yet, follow our guide to set up a project wiki for your team.

Inside the space, create a parent page for each phase and put the documents under it as subpages. The redesign space looks like this:

Website Redesign

├── 1 Initiation

│   ├── Project Charter

│   └── Stakeholder Register

├── 2 Planning

│   ├── Scope Statement

│   ├── Communication Plan

│   ├── Risk Register

│   └── RACI Matrix

├── 3 Execution

│   ├── Status Reports

│   ├── Issue Log

│   ├── Change Request Log

│   └── Decision Log

└── 4 Closure

    ├── Closure Report

    └── Postmortem

Anyone who joins the project can easily open the space and find a document by its phase. If the structure needs to change later, you can drag and drop pages in the sidebar.

Which Docmost Features Fit Each Document

Each document type matches a Docmost feature. Some of them work in the free edition, while some need the paid edition.

Templates let you save a layout once, so every new status report starts with the same sections.

A base turns a table into a small database. Its Kanban view groups rows into columns by a Select or Status property, and you drag a card to change its status, which works well for a risk register. A Person property lets you add people to a cell, which suits a RACI matrix.

Synced blocks let you reuse the same block on several pages. Put the project summary in one, add it to each status report, and you only have to edit it once. A status badge, which you add from the slash menu, shows a custom status on the page, such as on track or at risk.

Mermaid is a diagram tool built into the editor. You type a short text description, and it draws the chart as you type, including a Gantt chart for project timelines.

Where Docmost Fits Next to Your Tracker

Docmost holds the documents that explain your project, but it isn't built for scheduling or resource planning, so keep those in the tracker your team already uses.

You can still connect the two. Once an admin installs an integration for your tracker, you can paste a ticket link into a page and show it as a card or a mention. Each person connects their own account to see the preview. To set this up, see how to keep project documentation beside your tracker.

Project Management Documentation Best Practices

Link Project Documents Together

Your documents work best when they point to each other. Link each status report to the risk register and the charter, and link approved change requests to the scope statement. Type @ in the editor, then search for the page you want to link.

In the redesign space, the status report links to the risk register, the issue log links back to the risk it came from, and the blog section decision links to its change request and the scope statement.

The Details panel (ⓘ) at the top of each page lists its backlinks, so you can see every page that links to it. Before you change the charter, check which pages point to it. For more on this, see how to link wiki pages together.

Assign Owners and Review Dates

Every document needs one owner, named at the top of the page, so readers know who keeps it accurate. Docmost's page menu shows who created a page and when, but the creator isn't always the owner, so write the owner's name on the page itself. Add a "last reviewed" date next to it and update the date whenever the owner checks the page.

On the Enterprise edition, page verification lets you assign verifiers to a page and set a fixed or repeating review date. Docmost doesn't have a reminder for review dates, so build reviews into the update schedule above and book a recurring slot in the team calendar to check which pages are due. Our guide on how to assign page owners and review dates covers how to pick owners and set review dates.

Use Version History to Track Changes

Docmost saves a version history of each page automatically as people edit, and it calls this page history. Open it from the page menu, pick an earlier version to see a highlighted comparison with the current page, and click Restore to bring that version back. That's useful when someone edits the charter or the scope statement and you need to see what it said before.

The comparison shows what changed, but not why. So, to record why it changed, add an entry to your change request log or decision log.

Name Pages the Same Way Every Time

Pick a naming pattern and stick to it. Something like "Status Report, Week Six" or "Risk Register, Website Redesign" makes a page easy to spot in the sidebar. It also helps in Docmost's search, which has a Title only option for searching page titles. Write the pattern down once so new team members can follow it too.

Reuse the Same Structure on Every Project

Use the same phase page tree for every project, so the next project doesn't start from a blank page and anyone moving between projects already knows where things are. Keep a blank copy of the tree on one parent page, then use Copy to space in the sidebar page menu to copy it, subpages included, into each new project's space. On the paid edition, you can also save each document as a template, so every new charter or status report starts with the same sections.

Free vs. Paid Edition for Project Documentation

You can build every document in this guide with the free edition. But the paid edition adds features that save time when you run many projects.

The page verification and review workflow in the Enterprise edition lets your team request reviews, track approvals, and mark pages as verified.

Frequently Asked Questions

1. What Documents Does a Project Need?

Most projects use a charter, a scope statement, a project plan, a risk register, a RACI matrix, status reports, an issue log, a change request log, a decision log, and a closure report. A business case, a stakeholder register, and a communication plan round out the set. Which ones you need depends on the size of the project, and the table at the top of this page groups them by phase.

2. How Often Should Project Documents Be Updated?

Update living documents like the risk register and issue log every week, and send status reports weekly or biweekly. Review the project plan monthly or at each milestone. Change the charter and scope statement only when a change is approved.

3. What Is the Difference Between a Risk Register and an Issue Log?

A risk register tracks problems that might happen, and an issue log tracks problems that already have. When a risk comes true, it moves from the register to the log so it gets an owner.

4. What Is the Difference Between a Project Charter and a Project Plan?

A project charter starts the project. It says what the project is, why it matters, and who has the authority to lead it. The project plan comes after it and explains how the work will get done, covering areas like scope, schedule, cost, communication, and risk. You also update them differently: change the charter only when a change is approved, and review the plan monthly or at each milestone.

5. Who Should Own Project Documentation?

The project lead owns the documentation as a whole and usually keeps the logs, such as the risk, issue, and decision logs. The sponsor approves the charter and signs off on the closure report. Each risk and issue also gets its own named owner.

6. Can I Build a RACI Matrix in the Free Edition of Docmost?

Yes. Build it as a table with tasks down the side and people across the top, then fill each cell with R, A, C, or I. The paid edition adds Bases if you'd like to filter and sort the matrix.

7. Can Docmost Replace a Project Tracker?

No. Docmost holds the documents that explain your project, such as the charter, the decisions, and the status reports. Your tracker handles scheduling and day-to-day task tracking. Paste ticket links into your Docmost pages so each document points to the work it describes.

8. Can Stakeholders Read Project Documents Without Editing Them?

Yes. Add them to the project's space with the Viewer role, and they can read the pages without being able to edit them. See how role-based access for wikis works for larger teams.

Keep Every Project Document in One Place With Docmost

Every document in this guide has a page, an owner, and links to the pages around it. Set that up for one project, and the next final review has its answers on file.

Docmost gives each project its own space for the charter, the decisions, the status reports, and the lessons learned. Get a free trial license or contact sales to set it up for your projects.