What a useful weekly status report contains

A weekly status report is the cheapest tool a project has. It costs a few minutes to write and it prevents a surprising amount of trouble. Yet many reports are either too vague to act on or so long that nobody reads them. Here is what we put in ours, based on running ServiceNow and other platform projects.

1. The headline, first. Start with one sentence saying whether the project is on track. If it is not, say so plainly and say why. A reader should learn the most important thing in the first five seconds.

2. What was completed. List what actually finished, in specific terms. “Six of nine catalog items built and tested” is useful. “Good progress on the catalog” is not. On a ServiceNow project, name the process, the module or the integration.

3. What is planned next. Say what will be worked on in the coming week and who is doing it. This lets the customer see that the plan is alive and lets them raise concerns early.

4. Risks and issues. Keep a short list. For each risk, say what could go wrong, who owns it and what is being done. Distinguish risks, which might happen, from issues, which already have. Include the ones that are yours.

5. What we need from you. Many delays are waiting for a decision or an approval. Name each one, who it is waiting on and by when. This is the most useful section for the customer and the one most often left out.

6. Decisions made. Record any decision taken during the week. It saves the argument three months later about why something was configured that way.

A note on AI work. If a project includes an AI feature, add two lines: what was reviewed by a person this week, and whether anything the AI produced was overridden. This keeps accountability visible.

What to leave out. Leave out activity that does not change the customer’s decisions: long lists of meetings, technical detail nobody will act on and reassurance that is not backed by facts.

How long should it be? Short enough to read in a few minutes. If the report is regularly longer than a page, the project probably needs a better dashboard, not a longer report.

The best test of a status report is simple: could the customer make a good decision using only this page? If yes, it is doing its job.