A project status report is a short, regular update that tells everyone involved where a project stands, what is in the way and what happens next. For a small team juggling several client projects, a good one can cut down on ad hoc “quick check-in” emails by putting the answers on a single page. This guide gives you a one-page template, a simple way to set the status colour, and a worked example you can adapt.
Who this guide is for
This guide is for small business owners, studio founders and small-team leads who need to keep clients, partners or their own team informed without spending half a day on reporting. It suits design studios, agencies and service businesses running projects that last a few weeks or longer.
What a project status report is (and is not)
Atlassian’s guide to status reports describes a project status report as a concise, timely update on progress that gives stakeholders the essentials: the current state, obstacles and next steps. It is not a full activity log, and it is not a place to list every task completed. Think of it as a snapshot that lets a busy reader decide in a minute or two whether they need to act.
A useful status report answers four questions:
- Are we on track?
- What did we finish since the last report?
- What is blocking us, and what do we need from you?
- What happens next, and who owns it?
Know your audience before you write
An Atlassian article on writing status reports lists typical audiences such as the project team, leadership, the client and other teams you collaborate with, and suggests considering separate reports for internal and external readers. For a small business, that usually comes down to two versions:
| Audience | What they care about | What to leave out |
|---|---|---|
| Client | Progress against agreed milestones, decisions they need to make, anything that affects the launch date | Internal workload discussions, tool details, who was off sick |
| Internal team and owner | Blockers, capacity, upcoming handoffs, risks to other projects | Polished wording; plain notes are fine |
Writing for one reader at a time keeps the report short. A report that tries to serve everyone at once can grow long and become harder to read.
What to include in a project status report
The Atlassian article recommends covering what it calls the big three: timeline, scope and budget. It also suggests including achievements, blockers, an overall status indicator and action items with owners and due dates. Here is how that translates into a one-page layout for a small team:
- Header: project name, reporting period, report owner.
- Overall status: one colour and one sentence explaining it.
- Summary: a few sentences a reader could stop after.
- Timeline: next milestone and whether it is on schedule.
- Scope: any requested changes and whether they were agreed.
- Budget or effort: on plan, or a note on what has changed.
- Completed this period: the main outputs, not every task.
- Blockers and decisions needed: what is stuck and who can unstick it.
- Next steps: action, owner, due date.
Setting the status colour honestly
The Atlassian article describes a simple colour system:
| Status | Meaning | Example for a studio project |
|---|---|---|
| Green (on track) | No issues blocking progress | Designs approved on schedule, build started |
| Yellow (at risk) | Roadblocks exist, and solutions are in progress | Client copy is late, but a revised date has been agreed |
| Red (off track) | Roadblocks exist, and solutions are still being worked out | Key content still missing and no agreed date to receive it |
The same Atlassian article quotes a project manager warning that a report that is always green can signal a lack of awareness rather than a smooth project. A yellow status with a clear plan gives a client more to work with than a green status that later turns red without warning.
How to write a project status report in six steps
Atlassian’s status report guide outlines a writing process that starts with the objective and ends with editing and sending. Adapted for a small team, it looks like this:
1. Decide what the report is for
Is it to keep a client confident, to flag a decision, or to coordinate the team? Pick one primary purpose for each report.
2. Choose the audience
Use the table above to decide whether this is the client version or the internal version.
3. Gather the facts
Check the plan, the task board and recent messages. Note milestones hit or missed, open questions and any changes requested since the last report.
4. Fill in the template
Work top to bottom. Set the status colour last, once you have seen the full picture.
5. Cut it down
Remove anything the reader does not need in order to act. Replace long paragraphs with short bullets. Plain language helps clients who are not familiar with your process.
6. Send it on a fixed rhythm
The Atlassian guide suggests that a weekly report can be a good starting point, adjusting the cadence to the project. Send it on the same day each time so readers know when to expect it. The guide also recommends keeping an ongoing draft, which means adding notes during the week rather than writing from memory on Friday afternoon.
A one-page project status report template
Copy this into a document, email or shared page:
- Project: [name] · Period: [dates] · Owner: [name]
- Overall status: [Green / Yellow / Red] – [one sentence why]
- Summary: [two or three sentences]
- Timeline: Next milestone [name, date] – [on schedule / at risk]
- Scope: [no changes / changes requested and their status]
- Budget or effort: [on plan / note]
- Completed: [main output 1], [main output 2]
- Blockers and decisions needed: [issue] – [who can resolve it] – [by when]
- Next steps: [action] – [owner] – [due date]
Save the template somewhere the whole team can reach, alongside your other repeatable processes. Our business systems articles cover more ways to standardise this kind of recurring work.
Worked example: a weekly client report from a small studio
Here is a hypothetical report from a three-person studio redesigning a website for a local fitness studio.
- Project: Website redesign · Period: week four · Owner: account lead
- Overall status: Yellow – page designs are approved, but final class descriptions have not arrived yet.
- Summary: Homepage and class pages are designed and approved. Build has started. Launch stays on the agreed date if copy arrives by next Wednesday.
- Timeline: Next milestone is the staging site review – at risk until copy is received.
- Scope: Client asked for a new “Meet the instructors” page. Agreed as a follow-on phase, not part of this launch.
- Budget or effort: On plan.
- Completed: Approved homepage and class page designs; mobile layouts.
- Blockers and decisions needed: Final class descriptions – client – by Wednesday.
- Next steps: Build class page template – developer – Friday. Prepare staging link – account lead – after copy arrives.
The client can read this in a minute, see exactly what is needed from them, and understand why the status is yellow rather than green.
Common project status report mistakes
- Reporting activity instead of progress. “Had three meetings” tells the reader little. “Homepage approved” tells them a lot.
- Burying the blocker. Put decisions needed near the top, not in the last line.
- Staying green too long. Move to yellow as soon as a risk appears, with a plan attached.
- Irregular timing. A report that arrives whenever someone remembers is easy to ignore.
- One report for everyone. Clients and internal teams need different levels of detail.
Key takeaways
A project status report works best as a single page sent on a fixed rhythm to a clearly chosen audience. Lead with an honest status colour and a short summary, cover timeline, scope and budget, call out blockers and the decisions you need, and finish with owned next steps. Keep a running draft during the week so the report is quicker to finish, and send it on the same day each time so readers know when to expect it.
Written by the Design Productive Editorial desk. Disclosure: this guide contains no affiliate or sponsored links.
