This Week's Status Report Was Extracted, Not Written

There are PMs who spend Sunday night preparing for the 9 a.m. Monday status meeting. Find last week's work in the plan document and copy it over, copy this week's work in after it, align the table, draw the approval boxes. In Part 6 we wrote that deliverables should be extracted, not authored. This piece is that sentence, tested against the real thing.

The material carries straight over from our last case study: the six-month manufacturing ERP project we built with Claude. Forty-four nodes, a 92-day plan (August 3 – November 2), seventeen dependencies — a real project. From that plan we pulled the weekly and monthly reports with one button, and we'll record exactly where the automation ends and the human's share begins.

The precondition — what makes extraction possible

To extract a report, everything that goes into it has to already exist as data. Take a weekly report apart and this is what's inside: the tasks that ran this week, each with its schedule, progress, and owner; the tasks starting next week; the upcoming milestones. All of it is something the WBS and the schedule already know.

The question is where that data lives. If the plan lives in a spreadsheet file, the report becomes another spreadsheet — and Part 2 covered what happens when the original and the copy start disagreeing. In wbsgantt, the WBS, schedule, progress, and owners are one model, so a report can be a view of that model. That is the one precondition extraction needs.

Four sheets from one button

Press Excel export at the top right of the WBS screen, pick your options in the popover, and one file lands: {project-code}_{timestamp}.xlsx. Inside are four sheets, in order.

Overview — a one-page A4 portrait executive summary. Four metric cards on top (overall progress, task count, start, finish), a phase progress table in the middle (weight, duration, schedule, progress), and up to five upcoming milestones with D-Day counters below. Meant to be used as-is as the first page of a steering-committee deck.

WBS — the full plan. Nine columns (code, task, owner, weight, duration, predecessors, start, finish, progress) with a weekly Gantt timeline to the right (five markings: done, in progress, planned, phase span, milestone). Designed for A4 landscape printing, with the table header repeated on every page. This is the appendix you attach when someone wants the whole plan.

Weekly and Monthly — the protagonists of this piece. Dissected below.

One thing worth noting: the sheets follow your account language, not the screen language. A Korean account gets "주간 업무 보고"; an English account gets "Weekly Status Report". If your organization reports in English, switching the account language is all it takes.

Dissecting the weekly report — what fills itself

The weekly sheet is one A4 portrait page. From the top: the title and an approval strip (three boxes — prepared, reviewed, approved), a report header grid (project, code, reporting period, date, author, department), then two tables — this week's results and next week's plan — and finally an issues & requests section.

The auto-fill rules are simple, and simple means predictable.

• The reporting period is the week (Monday–Sunday) containing the generation date. Next week's plan is the week after.
• The results table lists the tasks and milestones whose schedules overlap that week. Summary (phase) rows are excluded — execution units only.
• Each row gets its code, task name, owner, schedule, and progress, and the status is derived from progress — 100% is done, 0% is planned, anything between is in progress, milestones get a ◆.

Let's make it concrete with the ERP project. Pull this file on Monday, September 7, and the reporting period becomes 9/7–9/13; the results table picks up tasks straddling that week, like "requirements review & sign-off" (9/7–9/9), with their progress and owners. The next-week table fills by the same rule for 9/14–9/20. On the overview sheet, the "system go-live" milestone reads D-56. What I did was not compute dates — it was press a button.

The monthly report shares the structure with two differences: the tables become this month's highlights / next month's plan, and a phase progress summary comes first at the top — because in an executive report, "which phase is where" is always the first question.

The blank cells — the boundary between automatic and manual

Which cells are left blank matters as much as which cells fill themselves. The footnote at the bottom of the sheet draws the boundary in one sentence: "Results, plans and progress auto-filled from WBS data · Owner/Notes/Issues are fill-in fields."

This is the same line we saw in the last case study. There, what wbsgantt enforces are structural invariants, while things like 8/80 appropriateness stay as judgment. Reports are no different — the machine pulls the numbers and the lists, but "does this issue go in front of the executives?" and the signature in the approval box are judgment, and no form signs for you.

And there's a ceiling on honesty. An extracted report can never be more honest than its data. If progress has been stuck at 80% for eight weeks (Part 4's lie), the report will print that 80% in a beautifully clean layout. What extraction removes is the time spent making the report — not the honesty of what it reports. That belongs to your progress-measurement rules.

Fit for the occasion — option recipes

The four export options (header tone, row density, long-schedule handling, report forms) combine into distinct uses.

The limits, and a Monday routine

Honestly, then. First, it will not come out in your company's standard template. If the client demands their own form, you still transcribe — though with a single source of truth, you stop hunting for numbers. Second, the machine cannot write your issues and risks. That's less a limitation than a design decision — a tool that auto-fills that section is a tool you should distrust. Third, it's a snapshot. As the footnote's "as of" date says, it reflects data at generation time; next week, you pull it again. You don't edit the file — you edit the data and re-extract. That is the whole point of this way of working.

So the Monday morning routine becomes: ① update last week's progress (this is the actual job), ② press Excel export, ③ handwrite three lines in the issues section, ④ send it up for approval. Of the ten weekly hours Part 6 counted for report production, what remains are ① and ③ — the parts that were the PM's job all along.

Try it yourself

1. On your project's WBS screen, press the Excel export button at the top right.
2. The defaults (navy, normal, auto, weekly + monthly) are fine the first time.
3. Download the .xlsx — check the four sheets: overview, WBS, weekly, monthly. Printing needs no setup; it's A4 as-is (portrait for the overview and reports, landscape for the WBS).

The thesis of Part 2 was that a report starts dying the moment it becomes a copy of the plan. There is exactly one way to avoid making a copy: make the report a view of the data rather than a document. Then the tool isn't writing your report for you — it's deleting the parts that never needed writing. The blank cells that remain are your share, and those blanks are what reporting actually is.