The Project Management Documents That Actually Earn Their Keep
Templates are cheap. Deciding which ones you need is the work.
Search for project management templates and you will find libraries of forty documents. Adopt them all and you will spend more time maintaining paperwork than delivering. Adopt none and you will rediscover, at some cost, why each was invented.
The honest position is in between and depends on one variable: how expensive is it if we are wrong, and how many people need to agree? A two-person internal tool needs a different pack from a fixed-price client build with a contractual deadline.
Key takeaways
- Three documents cover most projects: charter, RAID log, and a one-page status report.
- The charter's job is to prevent scope arguments by writing down what is out, not just what is in.
- A RAID log is the single highest-value artefact in day-to-day delivery — risks, assumptions, issues, decisions in one place.
- Decisions are the part everyone forgets to record, and the part most expensive to reconstruct six months later.
- Status reports should be one page, same shape every week. Variable formats hide trends.
Which pack for which project
| Project type | Minimum pack | Add if |
|---|---|---|
| Internal, one team, reversible | Charter (one page) + RAID | — |
| Client build, fixed price | Charter + RAID + status + change log | Contract references a specification |
| Multi-team, shared deadline | All of the above + dependency map | Two or more teams must sequence work |
| Regulated or safety-related | Full pack with traceability | Always |
| Discovery or research | Charter + decision log | The output is a recommendation |
The project charter
One page, written before work starts, agreed by whoever is paying. Its purpose is not ceremony — it is to make disagreement surface now rather than at delivery.
- Objective in one sentence, with a measurable outcome.
- In scope — the specific deliverables.
- Out of scope — explicitly, and this is the section that earns the document.
- Success criteria — how we will know it worked.
- Constraints — budget, deadline, technology, regulation.
- Roles — who decides, who delivers, who signs off.
- Key assumptions — the things that, if false, change the plan.
Write the out-of-scope list with the client in the room and make it specific. "Reporting is out of scope" is weak; "no custom report builder; the three named reports in appendix A only" prevents an argument in month three. Vague exclusions are the ones that get relitigated.
The RAID log
Risks, Assumptions, Issues, Decisions — one table, reviewed weekly. If you keep only one document beyond the charter, keep this.
Two disciplines make a RAID log work rather than decorate a folder:
- Every row has an owner and a date. Ownerless risks are observations.
- Review it weekly, in the same meeting, out loud. A log nobody reads is worse than none, because it creates a false sense that risk is managed.
The D is the part small teams skip and later miss most. Six months on, nobody remembers why you chose one payment provider over another, and the reasoning gets re-litigated from scratch. One line — decision, date, who, why, what was rejected — saves hours.
The one-page status report
| Section | Content | Why |
|---|---|---|
| Overall | Green / amber / red, with a one-line reason | Forces a judgement, not a narrative |
| Done this period | Completed, verifiable items | Progress, not activity |
| Next period | What will be done by the next report | Creates a checkable commitment |
| Risks and issues | Top three from the RAID log only | Escalation, not a data dump |
| Decisions needed | What you need from the reader, by when | The section that makes it worth reading |
| Budget / schedule | Planned vs actual | Trend beats snapshot |
Keep the shape identical every week. Consistent structure lets a reader spot a trend in ten seconds; a freeform update hides drift behind good writing.
Ban "amber for three consecutive reports" as a stable state. Amber means a decision is needed; if nothing changes for three weeks, either it is actually green and you are hedging, or it is red and nobody wants to say so.
Change control without bureaucracy
Every project changes. The failure is not change, it is undocumented change — where scope grows one small favour at a time and the deadline stays fixed. A change log with five columns is enough for most work:
- What is being changed, and who requested it
- Why — the business reason
- Impact on scope, schedule and cost, quantified even if roughly
- Decision: approved, rejected, deferred — and by whom
- Date
The discipline is not the form; it is the sentence "that is a change, let me note the impact and come back to you". Said early and pleasantly, it protects the relationship as much as the schedule.
Closure and lessons learned
Most projects end by fading out. A short closure document is worth an hour:
- What was delivered against what was agreed in the charter.
- Outstanding items and who owns each now.
- Handover — where the code, credentials, documentation and accounts live.
- What we would do differently, written honestly and kept short.
The handover section is the one clients value most and the one most often missing. It is also the clearest expression of the principle that the client should own everything at the end — the position we set out on why you own everything we build.
What you can safely skip
| Document | Skip when | Keep when |
|---|---|---|
| Work breakdown structure | Under about six weeks of work | Multiple teams with dependencies |
| Communications plan | Fewer than ten stakeholders | Large or political programmes |
| Detailed Gantt chart | Scope is expected to change | Fixed scope with hard external dates |
| Stakeholder matrix | You can name everyone from memory | You cannot |
| Quality management plan | Definition of done covers it | Regulated or safety-related |
| Benefits realisation plan | Benefit is obvious and immediate | Business case funded on projected savings |
The test for any template: if we did not write this, what decision would be made worse? If you cannot answer, do not write it.
Frequently asked questions
What is the minimum documentation for a small project?
A one-page charter and a RAID log. The charter stops scope arguments because it records what is explicitly out, and the RAID log keeps risks and decisions visible while they are still cheap to act on. Add a weekly one-page status report as soon as someone outside the delivery team needs to know how it is going — which in client work is immediately.
Do agile projects need a charter?
Yes, and it is arguably more useful there. Agile changes how scope is delivered, not whether people agree on the objective, the budget and what is out of scope. A one-page charter answers questions a backlog cannot: why this project exists, what success looks like, and who decides. The backlog then handles sequencing within those boundaries.
What is the difference between a risk and an issue?
A risk might happen; an issue already has. The distinction matters because they need different handling: risks get an owner, a likelihood and a mitigation, while issues get an owner and a resolution date. Logs that blur the two tend to fill with issues nobody is actively resolving, which is how a RAID log becomes a diary rather than a management tool.
How detailed should a decision log entry be?
One or two lines: what was decided, when, by whom, why, and what alternative was rejected. That last element carries most of the value — six months later the useful question is rarely "what did we choose" but "did we consider X?", and being able to answer it in seconds prevents the whole discussion happening again. Anything longer will not get written.
Should the client see the RAID log?
Usually yes, with judgement about internal delivery risks that are yours to manage rather than theirs to worry about. Shared visibility of risks and assumptions builds trust and, more practically, surfaces the assumptions only the client can confirm — which is where the expensive surprises hide. Keep commercial and staffing risks in a separate internal view.
Sources
- Project Management Institute, PMI standards and resources — source of the charter, change control and closure practices adapted here.
- ISO, ISO 21500 — guidance on project management — international guidance on project processes and governance.
Keep reading
All articles →
What an Hour of Your Time Actually Costs (and Why It's Not Salary ÷ 2,080)
Most freelancers price against a number they got by dividing a salary by 2,080 hours. That number ignores business costs, tax, and the fact that you cannot bill eight hours of an e
Aug 13, 2026 · 11 min read
How Small Businesses Compete with Tech Giants
How Small Businesses Compete with Tech Giants (Without Spending Like One) It’s easy to look at tech giants and assume they win because they have bigger budgets,...
Apr 17, 2026 · 9 min read
Hybrid Workplace Technology
Hybrid Workplace Technology: The Digital Transformation Advantage for Modern Businesses Hybrid work is no longer an experiment—it’s a durable operating model. B...
Feb 13, 2026 · 12 min read