Project Status Report: Template, Examples, and How to Use RAG Status

Quick answer: A project status report is a short, regular update telling people what has happened, what is coming next, and whether the project is healthy. Most use RAG status — red, amber or green. A good report fits on one page, uses agreed thresholds rather than opinion, and names the decisions you need.

Most status reports get skimmed and forgotten. Some are worse than that — they say green every week until the project suddenly fails.

That second problem has a name, and it’s the most important thing on this page.

This guide covers how to write a report people actually read: what goes in it, how to set RAG thresholds with real numbers instead of gut feel, and how to show the same week to three different audiences.

What Is a Project Status Report?

A project status report is a short document that tells people how a project is going over a set period — usually a week or a month.

It answers four questions:

1. What did we finish?
2. What’s next?
3. Is anything going wrong?
4. What do we need from you?

That fourth one is the one most reports forget, and it’s the reason sponsors stop reading. A report that only describes things is a newsletter. A report that asks for a decision is a working document.

Status report vs progress report

People use these interchangeably, and mostly that’s fine. Where organisations do separate them:

	Status report	Progress report
Focus	Health right now — are we on track?	Work completed over a period
Looks	Forward and backward	Mostly backward
Length	One page	Can be longer
Contains RAG	Usually	Sometimes
Audience	Sponsors and stakeholders	Often the client or a funder

If someone asks for one and you’re not sure which they mean, ask. It’s usually a status report.

What Goes in a Project Status Report?

One list, not two. These nine sections cover it.

#	Section	What goes in it
1	Header	Project name, report date, reporting period, author, who it’s for
2	Overall RAG status	One colour for the whole project, plus one sentence saying why
3	Summary	Three or four lines. The whole story for someone who reads nothing else
4	RAG by area	Schedule, budget, scope, resources, risk — each with its own colour
5	Completed this period	What actually finished. Not what was worked on
6	Planned next period	What will finish next, with owners
7	Issues and risks	What’s wrong now, and what might go wrong. Each with an owner
8	Decisions needed	What you need from the reader, and by when
9	Key numbers	Budget spent vs planned, milestones hit vs due

Section 5 is where most reports go wrong

“Worked on integration testing” is not a completed item. “Integration testing started, 12 of 40 test cases passed” is.

The test: could someone disagree with you about whether it’s done? If yes, it isn’t done — it’s in progress, and belongs in the next-period section with an honest note.

What Is RAG Status, and What Are the Thresholds?

RAG stands for red, amber, green. It’s a traffic-light summary of project health.

Colour	Meaning	What it asks of the reader
Green	On track. No help needed	Nothing. Read and move on
Amber	Off track, but we have a plan	Awareness. Maybe a small decision
Red	Off track, and we need help	Action. A decision, money, or people

Simple enough. The problem is that most projects set the colour by feeling, which makes it meaningless — and makes it easy to stay green when you shouldn’t.

Set thresholds with numbers

Agree your thresholds at the start of the project, write them into your reporting plan, and then apply them whether you like the answer or not.

Here’s a common starting point. Adjust the percentages to your project’s size and tolerance:

Area	Green	Amber	Red
Schedule	Within 5% of baseline	5–10% behind	Over 10% behind, or a milestone missed with no recovery plan
Budget	Within 5% of planned spend	5–10% over	Over 10% over, or forecast to overspend at completion
Scope	No unapproved changes	Change requests open and awaiting decision	Scope changed without approval
Resources	Team in place as planned	A gap with a plan to fill it	A gap with no plan, or a key person unavailable
Risk	No open high risks	High risk open, with an owner and a mitigation	High risk open with no owner or no plan

Why this matters more than it sounds. When the threshold is written down, “we’re amber” stops being an argument. You point at the number. That one change removes most of the politics from status reporting.

The rule for the overall colour

The overall status should be the worst of the individual areas, unless you explain why not.

If budget is red, the project is red. A project showing green overall with a red area underneath is the exact problem the next section describes.

What Is the Watermelon Effect, and How Do You Avoid It?

A watermelon is green on the outside and red in the middle.

A watermelon project reports green every single week, then fails. The reports were green. The project was always red. Nobody saw it because the reporting hid it.

This is the most common serious failure in project reporting, and almost no guide mentions it.

Why it happens

Cause	What’s going on
Green is rewarded	Nobody enjoys delivering bad news to a sponsor
Amber feels like admitting failure	So people wait “until we know more”
No thresholds	If the colour is a judgement call, optimism wins
Self-reported % complete	Everything sits at 90% for weeks
Bad news travels slowly upward	Each layer softens it a little
Reports describe effort, not outcomes	“Working hard on it” sounds fine

Six ways to stop it

1. Use written thresholds. Covered above. This is the single biggest fix.
2. Make amber normal. If a sponsor reacts badly to amber, they’ll only ever see green until red is unavoidable. Say early that amber means “managed, with a plan” — not failure.
3. Report milestones as done or not done. No percentages. Binary.
4. Require a reason for every green. One sentence of evidence. “Green because all four milestones hit and spend is 3% under plan” is checkable. “Green” alone is not.
5. Ask for the bad news directly. In your team check-in, ask “what’s the thing you’re hoping fixes itself?” You’ll hear things no status update would have surfaced.
6. Track the trend, not just this week. Three ambers in a row is a red, even if each individual week looked manageable.

A test you can run today. Look at the last four status reports on any project. If every area was green every week and the project is now late, you have a watermelon problem — not a project problem.

How Often Should You Send a Project Status Update?

The competitor guides list daily, weekly, monthly and quarterly, and give you no way to choose. Here’s the decision.

Project length	Suggested cadence
Under 4 weeks	Twice weekly, kept very short
1–3 months	Weekly
3–12 months	Weekly to the team, monthly to the sponsor
Over 12 months	Monthly, with quarterly steering group packs

Then adjust for three things:

• Risk level. A high-risk project reports more often, whatever its length.
• Stakeholder appetite. Some sponsors want weekly; some will ignore anything more frequent than monthly. Ask them.
• Phase. Report more often during a go-live than during a quiet build phase.

Two rules about cadence

Pick a day and stick to it. A report that arrives on a predictable day gets read. One that arrives whenever gets ignored.

Shorter and more often beats longer and occasional. A half-page every Friday is more useful than four pages once a month, because problems surface while they’re still cheap to fix.

Your stakeholder engagement plan is the right place to record who gets what, and how often.

How to Write a Project Status Report

Eight steps. Once the template is set up, a weekly report takes 15–20 minutes.

Step 1: Gather the facts first

Pull the actual numbers before you write a word: milestones hit, spend to date, open risks, change requests. Writing first and then finding numbers to fit is how reports become fiction.

Step 2: Fill in the header

Project, period covered, date, author, distribution list. Boring, and it’s what makes the report findable in six months.

Step 3: Set the RAG colours using your thresholds

Each area first, then the overall colour as the worst of them. Don’t start with the overall colour and work backwards.

Step 4: Write the summary last, but put it first

Three or four lines covering: overall status, the single most important thing that happened, the single biggest risk, and what you need. Most readers will read only this.

Step 5: List what actually finished

Completed means completed. Anything part-done goes in the next section with a note.

Step 6: List what’s next, with owners and dates

Name people, not teams. “The team will finish testing” is nobody’s job.

Step 7: State the decisions you need

Be specific: what the decision is, who needs to make it, by when, and what happens if it’s late.

This is the section that turns a report into a tool. Without it you’re broadcasting.

Step 8: Keep it to one page

If it won’t fit, you’re including things your reader doesn’t need. Detail belongs in an appendix or a linked document.

What Goes in the Project Status Report Template?

Copy this. It’s the project status report template you can reuse weekly.

PROJECT STATUS REPORT

Project:
Reporting period:  [from] to [to]
Report date:                     Report number:
Prepared by:                     For:
Next report due:

OVERALL STATUS:  [ GREEN / AMBER / RED ]
Because:  [one sentence of evidence]

SUMMARY
[Three or four lines. Overall position, the most important thing that
happened, the biggest risk, and what you need from the reader.]

STATUS BY AREA
| Area       | RAG | Why (evidence, with a number) |
| Schedule   |     |                               |
| Budget     |     |                               |
| Scope      |     |                               |
| Resources  |     |                               |
| Risk       |     |                               |

KEY NUMBERS
Budget spent to date:        £____ of £____  ( __% )
Planned spend by now:        £____           ( __% )
Variance:                    £____           ( __% )
Milestones due to date:      ____   Hit: ____   Missed: ____
Open change requests:        ____
Open high risks:             ____

COMPLETED THIS PERIOD
| What finished | Owner | Note |

PLANNED NEXT PERIOD
| What will finish | Owner | Due |

ISSUES (happening now)
| Issue | Impact | Owner | Action | By when |

RISKS (might happen)
| Risk | Likelihood | Impact | Owner | Mitigation |

DECISIONS NEEDED FROM YOU
| Decision | Who decides | Needed by | If late |

MILESTONE TRACKER
| # | Milestone | Planned | Forecast | Status |

Distribution:
Appendices / links:

What Does a Weekly Status Report Example Look Like?

Here’s a filled project status report example with real numbers.

Project: Warehouse management system rollout Period: Week 9 of 16 · Report date: 9 October 2026 Prepared by: Priya M. · For: Daniel K., Sponsor

Overall status: AMBER

Because: integration testing started 4 days late, which puts user acceptance testing at risk. Budget is 5% under plan and a recovery plan is agreed.

Summary

Hardware is installed across all three sites and signed off. Integration testing began on Monday, four days later than planned, because the supplier’s test environment wasn’t ready. We’ve agreed a recovery plan that protects the go-live date by running two test streams in parallel. Spend is slightly under plan. We need a decision on overtime approval by Friday to make the recovery plan work.

Status by area

Area	RAG	Why
Schedule	Amber	Integration testing 4 days late — 5% of elapsed timeline
Budget	Green	£74,000 spent of £140,000. Plan said £78,000 by now — 5% under
Scope	Green	No change requests open
Resources	Amber	Two testers shared with another project from week 11
Risk	Amber	One high risk open — supplier environment stability — owner assigned

Key numbers

Measure	Value
Budget spent to date	£74,000 of £140,000 (53%)
Planned spend by now	£78,000 (56%)
Variance	£4,000 under (5%)
Milestones due to date	3 · Hit: 3 · Missed: 0
Open change requests	0
Open high risks	1

Milestone tracker

#	Milestone	Planned	Forecast	Status
M1	Requirements signed off	Week 3	Week 3	Done
M2	Hardware installed, 3 sites	Week 6	Week 6	Done
M3	Integration testing starts	Week 8	Week 9	Done, 4 days late
M4	User acceptance testing	Week 12	Week 12	At risk
M5	Go-live	Week 16	Week 16	On track with recovery plan

Decisions needed

Decision	Who	By when	If late
Approve £3,000 overtime for parallel test streams	Daniel K.	Friday 13 Oct	Recovery plan fails; go-live moves to week 17

Notice three things about this report.

The overall status is amber, not green, even though three of five areas are green and the budget is healthy. Schedule is amber, so the project is amber. That’s the rule from earlier, applied honestly.

Every RAG colour has a number behind it. “5% of elapsed timeline” is checkable. “Slightly behind” isn’t.

There’s exactly one decision, with a deadline and a consequence. The sponsor knows precisely what to do and what happens if they don’t.

Before and After: What Does a Better Report Look Like?

The fastest way to see what makes a report work is to look at the same week written badly and then well.

Before

Status: Green

This week the team continued to make good progress on the warehouse project. We worked on integration testing and continued coordinating with the supplier. The hardware rollout is largely complete and we are in a good position overall. Some minor delays were experienced but these are being managed. The team is working hard and we remain confident of delivery. Budget is on track.

Next week we will continue with testing activities.

After

Status: Amber — integration testing started 4 days late, putting UAT at risk. Recovery plan agreed. Spend 5% under plan.

Completed: hardware installed and signed off at all 3 sites. Integration testing started Monday; 12 of 40 test cases passed.

Next: complete remaining 28 test cases by 17 Oct (Tomas B.). Confirm UAT participants (Sana R., by 15 Oct).

Issue: supplier test environment was 4 days late. Mitigation: two parallel test streams.

Decision needed: approve £3,000 overtime by Friday 13 Oct, or go-live moves to week 17.

What changed, and why

Problem in the “before”	Fix in the “after”
“Green” with a delay mentioned later	Amber, matching the facts
“Good progress”	12 of 40 test cases passed
“Largely complete”	Installed and signed off at all 3 sites
“Minor delays… being managed”	4 days late, with the named mitigation
“Budget is on track”	5% under plan
“We will continue with testing”	28 cases by 17 Oct, owner named
No decision asked for	One decision, deadline, consequence

The “before” version isn’t lazy. It’s what people write when they’re trying to sound reassuring. That’s precisely how watermelon reporting starts.

How Do You Adapt the Same Report for Three Audiences?

Different readers need different things from the same week. Here’s what changes.

	Team	Sponsor	Steering group
Frequency	Weekly or daily	Weekly	Monthly
Length	A short list	One page	3–5 slides
Focus	Tasks and blockers	Health, risk, decisions	Trend, forecast, money
Detail level	Individual tasks	Milestones	Phases
RAG	Optional	Essential	Essential, with last month’s for comparison
Numbers	Test cases, tickets	Budget vs plan, milestones	Forecast at completion, trend
Decisions	Who unblocks what	The one decision needed	Escalations and approvals
What to cut	Nothing	Task-level detail	Everything except trend and decisions

One rule. All three versions come from the same facts. If the team’s version says testing is struggling and the sponsor’s version says green, you’ve created a watermelon on purpose.

One practical tip. Write the sponsor version first, as the discipline of fitting one page forces you to decide what matters. The team version is then that plus detail, and the steering pack is that plus trend.

Why Is “% Complete” Misleading?

“The build is 80% complete” is the most quoted and least reliable number in project management.

Three reasons it misleads:

1. It’s self-reported. Nobody wants to say 40%, so everyone says 80%.
2. The last 20% holds the hard parts. Testing, fixing, integration and sign-off are all at the end.
3. It can’t go backwards without embarrassment. So it doesn’t, even when it should.

The classic symptom is a task that’s been 90% complete for three weeks.

What to use instead

Instead of	Use
“Testing is 60% done”	“24 of 40 test cases passed”
“The build is 80% complete”	“4 of 6 modules complete and signed off”
“We’re nearly there”	“2 milestones remaining, both forecast on time”
“Spend is on track”	“£74,000 of £140,000. Plan said £78,000”

The principle: count things that are either finished or not. Milestones, test cases, modules, sites, sign-offs. A count can’t be flattered the way a percentage can.

If your organisation needs a percentage, derive it from the count. “24 of 40 test cases” is 60%, and now the 60% means something.

For projects where cost and schedule performance need formal tracking, a project control process sets out how to measure it consistently.

What Should You Leave Out of a Status Report?

A status report is widely circulated and often forwarded. Things that don’t belong:

Leave out	Why	Where it goes instead
Named individuals’ performance problems	It’s an HR matter and it will be forwarded	A private conversation with their manager
Unconfirmed bad news	Rumours become facts once written down	Hold until confirmed, then report immediately
Commercially sensitive supplier detail	Reports get shared more widely than you expect	A restricted annexe
Personal or health information	Data protection, and basic decency	Nowhere in a project report
Blame	It stops people telling you things	Lessons learned, framed as process not people
Long technical detail	Nobody reads it	An appendix or a linked document
Anything you’d be uncomfortable with the client seeing	It will reach them eventually	Reword it so you would be comfortable

That last line is a useful test for the whole report. Assume it gets forwarded to the client, the supplier, and someone senior you haven’t met. Would you still send it as written?

How to Create a Project Status Report Template Using Popular Project Management Software

Menu names change, so check your tool’s help pages. The approach is the same across all of them.

In a spreadsheet (Excel or Google Sheets)

1. Build the template on one sheet, using the layout above.
2. Put the raw data — milestones, spend, risks — on a second sheet.
3. Use formulas to pull the key numbers through, so they can’t be mistyped.
4. Use conditional formatting on the RAG cells so typing “Amber” colours the cell.
5. Save as a template file, and copy it for each reporting period.

This is the most common setup and the easiest to keep honest, because the numbers come from the data rather than from memory.

In Microsoft Project

1. Use the built-in reports under the Report tab as a starting point.
2. Add the Baseline and Variance fields so planned versus actual appears automatically.
3. Create a custom report with the milestone table and the cost variance table.
4. Export to PDF for distribution.

In a task-board tool (Asana, Monday.com, ClickUp)

1. Add custom fields to the project for RAG status per area.
2. Use the tool’s built-in status update or project update feature for the narrative.
3. Create a dashboard with milestone completion and budget widgets.
4. Set a recurring task that reminds you to post the update on the same day each week.
5. Save the setup as a template for future projects.

In Jira

1. Use a dashboard with gadgets for sprint or epic progress and open issues.
2. Keep the narrative report in the connected wiki, with a page template per period.
3. Link each report to the relevant epics so the detail is one click away.

In a document or wiki tool (Confluence, Notion, Google Docs)

1. Paste the template above and save it as a page template.
2. Create a parent page for the project, with one child page per reporting period.
3. Keep a summary table on the parent page showing each period’s overall RAG, so the trend is visible at a glance.

That last step is worth doing in any tool. A column of RAG colours going green, green, amber, amber tells a sponsor more than any single report.

What Are the 8 Most Common Status Report Mistakes?

1. Reporting green to avoid difficult conversations. The watermelon problem. It always surfaces eventually, and later is worse.
2. No thresholds. If RAG is a feeling, it means nothing.
3. Describing effort instead of outcomes. “Working hard on testing” isn’t a status.
4. No decisions section. The report becomes a broadcast rather than a tool.
5. Too long. A four-page report is a report nobody finishes.
6. Inconsistent timing. Unpredictable reports get ignored.
7. Different stories for different audiences. The detail should change. The facts shouldn’t.
8. Using % complete as the main measure. Count finished things instead.

How Does Writegenic AI Fit In?

A status report is a short, structured document you write every single week. That repetition is exactly where drafting help earns its keep.

Writegenic AI can help you:

• Turn your raw notes and numbers into a clean one-page report
• Write the summary paragraph from the detail you’ve already captured
• Rewrite a vague draft into specific, evidence-backed language — the before-and-after above is the pattern
• Produce the three audience versions from one set of facts
• Draft the escalation email when something goes red
• Roll up several project reports into a portfolio summary for a steering group

It sits alongside the rest of the set: the work breakdown structure and schedule that your numbers come from, the risk assessment plan feeding your risk section, the performance evaluation plan defining what you measure, and the closure report at the end.

Explore AI for project management or use the prompt generator for sharper instructions.

Draft with the tool, keep the judgement. AI can make a report read well in seconds. It cannot decide whether you’re really amber or green, and a well-written green report on a red project is more dangerous than a badly written honest one. The colour is yours. So is the decision about what your sponsor actually needs to know.

Try Writegenic AI free

Frequently Asked Questions

Related reading:

• Work Breakdown Structure (WBS): Template + Example
• Project Planning and Scheduling: Steps + Example
• Stakeholder Engagement Plan: Steps, Template + Example
• Contingency Plan in Project Management: Template + Example
• Project Closure: Checklist + Closure Report Template