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

Force one: the person writing it is subject to documented biases

This isn't a criticism of project managers. These are among the most reliably reproduced findings in behavioural research, and the people affected are usually experienced and conscientious. The effect on reporting has been measured directly: in a survey of software project managers, status reports were biased around 60% of the time, and the bias was twice as likely to be optimistic as pessimistic. The most common reason for optimistic bias was reluctance to give management bad news.

The major biases, each documented:

• Optimism bias — expecting better outcomes than experience justifies: overestimating the positives and underestimating the negatives. Flyvbjerg (2021)
• The planning fallacy — underestimating how long remaining work will take, even with direct experience of similar work taking longer. Knowing about it doesn't remove it. Buehler, Griffin & Ross (1994)
• Anchoring — once a date is committed, every later estimate clusters around it rather than being formed fresh. Flyvbjerg (2021)
• Escalation of commitment — the more invested in a plan, the harder it is to be the person who says it isn't working. Staw (1976)
• Strategic misrepresentation — status deliberately shaded, because a realistic picture would bring scrutiny or interference. Cognitive bias is half the story; political bias is the other half. Flyvbjerg (2021)
• The mum effect — reluctance to pass bad news up the chain. Evidence of impending failure may be apparent to those closely involved, yet fail to be communicated up the hierarchy, or arrive substantially distorted. Smith, Keil & Depledge (2001)
• The deaf effect — its mirror: reluctance to hear bad news, which lets troubled projects escalate. Between the two, a report is filtered twice before anyone acts. Nuijten, Keil & Commandeur

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 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.

Why better tools haven't fixed it

None of this is new. It's known, acknowledged and documented — and almost every organisation still runs some version of the same process. Project management tools are good at recording work: tickets, estimates, dates. But the status field in every one of them is written by the same person, under the same pressures, and a dashboard built on it inherits every bias above. It just displays the watermelon status report more attractively. A better format can help with the second force. Nothing about the tool touches the first, while there is only one estimator — and it's the person accountable for the date.

How Genchi approaches it

Genchi takes a different route. Instead of trying to correct one person's bias, it stops relying on one person. It replaces the written status update with a single question asked of everyone doing the work: how confident are you the team will achieve their goal by the deadline? Answered one to five, in about two seconds, at a cadence you set. The result is a project delivery prediction from the people doing the work, not a forecast from the one person accountable for the date.

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.

References

• Snow, A.P., Keil, M. & Wallace, L. (2007). The effects of optimistic and pessimistic biasing on software project status reporting. Information & Management, 44(2), 130–141.
• Flyvbjerg, B. (2021). Top ten behavioral biases in project management: an overview. Project Management Journal.
• Buehler, R., Griffin, D. & Ross, M. (1994). Exploring the “planning fallacy”: why people underestimate their task completion times. Journal of Personality and Social Psychology, 67, 366–381.
• Staw, B.M. (1976). Knee-deep in the big muddy: a study of escalating commitment to a chosen course of action. Organizational Behavior and Human Performance, 16(1), 27–44.
• Smith, H.J., Keil, M. & Depledge, G. (2001). Keeping mum as the project goes under: toward an explanatory model. Journal of Management Information Systems, 18(2), 189–227.
• Nuijten, A., Keil, M. & Commandeur, H. Collaborative partner or opponent: how the messenger influences the deaf effect in IT projects.