/Management & operations

Project Status Report Template

RAG status, progress, milestones and blockers on one page.

Details

project status report template
Fills every box with an example you can type over.
Adding a logo, a photo or your signature?
One per line
One per line
One per line: Issue | Impact | Owner
One per line: Milestone | Date | Status

Red highlights mark what is still blank. Click anything on the page to change it. Your draft is kept on this device as you work.

Tap the page to change any words.
[organisation name]
[organisation address]
Project Status Report
Project[project]
Period[period]
Project manager[name]
Overall status[status]
Percent complete—%

1. Completed this period

[add completed items]

2. Planned next period

[add planned items]

3. Milestones

MilestoneDateStatus
[add milestones]

What is a Project Status Report?

A project status report is the regular one-page account of where a project stands: overall status, what moved since the last report, what is coming, milestone dates against the baseline, risks and the decisions needed. It matters because it is the sponsor's only routine view of the work. Reports that arrive late, or that stay green until the week the project fails, remove the one chance to intervene while intervention is still cheap.

Project managers send them to a sponsor or steering group weekly, fortnightly or monthly. Agencies and contractors send them to clients, often because the contract requires it. Programme offices consolidate them into a portfolio view, and grant-funded projects send a version to the funder. The audience is usually someone carrying several projects and very little spare time, which is why the format matters: it should be readable in two minutes and identical in shape every single period.

Where reporting is contractual, the content, frequency and deadline are set by the agreement rather than by preference. Construction and engineering contracts built on standard forms used in various markets prescribe reporting and, importantly, set separate notice requirements for delay and additional cost — mentioning a delay in a status report is not usually the same as serving the notice the contract requires. Grant agreements set their own reporting schedule, sometimes with funding consequences for late submission. Check the relevant clause and the notice provisions before relying on the report.

A status report is not a change request. Writing that scope has grown does not approve it, and a sponsor who read it has not agreed to it — the variation still needs whatever route your governance defines. It is not a payment application or an invoice either. And a RAG colour is not a risk entry: an amber status tells the reader something is uncomfortable, while the risk register tells them what might happen, how likely it is, and what is being done about it.

What to put in a Project Status Report

These are the details this template asks for. Anything left blank is marked in red on the preview so you can see what is still missing.

FieldWhat goes in it
Issuing organisationFor example: Maple Grove Homeowners Association
Organisation addressFor example: 1420 Kinnear Road, Columbus, OH 43212
ProjectFor example: Warehouse management system rollout
Reporting periodFor example: Week ending 30 August 2026
Project managerFor example: James Whitfield
Overall statusFree text
Percent completeFor example: 62
Completed this periodOne per line
Planned next periodOne per line
Issues and blockers optionalOne per line: Issue | Impact | Owner
MilestonesOne per line: Milestone | Date | Status

How to write a Project Status Report

  1. Define the RAG rule before setting a colour

    Write down what each colour means and apply it identically every period: green means the project will deliver within agreed time, cost and scope tolerance; amber means it will not without a decision or an intervention already identified; red means it will not and the answer is not yet known. Without definitions, colour becomes mood, and a project that jumps from green to red has been misreported for weeks.

  2. Report against the baseline, not last week

    Show the original agreed date and cost alongside the current forecast and the variance, not only the movement since the previous report. Incremental reporting hides drift: six one-week slips reported one at a time never look like the six-week problem they are. If the plan has been formally rebaselined, say so, and give the date it changed and who approved it.

  3. Write progress as completed outcomes

    'Worked on integration' is effort. 'Integration built and passing in test; awaiting supplier credentials for production' is progress with a blocker attached. Report what is finished, what is in flight with a forecast completion date, and what should have started but has not. Percentages invented by feel do more harm than a plain statement of which deliverables are done.

  4. Turn blockers into requests with dates

    For each blocker, write what you need, from whom, by when, and what happens if it does not arrive. 'Need a decision on the data retention period from the information governance lead by 18 March, or the build slips a week' can be acted on in the meeting. 'Waiting on IG' cannot. Carry unresolved requests forward with their original date, so the age is visible.

  5. Fix the cut-off, the distribution and the length

    Set a data cut-off — close of business Wednesday, issued Thursday morning — and hold it, so figures across projects are comparable. Keep the report to one page with the same sections in the same order every time, because readers navigate by position. Name a fixed distribution list, and send everyone the same report rather than a softened version upward and a candid one sideways.

Common mistakes

  • Keeping a project green until the milestone has already been missed, which destroys the sponsor's trust in every other report you send.
  • Reporting only movement since the last update, so accumulated drift against the original baseline is never visible to anyone.
  • Quoting percentage complete with no stated basis, which lets a project sit at ninety per cent for two months.
  • Listing blockers with no named person, no date and no consequence, so they read as complaints rather than as requests that need answering.
  • Assuming that a delay mentioned in the status report satisfies a contractual notice requirement, which can cost an entitlement to extra time or money.

Frequently asked questions

How often should a project status report be issued?

Weekly for active delivery, fortnightly or monthly for slower or long-running work, and always at the frequency the contract or funder specifies where one applies. The test is whether the sponsor can still act on what they read: a monthly report on a project with weekly decision points arrives after the decisions have already been taken by default.

What does RAG status mean?

Red, amber, green — shorthand for whether the project will deliver within agreed tolerance. The letters mean nothing without a written definition, and definitions differ between organisations, so publish yours on the report itself. Many teams also show separate colours for time, cost, scope and risk alongside an overall status, which is more informative than one colour standing for everything.

What should a project status report include?

Overall status with sub-statuses for time, cost and scope; progress since the last report as completed outcomes; what is planned next; milestones with baseline, forecast and variance; top risks and issues with owners; and decisions or actions needed from the reader, each with a date. One page, same order every time. Everything else belongs in an appendix or a linked plan.

Who should receive a project status report?

The sponsor, the steering group, the business owner who will operate the result, and any function carrying a dependency, plus the client or funder where the contract requires it. Keep the list fixed and named. The important rule is one version: circulating a reassuring report upward and a realistic one sideways is how projects end up formally green and privately failing.

What is the difference between a status report and a progress report?

In most organisations they are the same document under different names. Where a distinction is drawn, a status report is periodic and forward-looking — where we stand and what is needed — while a progress report is a narrative account of work completed, often tied to a payment stage or a funder claim. Check what your own contract or funder means by the term it uses.

This page explains general practice and is not legal advice. Requirements differ between countries and, in some cases, between states — check what applies where the document will be used.

All templates · Management templates