A project status report tells the people who fund and steer a project whether it will land on time and on budget, and what they need to do about it. It is read by a sponsor, a steering group or a client, usually in the five minutes before a meeting. They want the answer first and the detail second, and they want to see the same layout every week so a change jumps out.
This template uses the common RAG format: red, amber or green for each area, an overall status, milestones, a risk and issue log, and a short list of decisions. The example above is week 6 of a fictional rollout of handheld scanners in four warehouses: on budget, two weeks late at one site, with one decision for the steering group.
What goes in each section
The headline
The overall status in one word and the reason in one line: "Overall amber: on budget, two weeks late at Reno." Under it, the date, who the report is for, the project lead and the date of the next report. Mistake to avoid: a headline that only says "Week 6 status". The reader should know the answer without scrolling.
01 · Status at a glance
Four big numbers (overall status, progress, budget spent, the forecast end date), then a table with one row per area: scope, schedule, budget, people, vendors. Each row gets a coloured status and one line of why. Below it, say what changed since the last report. Mistake to avoid: statuses with no reason. "Amber" alone starts a meeting; "amber, Wi-Fi dead zones in aisles 30 to 44, two weeks to fix" ends one.
02 · Milestones
A timeline with finished, current and late work, and a table of each milestone's planned date against its forecast. If the project has a number that shows it working, add a small chart: the example compares picks per hour on paper and on scanners per warehouse. Mistake to avoid: moving the plan dates quietly. Keep the original plan from the project brief and show the forecast next to it.
03 · Risks and issues
One table for both. An issue has already happened; a risk might. Give each an impact, an owner and whether it is contained. Five rows is plenty; keep the full register elsewhere if you need one. Mistake to avoid: a risk with no owner. Nobody acts on it until it becomes an issue.
04 · Decisions needed
The question, the options with their cost and effect on the date, and your recommendation. Then the plan for next week in three lines. Mistake to avoid: asking for a decision without a deadline. Say by when, and what happens if nobody decides.
How often, and how long
Weekly is the default; every two weeks suits long projects with slow change. For a team with ongoing work and no end date, a weekly update is lighter. It should take 20 to 30 minutes to update if you keep it as one living page and change only what moved. Readers should get through it in under five minutes. If yours runs longer, move detail to linked pages and keep the status, the milestones and the decisions on top.
How to use this template
- In Obsidian: install the free myone.page plugin, run New page from template and pick Project status report. Every field says what goes there.
- With AI: paste your notes, the tracker export and last week's report into ChatGPT or Claude with the prompt from myone.page/ai.
- By hand: copy the Markdown of the example above. It is a plain note.
Each week, duplicate last week's note or edit the same one. The milestone dates and the gantt bars are edited right on the page, so the timeline stays current without redrawing it.
Where myone.page helps
Status reports go stale when they live in a slide deck that one person updates. Shared as a link, the sponsor reads the same page each week, and workstream leads can edit their own rows in the browser without Obsidian; their edits come back into your note. If your company already runs projects in Jira, Asana or Smartsheet and the sponsor reads dashboards there, a status field in that tool may be enough. Use this page when you need the story and the decision, not just the bars.