Software project status reports that clients actually read

A status report clients actually read fits on one page, arrives on the same day every week and starts with the decisions they need to make. It links to the detail instead of copying it, and a demo of working software backs it up. Reports go unread when they describe activity instead of progress, or hold back bad news until it can't be hidden.

Why most status reports go unread

The same problems turn up in the reports of projects that drift:

• Long lists of tasks worked on, with no link to milestones or goals.
• Every status green, week after week, until the project is suddenly red.
• Risks mentioned once and never followed up.
• Decisions buried halfway down the page, so nobody makes them in time.
• A different layout each week, so the reader has to work out what changed.

A one-page weekly status report template

Use the same headings in the same order every week. Each section should take less than a minute to read.

1. Overall status, with one sentence of explanation. For example: 'Amber: sandbox access for the payment provider is two weeks late, which puts the next milestone at risk.'
2. Decisions needed from you. Each one with an owner and the date it is needed by.
3. What shipped this week. Linked to the tickets, release notes or demo recording.
4. What is planned for next week. Kept short, and in priority order.
5. Milestone tracker. Each upcoming milestone with its planned date, its current forecast and whether it has moved since last week.
6. Top risks and issues. The three or four that matter, and what is being done about each. Everything else lives in the RAID log.
7. Quality. Open defects by severity, failed builds and anything blocking a release.
8. Budget or capacity. Spend against plan for a fixed or phased project, or team changes for a monthly team.

Decisions go near the top for a reason. A decision the reader has to hunt for usually gets made late, and a late decision moves the plan as surely as late code does.

Demos: show working software, not slides

A report says what happened. A demo shows it. Hold one at the end of every sprint or milestone, in a real environment, run by the people who built the feature.

• Show the feature working end to end, including at least one error or edge case.
• Say what isn't finished yet, so nobody mistakes a prototype for a release.
• Record it for anyone who couldn't attend.
• Log new requests as backlog items rather than agreeing to them in the room. Our post on managing scope creep explains why that matters.

On our project delivery work, clients get weekly updates, working demos, milestone reviews and risk tracking, with a named owner for every decision.

Keep a RAID log alongside the report

A RAID log is one shared list of a project's risks, assumptions, issues and decisions. The weekly report shows the top items. The log holds all of them, with their history.

• Risks are things that might happen and would hurt the plan. Record the likelihood, the impact, an owner and the action being taken.
• Assumptions are things the plan depends on that nobody has confirmed yet, such as 'the client's existing API supports bulk updates'. Each one needs a date by which it will be checked.
• Issues are risks that have already happened. Record the impact, the owner and when it should be resolved.
• Decisions record what was decided, by whom, when and why. Months later, when someone asks why the system works the way it does, this is where the answer is.

Keep the log somewhere both teams can edit, such as a page in your Jira or Confluence, not an email attachment. Review it in the weekly call, and close items on purpose rather than letting them go quiet.

RAG status, reported honestly

Red, amber and green only help if everyone agrees what they mean. Write the definitions down at kickoff:

• Green: on track for the next milestone, and no help is needed.
• Amber: at risk. The team has a plan to recover, but the date, scope or budget could move, and something may be needed from the client.
• Red: the milestone or budget will be missed unless the client makes a decision.

The usual failure is 'watermelon' reporting: green on the outside, red inside. It happens when amber feels like admitting failure. Make amber normal. A project that turns amber early, with a recovery plan, is far easier to rescue than one that jumps from green to red the week before a deadline.

We report risks as quickly as wins. Clients can also talk to our engineers directly and see the project tools and progress at any time, so the weekly report is never their only view of the work.

An escalation path agreed at the start

Escalation shouldn't feel like a complaint. Agree the route in the first week, so either side can use it calmly:

1. Team level. The delivery lead and your product owner try to resolve the problem within an agreed time, such as two working days.
2. Management level. If it is still open, it goes to a named manager on each side, with the options and their cost written down.
3. Sponsor level. If it affects the contract, the budget or a major date, it goes to the executive sponsors on both sides.

Also write down what triggers an escalation, such as a milestone moving by more than a week or a blocker staying open past an agreed time. Then nobody has to judge whether something is serious enough. If your teams work in different time zones, agree when escalations can be raised outside shared hours; our post on managing an offshore team across time zones covers the wider rhythm.

Where to start

Cut your current report down to the eight headings above. Agree RAG definitions with your partner, open a RAID log and put a demo in the calendar at the end of each sprint. If you want a few numbers to sit alongside the report, read software delivery metrics for business leaders.

To talk through how reporting would work on your own project, book a free 30-minute call.