How to Write a Project Status Report (5 Steps)

how to write a project status report is a key topic in modern project management and teamwork. Every project manager knows the feeling: it is Friday afternoon, the status report is due, and the last thing you want to do is reconstruct a week’s worth of work from memory. So you open last week’s report, change a few dates, add “still working on the integration,” and hit send. Your stakeholders read it, learn nothing, and keep asking the same questions in the Monday meeting. This cycle is why most status reports are worthless — they are written as a chore instead of as a communication tool. A good project status report answers three questions in under a page: where is the project relative to the plan, what is at risk, and what do you need from your readers. This guide teaches you how to write one in five repeatable steps, what to put in every section, how to pick an honest RAG status, and how to finish the whole thing in under 30 minutes.

Quick Answer: How Do You Write a Project Status Report?

To write a project status report, fill in five sections in order: overall status (with a red/amber/green indicator), work completed this period, work planned for the next period, issues and risks, and decisions or help needed. Write it from your task list rather than from memory, keep it to one page, and give every issue, risk, and decision an owner and a date. A status report is not a narrative — it is a snapshot that lets a busy stakeholder absorb the project’s health in under a minute and act on what they read.

The nuance: the hardest part is honesty. Most status reports fail because the writer softens the bad news. Specific, dated, and owned sentences beat optimistic generalities every time.

What Is a Project Status Report, and Why Does Writing It Well Matter?

A project status report is a periodic snapshot of a project at a specific moment: where it stands against the plan, what happened since the last update, what comes next, and what is blocking it. It is one of the core outputs of project communications, sitting alongside the project plan as the routine way the project manager keeps sponsors, clients, and team members aligned between formal reviews.

Writing it well matters because projects fail quietly. A team can drift two weeks behind schedule for a month before anyone says the words “we are behind,” and by then recovery is expensive. A good report makes delay visible early, while it is cheap to fix. It is also your evidence trail: when a stakeholder later claims “nobody told me about the vendor delay,” the report is the dated record that they were told, with an owner attached. Done badly, a report actively hurts — vague updates hide problems, waste stakeholder time, and teach readers to ignore you.

What Are the 5 Sections of a Project Status Report?

Use these five sections in this order. They cover everything a reader needs without filler.

1. Overall Status (with RAG Indicator)

One line that states the project’s health and a color. The color — green, amber, or red — summarizes schedule and budget against the plan, with scope, quality, and resources factored in. Include the reporting period and project manager in the header so the report is self-contained.

2. Accomplishments This Period

A short bullet list of what was completed since the last report, tied to a milestone or deliverable. Each bullet names the outcome, not the effort: “Payment integration completed and signed off” beats “worked hard on payments.”

3. Upcoming Work Next Period

The planned work for the coming period with owners and dates. This is what stakeholders use to know what to expect and where they need to unblock you.

4. Issues and Risks

Every problem that could threaten delivery. Separate a risk (something that might happen, gets a probability and mitigation) from an issue (something that has happened, gets an owner and a resolution date).

5. Decisions Needed

The ask: what does the project need from the sponsor, client, or other teams? One sentence per decision, with a due date. Stakeholders read this section first, so make it crisp.

How Do You Write a Project Status Report in 5 Steps?

Follow this order and timebox each part. The whole thing should take 20 to 30 minutes once the project lives in a task list.

Step 1. Fill the header and pick the RAG color from the plan (2 minutes). Check the numbers first: is the project on schedule and within budget against the plan? If the plan says 60% of the work should be complete but only 48% is, that is amber at best. The color follows the numbers, not the team’s mood.

Step 2. Pull completed work from the task list (5 minutes). Do not write from memory. Open the task list and copy every task marked done since the last report, then group them into two to four bullets. If nothing was completed, say so and explain — silence reads as hiding.

Step 3. Copy the next period’s planned work (4 minutes). Take the upcoming week’s assignments with their owners and due dates from the plan. This section should match the plan exactly; if the plan is empty, that is a finding, not an omission.

Step 4. Update the issues and risks list (4 minutes). Add new items, close resolved ones, and keep the wording specific. Every issue gets an owner and a target date; every risk gets a probability and a mitigation. If nothing changed, write “no change” and give one line of evidence — do not copy last week’s text.

Step 5. Write the decisions-needed section last (2 minutes). It forces you to notice what actually blocks the team. If you cannot think of a decision, you are probably not surfacing the real blockers — check the open risks and overdue items again.

What Does a Good Project Status Report Look Like?

Here is a filled example for a mobile app project in week 6 of a 12-week plan.

> Project: Mobile Banking App — Phase 1 > Period: March 23–27, 2026 > Project Manager: Sara Lindqvist > Overall status: Amber — on schedule, budget slightly over, one high-priority risk open > > Accomplishments > – Log-in and account summary screens delivered and signed off (milestone M3). > – Test environment upgraded to the latest backend build (completed March 25). > – User-acceptance-test script drafted; 60% of scenarios written. > > Upcoming work (March 30 – April 3) > – Finish UAT script (owner: Tomás, due Apr 2). > – Begin payment integration with the sandbox (owner: Priya, due Apr 1). > – Client review of account summary screens (owner: sponsor, due Apr 3). > > Issues and risks > – Issue: sandbox credentials from the payments vendor arrived five days late. Mitigation: integration window compressed to 3 days; owner Priya, resolved by Apr 6. > – Risk: if the vendor’s production approval takes longer than 4 weeks, the launch date slips. Mitigation: application submitted now; escalation trigger if no answer by Apr 15. > > Decisions needed > – Approve the reduced UAT scope for non-critical screens (decision owner: sponsor, due Apr 2).

This is one page, it is specific, and every line has an owner and a date. That is the standard to aim for.

How Do You Pick the Right RAG Status?

Assign the RAG color from the two dimensions that matter most to delivery — schedule and budget — then factor in scope, quality, and resources.

Do not let optimism pick the color. If the plan says 60% of the work should be done and only 48% is, that is amber regardless of how good the team feels. A red status delivered honestly and early is more valuable to the sponsor than an amber status delivered two weeks late.

How Long Should a Status Report Be, and How Often Should You Send It?

A status report should fit on one page. If it does not, the extra content is either detail that belongs in a linked issue or agenda, or it is filler. Weekly is the default cadence for active projects because it matches the natural rhythm of most teams and gives stakeholders a predictable beat. Send it at the same time every week — Friday afternoon or Monday morning both work as long as you are consistent. Use monthly for low-activity projects, and escalate to daily or twice-weekly only during a crisis or the final sprint before a hard launch.

Who Should Receive It, and at What Level of Detail?

Send the report to the sponsor, the client or key stakeholders, and the project team. Keep the list small — a report with twenty recipients gets read by two. Match depth to reader: executives get the overall status and the decisions-needed section; the team gets accomplishments and upcoming work so the report doubles as the team’s plan for next week.

What Tools Help You Write a Project Status Report Faster?

Writing from memory is the slowest and least accurate method. The fastest approach is to generate the report where the work already lives, because tasks carry owners, due dates, status, and completion. A few real options cover the spectrum:

• monday.com lets you build a status view from your boards, with color-coded progress and automatic update generation from item activity. The trade-off: the report is as honest as the board — if the team does not update statuses, the report lies.
• Asana offers progress views and weekly-report-style templates that summarize project activity and completion. The trade-off: you still curate the narrative; the tool gives you data, not judgment.
• Wrike and Jira both surface reporting dashboards from live tasks, useful for teams already working inside those platforms. The trade-off: dashboards are not stakeholder-friendly on their own and usually need a written summary attached.
• ProjectManager.com and Smartsheet ship report and status templates with Gantt- or sheet-based data. The trade-off: the templates are starting points, not a substitute for deciding what matters this week.

Whichever you use, the principle is the same: the report should be assembled from real project data, with the project manager adding the judgment — the RAG color, the risk call, and the asks.

How Do Status Reports Help Teams That Work Remotely or Across Time Zones?

For distributed teams, the status report is a substitute for hallway updates. When the team shares a physical office, someone walking past a desk learns that the integration is blocked. Remote teams do not get that signal, so the gap between what the plan says and what is actually happening grows silently. A weekly written report, sent on a schedule everyone knows, becomes the shared heartbeat: it tells remote colleagues and stakeholders what changed, what is coming, and where to unblock — without requiring a synchronous meeting in an inconvenient time zone. In practice, teams that keep the report honest in writing have shorter status meetings, because everyone arrives already informed.

What Are the Common Mistakes in Project Status Reports?

Hiding bad news in vague language. “We are experiencing some delays in the integration” tells the reader nothing. “Vendor integration is 5 days behind; recovery plan in place; decision needed by Thursday” is a report. Write the second sentence.

Writing activities instead of outcomes. “We worked on the landing page, the signup form, and the email setup” does not say whether anything is finished. Report completions: “Landing page shipped and live; signup form in review; email setup blocked on template approval.”

No owners and no dates. “Budget is over” is a statement; “Budget is over by 4%; finance to review mitigation options by Friday” is a report. Every issue, risk, and decision needs an owner and a due date.

Copy-pasting last week’s report. Stakeholders notice, and it destroys the trust the report is supposed to build. If nothing changed, say “no change” with one line of evidence.

Writing from memory instead of the task list. Reports written from memory drift from reality by the second week. Pull the data from the project tool.

Sending it late or skipping weeks. A report that arrives a week after the fact is history, not status. Consistency matters more than polish.

Know This Before You Choose

Before you commit to a status report format or tool, ask yourself:

• Who reads this, and what is the one thing they need to know first?
• Can every section be filled from data I already have, or will I be writing from memory?
• Does the format force an overall status at the top, or will I have to add it myself?
• Are owners and due dates built into the structure?
• Will my stakeholders be able to act on this without asking me follow-up questions?
• If the project slips, will this format make the slip visible early — or hide it?
• How much time am I willing to spend each week, and can the report be assembled rather than written?

How Do You Automate the Status Report Without Losing the Judgment?

The repetitive part of a status report — collecting completed tasks, upcoming work, and open risks — can be automated, but the judgment cannot. Automating data collection saves the project manager an hour a week and, more importantly, keeps the report honest because it reflects the live plan rather than memory. What stays human is the RAG decision, the framing of issues, and the asks. In practice the best workflows do both: a project management platform assembles the factual sections from real tasks, and the project manager adds the color, the risk commentary, and the decisions-needed paragraph.

One option built around exactly this split is Doitify. Doitify is an all-in-one platform for project management, team management, and goal achievement — you turn a goal into a project with tasks, sub-tasks, checklists, and schedules, then manage execution in one workspace. Tasks, owners, milestones, risks, and work reports live in the same place, so the factual parts of a status report are assembled from real data while you add the judgment on top. To be transparent: Doitify is our product, which is why we know its capabilities from the inside. If your project runs longer than a few weeks or has multiple stakeholders, keeping the report attached to the live project is usually worth it; for a one-off client update, a simple document template is perfectly fine.

Conclusion

Writing a project status report is a skill that compounds. Stick to five sections — overall status, accomplishments, upcoming work, issues and risks, decisions needed — pick the RAG color from the numbers, give every line an owner and a date, and keep the whole thing to one page. Pull the facts from your task list instead of memory, send it on the same day every week to a short list of people who act, and never let optimism write the status. If a report takes more than 30 minutes, cut it back — you are writing prose, not reporting. When the project lives in a tool that tracks tasks, owners, and risks, the report stops being a chore you retype and becomes a snapshot you assemble, and that is the difference between a document nobody reads and the one that keeps your project visible. Start with project management that keeps tasks, risks, and reports in one place. Explore Doitify Project Management to see status reporting that pulls itself together from your real work.