drafty

Project status report template

A project status report answers three questions: are we on track, what's blocked, and what happens next. Ask your agent to draft it, share the link, and skip the email chain.

What it is
A project status report is a regular snapshot — usually weekly or monthly — that tells stakeholders whether the project is on track, at risk, or off track, what was accomplished, what's blocked, and what comes next. It is not a task list and it is not a post-mortem.

Most status reports fail at distribution, not content. A PM spends 45 minutes assembling the update, emails it as a PDF or a Google Doc link, and half the recipients open the wrong version — or don't open it at all. The meeting to discuss the report takes longer than writing it. Draft it with your agent, publish to a Drafty link, and stakeholders leave comments on the exact line rather than replying-all to the thread.

Generate it with your agent

Paste this into Claude, Cursor, or any agent — it drafts the status report and publishes it as a Drafty link your team can comment on inline:

claude
Draft a project status report for {project name}. Include: (1) Status — on track / at risk / off track with a one-line reason; (2) Summary — 2–3 sentences on where things stand this week; (3) Milestones — what was completed, what's coming up, and any date changes; (4) Blockers — each one named with an owner and what's needed to unblock; (5) Budget — current spend vs. plan if relevant; (6) Next steps — 3–5 actions, each with an owner and a due date. Then publish it to Drafty so I can share a link and collect inline comments — no account needed to reply.

See it on a real one

Live canvas — comment on any elementOpen ↗

What goes in a project status report

Six sections. The goal is a stakeholder who can make a decision in two minutes.

  1. Status — one signal: on track, at risk, or off track. Add a single sentence explaining why. This is the headline — put it first, not buried on page two.
  2. Summary — two to three sentences on overall progress. Written last; summarizes what follows.
  3. Milestones — what was completed since the last report, what's due before the next one, and any slipped dates with a new target. Dates only; skip the narrative.
  4. Blockers — a blocker without an owner is just a complaint. Each entry needs: what's blocked, who owns it, and what decision or input is needed to move. If a blocker needs the reader to do something, say so explicitly.
  5. Budget — current spend versus plan, and a brief note if the variance is material. Skip this section if it doesn't apply; don't pad with zeros.
  6. Next steps — three to five actions, each with a named owner and a due date. "Team to align on approach" is not a next step.

The one section most status reports get wrong

The status field. "On track" when the schedule just slipped two weeks is a credibility problem — stakeholders notice the gap between the signal and the reality, and then they stop trusting the signal. Use "at risk" the moment you see a threat to the timeline or budget, not after it's confirmed. Stakeholders would rather be alerted early and have it resolve than be surprised by a miss.

The same principle applies to blockers: the most expensive status reports are the ones that list issues but don't name what the reader needs to do. "Legal review pending" is noise. "Legal needs the vendor agreement by Thursday to stay on schedule — flagged to Sarah" is a decision.

How often to send a status report

Weekly for active projects where things are changing fast. Monthly for long-running initiatives where the big picture matters more than weekly deltas. The right cadence is whatever eliminates the check-in meeting — if stakeholders are still pinging you for updates between reports, shorten the interval.

Pick a day and stick to it. Inconsistent timing forces people to check whether a new report exists; a predictable cadence means they know when to expect it.

FAQ

What should a project status report include?

At minimum: an on-track / at-risk / off-track status with a one-line reason, a short summary, milestone progress, current blockers with owners, and next steps with due dates. Budget and resource status are worth adding when there's a variance worth flagging. Keep it to one to two pages — anything longer tends to go unread.

How long should a project status report be?

One to two pages for most projects. Executive stakeholders need the status, summary, and key blockers — they rarely read past that. If your audience is the delivery team rather than leadership, you can go deeper on milestones and next steps. Adjust length to what your audience will actually finish, not to what feels thorough.

What's the difference between a status report and a progress report?

A status report captures how things stand right now — it's a snapshot. A progress report documents what has been accomplished over a period of time. In practice the terms are used interchangeably, but if you're writing for executive stakeholders, "status" is usually the right frame: they want to know where you are and whether action is required, not a historical summary.

How do I report status when the project is behind?

Name it clearly: "off track" or "at risk." Then explain what happened, what the revised timeline is, what options exist to recover (more resources, reduced scope, extended deadline), and which option you're recommending. A bad status delivered honestly with a plan tends to go better than a vague status that eventually surprises people. One straightforward paragraph beats three paragraphs of context-setting before you get to the problem.

Who should receive the project status report?

Anyone who needs to make a decision about the project or is accountable for its outcome. That usually means the project sponsor, the key stakeholders, and any team leads who aren't already in the weeds. Don't send it to everyone — a long distribution list means nobody feels responsible for acting on it.

Can I use AI to write a project status report?

Yes — the agent can structure the report, draft the summary, and format the milestones and next steps. What it can't do is fill in the actual data: the milestone dates, the real blocker details, the budget figures. Use the prompt above as a starting frame, then fill in what only you know. The draft takes under a minute; the filling-in is the part that takes judgment.