Case Study 1: A Bloated Status Update, Made Scannable

A worked example of the chapter's central before/after: taking a status report nobody reads and rebuilding it as an exception-based dashboard. The project and people here are a composite—fictional but realistic.

The situation

Nadia runs a four-workstream platform project and sends a weekly status email to a distribution list that includes her director, two peer leads, and the client sponsor. She is conscientious. She writes a thorough update every Friday. And she has noticed something demoralizing: almost no one responds, and in last week's steering meeting her director asked a question whose answer had been in the email she'd sent that morning. The information was there. It just wasn't findable.

Here is the update she sent:

❌ Before (Nadia's Friday status email — ~290 words): Hi all, here's the weekly status for the Meridian platform project. Overall it's been a productive week with good progress across most areas, though we do have a couple of things to flag.

On the data-pipeline workstream, the team made excellent progress. We completed the migration of the ingestion jobs to the new scheduler, which had been a goal for a few weeks, and we've validated that all the nightly jobs are running correctly on the new system. This puts us slightly ahead of schedule on that workstream, which is great news.

The search workstream is also moving along well. We finished indexing the historical documents and the new search API is responding within our latency targets in testing. We expect to begin the integration testing next week as planned.

On the notifications workstream, we've run into a bit of a challenge. The third-party email provider we'd planned to use has changed their pricing model, and the new pricing would put us about 30% over the budget line for that component. We're evaluating two alternative providers, but this is something we'll need to make a decision on relatively soon because it affects the architecture. We're hoping to have a recommendation within a week or so.

The reporting workstream is the one I'm most concerned about. We discovered that the reporting requirements the client gave us assume a level of data granularity that our current data model doesn't capture, which means either the client needs to relax the requirement or we need to do a fairly significant data-model change that would take several weeks. We really need to get alignment on this with the client soon, as it's potentially a multi-week impact on the timeline.

Infrastructure is all on track, no issues to report. Let me know if you have any questions or want to discuss anything. Thanks, Nadia

Everything is accurate. Everything is honest. And the two items that need a decision—the notifications budget overrun and the reporting data-model problem—are in paragraphs four and five, framed as "something we'll need to make a decision on" and "we really need to get alignment," with no owner and no date. A director scanning on a phone sees a wall of gray and learns nothing actionable in the first screen.

The diagnosis

Run the reverse outline (Chapter 4) on Nadia's email—one line per paragraph:

  1. Overall productive, a couple of flags. (vague headline)
  2. Data pipeline: done, ahead. (green — routine)
  3. Search: on track. (green — routine)
  4. Notifications: vendor pricing change, 30% over budget, decision needed soon. (red — buried)
  5. Reporting: data-model gap, multi-week risk, need client alignment. (red — buried)
  6. Infrastructure: fine. (green — routine)

The skeleton is damning. Three routine items get full paragraphs; two decision-needed items are stranded in the middle with no owner, no date, and hedged verbs ("hoping," "soon," "relatively"). The email weights every workstream equally, which is precisely backward—the two reds should dominate and the three greens should nearly vanish. This is a textbook failure of exception-based reporting (§21.3): the writer spent the most words on the items that needed the least action.

The rebuild

✅ After (the same status, as an exception-based RAG dashboard — ~110 words): ```text STATUS — Meridian platform — Mar 21 Overall: 🔴 Next milestone: Client review — Apr 4

Data pipeline ...... 🟢 Scheduler migration done; nightly jobs validated. Slightly ahead. Search ............. 🟢 Historical indexing done; API within latency targets. Integration testing next week. Notifications ...... 🟡 Email vendor raised pricing → ~30% over budget for this component. Evaluating 2 alternatives; affects architecture. DECISION by Mar 27: pick a provider (owner: Nadia). Reporting .......... 🔴 Client's granularity requirement exceeds our data model → either client relaxes the requirement OR a ~3-week data-model change. DECISION by Mar 25: align with client (owner: Nadia + client sponsor). Infrastructure ..... 🟢 On track.

DECISIONS NEEDED: 1. Reporting granularity — with client — by Mar 25 (timeline risk: ~3 weeks) 2. Notifications provider — by Mar 27 (budget risk: ~30% over) ```

Why the rebuild works

The word count fell from ~290 to ~110, and the useful content rose. Specifically:

  • The headline does the work. "Overall: 🔴" tells the director, before they read a single workstream, that this week needs their attention. Nadia's original "productive week with a couple of things to flag" actively understated two timeline-and-budget risks.
  • The greens vanish into one line each. Data pipeline, search, and infrastructure are confirmed present and fine, costing the reader no attention. In the original they consumed three of six paragraphs.
  • The reds carry the story and the decision. Each problem states what it is, what it affects, and—crucially—the decision required, with an owner and a date. "We're hoping to have a recommendation within a week or so" became "DECISION by Mar 27: pick a provider (owner: Nadia)."
  • The "Decisions Needed" block is a gift to the executive. Both decisions, their deadlines, and their risks are pulled into one place at the bottom. The director can now walk into the steering meeting knowing exactly the two things that need them—and they can't miss them, because they're not buried in prose.

The test from §21.3 confirms the fix: hand the dashboard to someone who's never seen the project and ask, "What needs attention, and by when?" From the "after," they answer in seconds—two decisions, by the 25th and the 27th. From the "before," they'd still be reading paragraph four.

The takeaway

Nadia didn't work less or hide anything. She re-sorted the same facts by what the reader had to do with them, compressed the routine, and surfaced the exceptions with owners and dates. That single re-sort is the difference between a status report that gets skimmed and forgotten and one that drives the steering meeting. The format isn't decoration—it's the message.

Try it yourself: Find a status update you sent in the last month. Reverse-outline it (one line per paragraph), label each line green/amber/red, and check: do the reds lead, and do the greens nearly disappear? If not, rebuild it as a dashboard. You'll almost always cut the length in half and double the clarity.

Back to: Chapter 21 · Exercises · Case Study 2