Project Status Reports: Template, Examples and AutomationProject Status Reports: Template, Examples and Automation

A project status report is a short, regular update that tells stakeholders where a project stands against its goal, what has changed since last time, what could go wrong and what decisions they need to make. A good one can be read in two minutes and leads to action. A bad one is a list of everything the team did this week.

Reporting also takes real time. In Wellingtone’s 2026 State of Project Management research, 72% of project professionals said they spend half a day or more each month collating reports, and 44% were somewhat or very dissatisfied with their PMO’s reporting (Wellingtone, 2026).

Below you will find a copyable project status report template, a filled example, clear definitions for green, amber and red, guidance for different audiences and a practical way to cut the manual work. For the fundamentals behind it, see our complete guide to project management.

What a project status report should include

Every section should help a reader answer one question: does this project need my attention, and if so, what should I do? The essentials:

• Header: project name, reporting period, report date, project manager, sponsor.
• Overall status with a reason: one status using agreed definitions, plus a sentence explaining it.
• Summary: two or three sentences on what changed since the last report.
• Progress against milestones: baseline date, current forecast and variance for the key milestones.
• Completed this period: accepted outcomes, not activity.
• Next period: the work and milestones coming up.
• Budget or effort: actual vs plan and forecast at completion, if tracked.
• Top risks and issues: the three to five that matter, with owner and response.
• Decisions needed: what, from whom, by when, and what happens if it is late.
• Scope changes: approved changes and their impact on dates or cost.

Notice what is left out: a full task list, hours per person and a narrative of every meeting. Link to the source for readers who want detail.

Copyable project status report template

Copy this structure into your doc, email or wiki page. Keep the order the same every time so readers learn where to look.

Filled example: IT service desk migration

Here is the template filled in for a mid-sized company moving its internal IT service desk to a new platform. The sponsor is the IT director; the audience is the steering group.

The example works because a busy director can stop after the overall status line, or after decisions needed, and still know what to do. The amber rating is explained, the variance is quantified and the decision has a deadline and a consequence.

Define green, amber and red before you use them

Traffic-light labels are only useful when everyone reads them the same way. Agree definitions at kickoff and print them at the bottom of every report:

Two rules keep the colors honest. First, rate status against the commitment, not effort: a hard-working team that will miss the date is red. Second, never go from green to red in one step without having flagged the risk earlier. If that happens, the reporting process missed something. Some teams also report a separate status for schedule, budget, scope and quality, which helps when one dimension is fine and another is not.

Write for the audience

One set of project data can serve several audiences, but each needs a different cut:

A useful test: if a section would not change any decision this audience can make, cut it from their version.

How to write a status report in 20 minutes

1. 1.Pull the data, do not retype it. Open your project workspace, timeline and timesheet or budget view rather than asking people for updates.
2. 2.Compare against the last report. What moved? Which forecasts changed? Which risks went up or down?
3. 3.Decide the overall status using your agreed definitions, then write the one-sentence reason.
4. 4.Write the decisions-needed section next. If there is nothing to decide, say so.
5. 5.Fill milestones, risks and budget from the source data. Note any data you know is incomplete and who will fix it.
6. 6.Write the two-to-three-sentence summary last, once you know the story.
7. 7.Read it as the sponsor would. Could they act on it in two minutes? Remove anything that does not help.

Keep status evidence-based

• Separate done, in progress and planned. “Login redesign done” should mean accepted, not “developer finished coding”.
• Report forecasts with their assumptions: “Go-live forecast 15 Jan, assuming vendor fix by 20 Nov.”
• Show baseline and forecast side by side. Do not reset the baseline simply to remove variance; record approved changes instead.
• Use a few consistent measures over time, such as milestone variance, budget burn vs work accepted, and open high risks. Our guide to project management KPIs explains which to choose.
• Pull risk entries from a maintained register so the report reflects reality. See our guide to project risk management for how to score and track them.

Reduce manual reporting without losing accountability

Most of the time spent on status reports goes into chasing updates and copying data from one tool into a slide or spreadsheet. That is slow and error-prone. A better pattern:

• Keep tasks, owners, milestones, risks and decisions in one shared workspace so the data is current by default.
• Use dashboards or saved views for the routine numbers: progress, slippage, hours, open risks.
• Let automation or AI draft the factual summary, then have the project manager review it, add judgment and explain exceptions.
• Link the report to the source records so readers can drill down instead of asking for more slides.

Automation should remove transcription, not accountability. A generated summary can list what slipped; it takes a person to say why it matters and what the sponsor should decide. Our guide to AI in project management covers where AI summaries help and where they need oversight. And if your reporting pain comes from data split across four or five products, the hidden cost of tool sprawl is worth a look.

Common status reporting mistakes

• Reporting activity instead of outcomes (“held 12 meetings”).
• Watermelon status: green on the outside, red inside, until it suddenly turns red at the last minute.
• Burying the decision needed at the bottom of a long report, or never asking for one.
• Inconsistent formats, so readers must hunt for information each time.
• Too much detail for executives, too little for the team.
• Forecasts without assumptions, or variance hidden by quietly moved baselines.
• No follow-up on decisions, so the same request appears in report after report.

Close the loop

A report is only useful if something happens because of it. Give each decision a named owner and a due date, record the outcome in your decision log, and update the plan if it changes dates, scope or budget. Start the next report by noting what was decided since the last one. Over a project, patterns in your reports (recurring blockers, always-late approvals, chronically optimistic estimates) are valuable input for planning the next project and for each phase review.

Where QuikProjects fits

QuikProjects is built so the evidence for a status report already exists in the workspace. The executive report shows completion, on-time delivery, slipping work and hours variance team by team, with weekly scorecards and week-over-week change. Planned vs actual hours come from approved timesheets, and the resource report shows who is overloaded. Saved views and CSV export help you assemble a report for a specific audience.

On Premium and Pro, the AI Project Assistant summarizes sprints and flags risks, for example noting that work is on track by points but that a blocked item is likely to slip. Treat that as a first draft: the project manager still adds the narrative, the status rating and the decisions needed.

Frequently asked questions

How often should you send a project status report?

Match the cadence to the pace of change and the audience. Weekly is common for active delivery and client projects; every two weeks or monthly suits executives and slower projects. Send an exception report straight away if status turns red between cycles.

How long should a project status report be?

One page or one screen is enough for most audiences. If it runs longer, move detail into linked source records and keep the report focused on status, changes, risks and decisions.

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

The terms are often used interchangeably. Where teams distinguish them, a progress report focuses on work completed, while a status report covers the full picture: forecast, risks, issues and decisions needed. The template above is a status report.

Should status reports be automated?

Automate data collection and the routine numbers; do not automate judgment. A person should set the overall status, explain variances and make the asks.

The bottom line

A strong project status report is short, consistent and decision-focused. Use agreed status definitions, show baseline against forecast, highlight the few risks and decisions that matter, and pull the facts from a shared workspace instead of retyping them. The time you save on collating can go into the part that actually helps stakeholders: explaining what the numbers mean and what to do next.

Spend less time compiling updates and more time acting on them. Try QuikProjects free for up to 10 users, no credit card needed.

Sources

• Wellingtone, State of Project Management 2026 press release (16 March 2026)
• Wellingtone, State of Project Management research