What Should a Status Report Include? The Four Core Sections (With a Reusable Template)

A status report should include four things: where the project stands overall, progress against the plan rather than against effort, the risks, issues and decisions that need attention, and what happens next including what you need from the reader. The last of those is the one most reports leave out.

This piece covers the contents. The craft of writing each line is in how to write a project status report stakeholders actually read, and how often to send one belongs in a project communications plan.

What is a project status report?

A project status report is a short recurring written update on one project, sent on a fixed schedule to people who are not doing the work. It carries health, progress, risk and next steps for a single delivery, which separates it from meeting minutes, a record of one conversation, and from a monthly client or funder report, an accountability document covering a period.

Most status reports are written to prove that work happened. A report written to get a decision is a different document, and the difference shows up in every line. The proving version narrates activity, avoids the uncomfortable numbers, and ends with nothing for anyone to do. Six weeks of that teaches the distribution list to skim, and the report nobody reads is almost always the one that never asked anybody for anything.

What should a status report include?

Four sections, in this order: overall status, progress against the plan, risks and decisions needed, and what happens next including your ask. The count is a property of the template rather than of the discipline. No standards body defines four, and there are perfectly good reports running on three and on six. What is genuinely established is the progress, plans and problems shape, usually shortened to PPP, and the red, amber and green convention for signalling health. Everything else is house style.

1. Overall status. One colour, one short paragraph, and a named thing the colour refers to. “Amber” on its own means nothing. “Amber against the November release, green against budget” is a status. Put last period’s colour beside it so the direction is visible, and if it has moved, say what moved it. Some readers will read this section and nothing else, so it has to work alone.
2. Progress against the plan. What has finished since the last report, expressed as things that now exist rather than hours that were spent. Three lists do this better than a single figure: finished and demonstrable, in progress with an expected finish date, and not started although it was due to have started. Add a line for anything that slipped, carrying the old date, the new date and the cause. Slippage recorded with its cause is what lets a reader spot a pattern before you do.
3. Risks, issues and decisions needed. A risk might happen, an issue already has, and a decision needed is neither: it is work sitting still because somebody outside the team has not chosen yet. Each line takes an owner, a date and a consequence. Report only what changed or what needs the reader. The full register lives in the register, and copying it across every week is how both documents stop being read.
4. What happens next, and what you need from the reader. The items due before the next report, each with a name against it, and then the ask: a specific thing, from a specific person, by a specific date. Write “nothing needed this week” when that is true, so an empty section never gets confused with a forgotten one. Most reports stop at the forecast. A forecast tells the reader what you intend to do. The ask is the only part that changes what they do.

If you have to drop a section in a bad week, drop the forecast. If you keep only one, keep the ask.

A status report template you can copy

Keep it short enough that writing it weekly is not resented. A template that takes an hour gets abandoned around week four and replaced by a paragraph in a chat channel, which is worse than the template you started with.

PROJECT: <name>        REPORT DATE: <date>        PERIOD: <from> to <to>

STATUS: Green / Amber / Red
Refers to: <the milestone, date or budget the colour is about>
Last period: <colour>. Changed because: <one line, or "no change">

1. WHERE WE ARE
<Two or three sentences. What is true now, and what is different from last time.>

2. PROGRESS AGAINST PLAN
Finished and demonstrable: <items>
In progress: <item, expected finish date>
Not started, and due to have started: <item, why>
Slipped: <item, old date, new date, cause>

3. RISKS, ISSUES AND DECISIONS
Risk / Issue: <what it is, the consequence, owner, review date>
Decision needed: <the decision, who takes it, needed by, cost of it being late>

4. NEXT, AND WHAT I NEED FROM YOU
Due before the next report: <item, owner, date>
I need: <named person, specific thing, date>   or   Nothing needed this week.

Keep two variants. The short one, for a week when the plan is holding, is the status block, the three progress lists and “nothing needed this week”. Four lines sent on the agreed day beats a page sent on Thursday. The long one, for a steering group or a project in trouble, adds a milestone table showing baseline against forecast dates, a budget line, and a log of what has been agreed since the last version. Everything else goes in an appendix nobody is obliged to open.

Who is the report actually for?

One report rarely serves three audiences well, and pretending otherwise is the main reason reports get long. The same facts have to be assembled differently depending on who is reading.

Reader	What they want from it	What they do with it	What to cut
Sponsor or exec	Exceptions, decisions, money and dates	Approves, funds, unblocks, or leaves you alone	Workstream detail, tool names, anything that has not changed
Delivery team	Specifics, sequencing, who is waiting on whom	Plans their own week around it	Commercial framing, stakeholder politics
Client	An honest picture and early warning	Manages their own stakeholders with it	Internal blame, unconfirmed dates, half-formed risks
Steering group	Trend against the baseline	Decides to continue, change or stop	Anything that is not a delta since the last meeting

Pick one primary reader per report and write to them. Where two audiences genuinely need different things, two short reports beat one long one that satisfies neither: the team’s version can be a channel post, the sponsor’s a single page. Failing that, put the sponsor’s section on top and push the rest into an appendix.

Why “percent complete” is the weakest number in the report

Percent complete is usually a feeling expressed as arithmetic. Almost nobody measures it. Somebody estimates the effort still left, compares it to the effort they imagined at the start, and rounds to the nearest five. That is why projects sit at eighty per cent for a month, and why the last ten per cent routinely takes as long as the first half: it holds integration, sign-off, data cleanup, accessibility fixes and everything deferred for being awkward.

The figure earns its place when it counts something countable. “42 of 60 sites migrated” is worth printing, because the denominator is fixed and a reader can check it. “The build is 80% complete” is not, because the denominator moves every time the scope does, and it moves quietly. Otherwise use the three lists. They take longer to write because they commit you to claims someone could check next week.

Why reports stay green until they cannot

Status colours drift green because amber starts a conversation and green ends one. Amber means somebody senior asks what you need, which is a good conversation to have and an uncomfortable one to schedule, so it slides to next week, and next week carries exactly the same incentive. By the time the report goes red, the decisions that would have helped, more people or less scope or a later date, have mostly expired.

Four things make honest colours easier to file:

• Define the colours by what they ask of the reader, not by how the team feels. Green: nothing needed from you. Amber: a decision or a resource is needed, and it is written below. Red: a committed date or scope has already moved. Print the definitions on the report so nobody has to remember which version you meant.
• Make amber ordinary. A project that has never once been amber is either very lucky or not being reported. Say that at kickoff, and go amber early on something small, so the first amber is not also the first crisis.
• Record the date the colour last changed. A colour that has not moved in eight weeks, on a project that has moved a great deal, is not a status. It is a habit.
• Let someone who is not the author challenge it. A delivery lead, a peer project manager, anyone who has read the plan. Colours set by one person alone drift in that person’s preferred direction, and rarely on purpose.

What follows an amber is a re-planning conversation, not a longer paragraph. That conversation goes better when it starts from the plan that already exists rather than from a blank page, which is what Projan’s import step does: it pulls the current plan document into a planning session in Slack or Microsoft Teams, asks what has actually changed about dates and owners, and writes the revised items back out to a tracker such as Jira.

What are the common status report mistakes?

The mistakes that get reports ignored are mostly about who the report is addressed to and what it asks for. Very few of them are about formatting.

1. The report has no addressee. It goes to a distribution list, is addressed to nobody in particular, and so nobody in particular owes it a reply. Name the person who has to act, in the report.
2. Numbers arrive without a denominator. “14 tickets closed” is a fact with no meaning attached until the reader knows how many are open and how many were closed last week.
3. Risks are copied forward unchanged. The same four risks, same wording, eleven weeks running. A risk nobody has reassessed is decoration, and it teaches readers to skip the section where the real one will eventually appear.
4. The report is where bad news is broken. Discovering a two-month slip in writing, alongside twelve other people, is how a sponsor learns to distrust the whole document. Brief them first, then write it down.
5. Length grows to fill a quiet week. Weeks with nothing to report often produce the longest ones, because there is nothing to say and an urge to prove otherwise. A quiet week deserves four lines.
6. Everything sits at the same altitude. A blocked integration and a booked meeting room get the same bullet, and the reader ends up doing the sorting you were supposed to do.

All six are fixed by the same edit. Decide who has to do something because of this report, then cut whatever does not help them do it.

Frequently asked questions

What are the four key components typically included in a well-structured status report? There is no canonical four. Most templates settle on overall status, progress, risks and decisions, and what comes next, which is the version used above. The genuinely established shape is progress, plans and problems, usually shortened to PPP. Three, four and six section templates are all in common use, and the count says more about who wrote the template than about the discipline.

Should a status report include a budget line? Include it if somebody reading the report can act on it, which usually means the sponsor. One line is enough: approved, spent to date, forecast at completion. Skip it on internal projects where nobody in the distribution list controls the budget, and never show spend without a forecast, because spend alone tells a reader nothing about whether the money will run out.

Should risks and issues be in the same section? Yes in a weekly report, separated by a label. Splitting them into two sections doubles the reading and hides the relationship, since most issues were risks somebody logged and nobody acted on. Mark each line as risk or issue, give it an owner and a date, and keep the full risk register somewhere else. Only report the ones that changed or that need the reader.

How much history should a status report carry? One period, plus the previous status colour and the original baseline date for anything that has slipped. Readers want the delta, not the archive. If someone needs the full history, keep a running document with each report appended and link to it once, rather than growing every weekly report until it is a project diary nobody opens.

What should I do if a stakeholder disputes the status colour? Ask which date or deliverable they think the colour is wrong about, then agree the colour against that specific thing rather than in general. Most disputes are about scope, not honesty: they are reading the colour as covering the whole programme while you meant one milestone. Record the outcome in the next report so the disagreement is not repeated silently.

Four sections, one page, one fixed day. Write the ask first and build the rest of the report around it, because that is the only part of the document that changes what happens next.