How to write a project status report, with a filled client example

Report the current position and the decision needed next

A project status report is a dated snapshot of progress against the agreed plan. It should say what is complete, what is still open, whether the current forecast differs from the baseline and who needs to decide or act next. For a freelance engagement, a short structured message can do this without a dashboard.

Atlassian recommends a clear summary, schedule information, obstacles and accountable next steps. Keep the main report readable without opening every supporting file, then reference the evidence where useful. A list of hours worked is not enough: the client needs to understand delivery and the choices affecting it.

Keep baseline, forecast and actual dates separate

The baseline is the approved comparison plan. The forecast is your current best expectation, based on the information available at the report cutoff. An actual date records something that has happened. Label all three explicitly; moving the baseline every week makes a late project look permanently on time.

A forecast is not an approved change to a contractual commitment. If the client agrees a revised baseline, preserve the previous version and record the approval and reason. Until then, report the original commitment and the new forecast together, including any unresolved consequence.

Use a reporting period and an “as of” timestamp. Someone reading the report on Monday should know whether a Friday decision was included. If an important input is unconfirmed, say so and make the forecast conditional instead of presenting an assumption as a fact.

Use status labels that agree with the evidence

Agree simple definitions before using green, amber and red. For this example, green means delivery is forecast within the approved plan, amber means a material risk needs action but no approved final date is yet forecast to slip, and red means a committed date is forecast to be missed or delivery is blocked. These are illustrative conventions, not universal standards.

Show the reason in words so the meaning does not depend on color. Avoid averaging away a serious schedule problem because budget and scope look healthy. An overall label should draw attention to the material decision, with separate dimensions where useful.

Do not invent a percentage complete by dividing hours spent by estimated hours. Effort consumed and accepted outputs measure different things. Report named versions and states such as submitted, in review, changes requested and accepted. Payment remains a separate financial event, not evidence that the work was approved.

Filled example: a delayed client copy decision

The following report is fictional. Its schedule uses Monday–Friday working days with no holidays or absences during the period. The agreed work is one six-page service brochure; dates refer to the end of the named working day unless a time is stated.

Project: Juniper service brochure | Report 03 | Period: October 5–9, 2026 | As of: October 9, 2026, 16:00 UTC | Author and delivery owner: Lena, studio producer | Client decision maker: Omar | Comparison: baseline 1 approved October 2.

Overall status: RED. Final package acceptance and handoff are forecast for October 19 against the October 15 baseline, a two-working-day slip. Approved copy remains outstanding. The forecast assumes Omar supplies and approves the final copy by the end of October 12; that date is requested, not confirmed. If it changes, Lena will issue a revised forecast.

Completed this period: visual direction version 2 accepted by Omar on October 6, matching the baseline date. Evidence: dated review response referencing that version. Layout template prepared and internally checked on October 7. This does not mean the finished brochure has been accepted.

Open issue I-02: final copy was due October 8 and has not been approved at the report cutoff. Owner: Omar for the copy decision; Lena for schedule coordination. Impact: final layout cannot begin. This is an existing issue, not just a risk that the copy might arrive late.

Schedule: copy approval baseline October 8, forecast October 12, actual not yet recorded. Final layout baseline October 9 and 12, forecast October 13–14. Client review baseline October 13, forecast October 15. Corrections and checks baseline October 14, forecast October 16. Final acceptance and handoff baseline October 15, forecast October 19. None of these future forecasts is an actual completion date.

Decision needed: Omar to confirm the October 12 copy delivery and approval by 12:00 UTC on October 12, and state whether October 19 handoff is acceptable. If the original handoff date is immovable, Lena and Omar must agree a feasible alternative scope and review arrangement before work changes. Silence will not be treated as approval.

Next milestone: approved copy received, forecast October 12, owner Omar, evidence a dated acceptance of the named copy version. Next actions: Lena confirms the layout booking on October 12; Omar confirms availability for the October 15 review. Risk R-04: the shifted review window may not fit the reviewer; Lena escalates if availability is unconfirmed by October 12.

Commercial position: agreed fixed scope and fee unchanged; no additional work or charge authorized. This is not a statement that internal costs are unchanged. Next regular report: October 16; Lena will send an earlier update after the copy decision or if the forecast changes.

Explain the arithmetic without disguising the slip

In the example, copy approval moves from Thursday October 8 to Monday October 12: two working days later, counting Friday and Monday. The five successor working days are two for layout, one for review, one for corrections and one for final acceptance and handoff.

Originally those days were October 9, 12, 13, 14 and 15. The forecast uses October 13, 14, 15, 16 and 19. Final handoff therefore moves by two working days, although four calendar days separate October 15 and 19. Keeping the calendar assumption visible prevents an apparently contradictory update.

The report does not claim the final date has been renegotiated. Nor does it promise that every missing-input delay produces an equal finish delay; available slack, other dependencies and bookings can change that result. This particular forecast assumes the listed durations and resources remain available.

Copy this structure for the next update

Replace each bracketed field with current evidence. Keep internal labor costs or other confidential information in an appropriately restricted record. Include budget information when relevant to the reader, clearly distinguishing the client fee, approved cost budget, actual costs and forecast rather than labeling all of them “spend.”

1. Header: [project], [report number], [reporting period], [as-of time and zone], [author], [baseline version].
2. Summary: [status and reason], [current delivery forecast], [most important change since last report].
3. Evidence: [completed output or milestone], [version], [actual date], [acceptance or checking record].
4. Schedule: [next milestone], [baseline], [forecast and assumptions], [actual if reached], [variance with working/calendar-day unit].
5. Open items: [issue already occurring], [uncertain risk], [impact], [owner], [response or trigger].
6. Decision: [specific choice required], [authorized decision maker], [deadline], [effect if unresolved].
7. Next: [actions and owners], [commercial changes if any], [next report date], [supporting record locations].

Send decisions early and preserve each dated report

Check the update against the latest approval, schedule and issue records before sending. Do not call a submitted draft accepted or carry last week’s resolved blocker forward. Preserve the dated report so a later reader can see what was known at that time.

Use the agreed communication plan for recipients and cadence. An urgent decision should not wait for the next weekly report, and a weekly report should not silently authorize scope changes. Record the resulting decision separately, then show its effect in the next snapshot.