Search “project status report template” and you get the same thing forty different ways: a slide deck with six colored dashboards, a spreadsheet with twelve tabs, or a form built for a program office with its own PMO analyst. None of it fits a five-person team that needs a status update a stakeholder can read in ninety seconds, not a report that takes an hour to fill in and another hour to read.
This guide gives you the one-page project status report template a small team can actually keep up with: six fields, a worked example with real numbers, and the two things most templates leave out that cause the most confusion later.
What a project status report actually does
A project status report is a short, recurring update that tells stakeholders three things: where the project stands against the plan, what changed since the last update, and what needs their attention now. It is not a project plan, a task list, or a meeting transcript. Those documents answer what the work is, while a status report answers how the work is going.
Skip the status report and stakeholders find out about a slipping deadline the week it slips, instead of three weeks earlier when there was still time to react. Send one every week instead, and the same slip shows up as a one-line flag two reporting cycles before it becomes a crisis. A status report is one piece of the operating system that keeps a project visible; our business systems guide covers the other seven pieces that work alongside it.
Not every project needs one. A single founder shipping a two-week project does not need a weekly report, since the founder is the only stakeholder. If you have not scoped the project yet, there is no status to report in the first place: our project plan template covers the six steps that come before this one. A status report earns its place once more than one person depends on the outcome and the work runs longer than a few weeks, because that is roughly when a silent delay stops being obvious to everyone who needs to know about it.
The one-page status report format
Six fields cover what a status report needs to do its job. Skip one and a reader has to ask a follow-up question, which defeats the purpose of writing the report in the first place.
| Field | What goes in it |
|---|---|
| Project and period | The project name and the exact date range this report covers, not just “this week.” A reader opening it later needs the dates spelled out. |
| Overall status | One label: on track, at risk, or off track. Set this before writing anything else, and let the rest of the report explain why. |
| Accomplishments this period | Two to four things that finished since the last report, not what is almost done. Started work belongs in next steps, not here. |
| Blockers and risks | What is slowing the project, who needs to act on it, and by when. A blocker with no owner and no date is just a complaint. |
| Next steps | What happens before the next report, with one name attached to each item. An unowned task will not get done by the next update. |
| Budget and schedule variance | One line each: planned versus actual spend, and planned versus actual pace. Skip this field only if the project does not track a budget. |
A worked example: homepage redesign, week four of six
Here is how the six fields look filled in for a small agency redesigning a client homepage. Use it as a reference, then replace the content with your own project.
| Field | What it says |
|---|---|
| Project and period | Homepage Redesign, week 4 of 6 (October 1 to 7) |
| Overall status | At risk: two days behind on one sign-off, budget on pace |
| Accomplishments this period | Wireframes approved by the client; copy finished for all 5 pages; staging environment set up and tested |
| Blockers and risks | Client has not approved the final color palette. Design lead cannot start the homepage build without that sign-off. Owner: client contact, due October 9 |
| Next steps | Finalize color palette (client, October 9); build homepage template (design lead, October 14); start mobile QA (developer, October 16) |
| Budget and schedule variance | Spent $11,200 of an $18,000 budget through week 4: 62 percent of the budget against 67 percent of the schedule elapsed |
The percentages matter more than the raw numbers. Through week four of six, the project has used 67 percent of the schedule and 62 percent of the budget, so spending is running slightly ahead of schedule progress even though the overall status reads at risk. That gap is worth stating out loud, because a reader who only sees “at risk” will assume money trouble unless the report tells them otherwise.
How to fill it in under ten minutes
- Pull three or four finished items, not almost-finished ones. Two minutes. If a task is not done, it goes in next steps instead.
- Set the overall status before writing anything else. One minute. On track, at risk, or off track, decided first so the rest of the report has to justify it.
- List blockers with an owner and a date. Three minutes. A blocker without both is a complaint, not a status update.
- Write next steps with one name on each line. Two minutes. An unowned step is the first thing that slips before the following report.
- Check the variance line against the plan. Two minutes. Skip this step entirely if the project does not track a budget or a fixed schedule.
Common mistakes that make a status report useless
- Reporting activity instead of outcomes. “Worked on the homepage” tells a reader nothing. “Wireframes approved” tells them exactly where the project stands.
- Marking everything on track to avoid a hard conversation. The first time a stakeholder discovers a problem that three reports called on track, every future on track status loses its meaning.
- Listing a blocker with no owner and no date. “Waiting on the client” is not a blocker a reader can act on. “Waiting on the client, due Thursday” is.
- Skipping the report during a slow week. A quiet week is still information. A report that goes silent is the first thing readers stop trusting.
- Changing the format every time. Readers learn where to look for the status line. Move it, rename it, or drop a field, and every report costs more of their attention than the last.
Status report versus progress report: what differs
The two documents answer different questions, and treating them as interchangeable is why some founders skip the short weekly version and jump straight to a long monthly one that arrives too late to help.
| Document | Covers | Frequency | Written for |
|---|---|---|---|
| Status report | Where the project stands right now, including blockers | Weekly or every two weeks | Everyone with a stake in the outcome |
| Progress report | A full stretch of completed work and results | Monthly or at a milestone | Leadership, a funder, or a client needing a formal record |
Who should get it and how often
Weekly works for most active small-team projects: a week is long enough to show real movement but short enough to catch a slipping deadline before it turns into a crisis. Slower projects can move to every two weeks, and work tied to a few fixed milestones can report only at each milestone instead of on a fixed calendar.
Pair the written report with a short weekly checkpoint rather than a long status meeting. Our team meeting agenda template covers a standup format built to stay under ten minutes, which is usually enough once the written report has already done the heavy lifting.
If your team is tracking several projects at once and copying this table into a document every week feels like overhead, that is usually the sign to move status tracking into a tool instead of a page. Our guide to choosing project management software covers a five-question filter for picking one without paying for features a five-person team will never use. A dedicated project risk register template covers the fuller picture once a project has more than a couple of open threats to track.
Frequently asked questions
What should a project status report include?
A project status report should include six fields: the project name and reporting period, the overall status (on track, at risk, or off track), what finished since the last report, current blockers with an owner and a date, next steps with an owner attached, and a one-line budget and schedule variance when the project tracks both.
How often should a project send a status report?
Weekly works for most active small-team projects, since a week is long enough to show real progress but short enough to catch a slipping deadline before it becomes a crisis. Slower projects can move to every two weeks, and projects tied to a few fixed milestones can report only at each milestone instead of on a fixed schedule.
What is the difference between a status report and a progress report?
A status report is short and frequent: it covers where the project stands right now, including blockers, and goes out weekly or every two weeks to everyone with a stake in the outcome. A progress report is longer and less frequent: it covers a full stretch of completed work for leadership, a funder, or a client who needs a formal record rather than a quick weekly update.
What does an at risk status actually mean?
An at risk status means the project will likely miss a date or a budget line unless something changes this week, but the team still has a path to recover without help from outside the project. Off track means that path no longer exists without added budget, added time, or a change in scope, and someone above the project owner needs to make that call.
Who should receive a project status report?
Send it to everyone with a stake in the outcome: the project sponsor who owns the budget, the core team doing the work, and any client or stakeholder who was promised updates when the project started. Leave out people who only need the final result, since a weekly report they never asked for just adds noise they will eventually stop reading.
The bottom line
A project status report is not busywork. It is the one page that lets a stakeholder spot a slipping deadline two weeks before it turns into a crisis instead of finding out the week it happens. Fill in the six fields, set the status before writing anything else, and send it on the same day every week so readers know exactly when to expect it.
