Why do status reports not reflect what's actually happening?

Force one: the author's own estimates are biased

This isn't a criticism of project managers. It's one of the most reliably reproduced findings in behavioural research, and the people affected are usually experienced and conscientious.

Optimism bias is the general tendency to expect better outcomes than base rates justify. Applied to delivery, it means a plan is more likely to describe the version of events where things go reasonably well.

The planning fallacy is sharper and more specific: people underestimate how long a task will take even when they have direct experience of similar tasks taking longer. Knowing about the effect doesn't remove it. Someone who has watched three integrations slip will still estimate the fourth optimistically.

Anchoring compounds both. Once a date is committed, subsequent estimates cluster around it rather than being formed fresh. The original number, produced when least was known, exerts a pull on every assessment that follows.

Escalation of commitment keeps that pull in place as evidence accumulates against it. The more that has been invested in a plan, the harder it becomes to be the person who says it isn't working.

Bent Flyvbjerg's work on large projects adds one more, and it's the least comfortable: strategic misrepresentation, where estimates are shaded deliberately because a realistic number would not get approved. A developer we interviewed described the everyday version:

"Everyone wants to be green. Executive sponsor wants to look good."

Now note what a status report is: a forecast, produced by one person, who is subject to all five of the above, about a project they are responsible for. Even filled in with complete honesty, it inherits every one of those distortions.

Force two: the format strips out doubt

The second problem isn't the author, it's the container.

Most reporting formats ask for two things: what happened, and a status. Both reward defensible content. "The vendor API returns malformed responses under load" is a fact anyone can verify. "I have an uneasy feeling about the integration" is not, and putting it in writing invites a question the author may not be able to answer.

So uncertainty gets dropped, or hardened into something smaller and firmer. Which is unfortunate, because uncertainty is the early signal — by the time a concern is defensible enough to write down, it's usually also a schedule impact.

Traffic-light status makes this worse by quantising a continuous quantity. A team lead who was 90% confident last month and is 70% confident today has nowhere to put that. A project manager described the consequence:

"Switching a ticket from green to yellow is such a big step change that it sets off all the alerts. There is a cost to calling out problems."

Faced with overstating confidence or triggering an escalation, most people wait a week to see if it resolves. Frequently it does. When it doesn't, the same logic applies again — which is how a project stays green until a fortnight out.

Force three: it's old when you read it

A weekly report describes a state that is up to seven days stale by the time it's read, and often longer, because the author assembled it from information they gathered over the preceding days.

One engineering leader summarised why that matters even on short cycles:

"We do weekly deliveries, but even at that, on Wednesday I want to know if we're on track."

Projects don't change state on reporting boundaries. The gap between when something goes wrong and when the format allows it to be reported is dead time, and it's exactly the period in which cheap intervention is still possible.

The compounding problem: reports get heavier

Each of the three forces above is present on day one. A fourth arrives over time.

"It started out good, but any single source of truth gets a lot of extra data added to it. It used to be a two-line update every two weeks — then it got super complicated." — group project manager, 180–200 engineers

Nobody sets out to make status reporting expensive. An executive asks a question the format didn't answer, so a field is added. Repeat quarterly for two years. The result costs an hour a week and answers questions nobody is asking any more — and a form that costs an hour gets filled in with less care, not more.

Meanwhile the audience quietly stops reading. A developer's assessment of his organisation's status tool:

"Doubt anyone read it."

And the reports that are read aren't necessarily wanted in that form. A VP of engineering responsible for 120 engineers:

"Don't care about the words. I want to know if I'm in trouble or not. Does he need my help or not?"

What would have to change

Working backwards from the three forces gives a fairly specific list.

• More than one estimator. Individual estimation bias is difficult to correct in an individual. Aggregating several independent assessments doesn't eliminate it, but it stops one person's optimism being the whole picture.
• A format that can carry degree. Something where "somewhat less confident than last week" is expressible as a small movement rather than a category change with consequences attached.
• A cadence that isn't weekly prose. Frequent enough to be current, cheap enough that frequency doesn't create a burden.
• Aggregation that isn't editorial. Arithmetic has no reputation to protect. See why bad news gets softer as it travels up.

How Genchi approaches it

Genchi replaces the written status update with a single question asked of everyone on the team: how confident are you that we'll achieve our goal? Answered one to five, in about two seconds, at a cadence you set.

That addresses the three forces directly. It has many estimators rather than one. The one-to-five scale carries degree, so a small loss of confidence is a small movement rather than an alarm. And because responding costs seconds rather than an hour, it can run frequently enough to be current.