Weekly Status Update Report Structure

Imagine a sponsor who receives one message from your team each week and has only half a minute to read it. That reader is not auditing your calendar. They want to know three things: what changed, what is stuck, and whether anything is about to go wrong. A weekly status update exists to answer those questions quickly.

The format is built around a simple idea: the reader should be able to predict where each answer will appear. Once a reader learns where the blocked items live, they can skip straight to that line. The structure is therefore a reading tool as much as a writing tool. When the structure drifts from one week to the next, the reader has to hunt for information again, and the update stops doing its job.

The template begins with a header line that identifies the customer and the week. After the header come five labeled sections, always in the same order. Each section answers one question the sponsor cares about. Follow the sections in order below and notice that each one hands the reader to the next kind of information: finished work, then requests for action, then insight, then evidence, and finally a forecast.

Each section answers one question. WHAT SHIPPED reports finished work. WHAT'S BLOCKED reports anything that cannot move without help. WHAT WE LEARNED records insight that should influence later decisions. METRIC MOVEMENT shows how the numbers changed. ONE RISK FOR NEXT WEEK names the most dangerous possibility ahead. Because the labels never change, the reader's eye can go directly to the question they came to answer.

Shipped work and blockers share one requirement: specificity. A shipped entry should name the change itself and attach something the reader can inspect, such as a link to a demo, a dashboard, or a pull request. The template's own placeholder reads WHAT SHIPPED followed by a note to give a specific change with a link to the demo, dashboard, or PR. The expected detail is therefore a concrete change plus proof, not a general statement that progress was made.

A blocker is held to the same standard. It must name what is stuck, provide a path to unblock it, and identify an owner who can act on that path. If nothing is blocked, the update should say so explicitly rather than leaving the section blank, because a blank section forces the reader to wonder whether the item was skipped or whether there truly is nothing stuck.

Blockers and risks look similar because both involve things that could hurt progress, but they sit in different sections for a reason. A blocker is stopping work now. A risk might stop work later. Placing each in its correct section tells the sponsor whether the team needs help immediately or needs to watch a possibility over the coming week.

The two also differ in what they ask of the reader. A blocker is a request for action, so the sponsor may need to remove an obstacle. A risk is a forecast, so the sponsor needs to know where attention should go and what the team is doing about it. This is why the risk section is limited to one item with its prevention step, while the blocker section can list every item that cannot move without help.

The lessons section asks for one or two specific things from the week that change how the team should think about the rest of the engagement. The point is not a diary of activity. A lesson is useful only if it would alter a future decision, so each lesson should name the decision it affects.

The metric section compares three numbers for each measure: the current value, the value from last week, and the baseline. For the evaluation suite, the template asks for this week's pass rate against last week's. Showing movement against both a recent point and a fixed starting point lets the sponsor see whether a change is a real trend or just noise from one week.

A weekly update usually fails in predictable ways. The reader may be unable to find the answer they need, or the answer they find may not be something they can act on. The before and after view below shows the same week reported two ways.