Your Project Dashboard Is Lying to You (Gently)

A few weeks back, this blog's Data Analysis category got its first post: Exploratory Data Analysis is an Art. Its argument was simple - raw data needs exploring before you trust it. Look at the distribution, not just the mean. Check for outliers. Understand what's missing before you draw conclusions from what's there.

Most project managers will never run that process themselves. They don't get raw data. They get a project dashboard someone already built for them - a burn-up chart, a velocity graph, a status widget that's either green, amber, or red. Someone already did the exploring. They already picked the summary statistic, the chart type, the time window.

So here's the question that post didn't ask, and this one will:

Who did the EDA on your dashboard? And what did they leave out?

The Project Dashboard that Looked Fine Until it Didn't

Picture a fairly ordinary project burn-up chart. Two lines: total scope, and completed work.

For most of the project, the lines track the way you want - completed work climbing steadily, scope holding roughly flat, the gap between them narrowing on schedule.

Every Monday status meeting, someone points at it and says "on track."

Then, in the final two weeks, two things happen at once: a handful of late-discovered requirements nudge the scope line upward, and the team's completion rate - for reasons that seemed individually minor at the time - slows down.

The gap that had been narrowing for three months suddenly isn't. The chart that looked healthy in every previous meeting now shows a project in real trouble, with no runway left to do anything about it.

Here's the uncomfortable part: the chart wasn't wrong. Every point on it was accurate. It just didn't show what mattered until it was too late to act on it.

That's not a data error. That's a chart doing exactly what it was built to do - and doing it in a way that quietly hid the one thing you needed to see three weeks earlier.

How Averages Flatten the Exact Thing You Need to See

The EDA post made a point of listing mean, median, and standard deviation together, not mean alone - because the average only tells you where the center is, not how much things are moving around it.

Most Project Management dashboards report the average and stop there.

Take average cycle time, or average sprint velocity. A team that closes 20, 22, 19, and 21 points across four sprints has the same average as a team that closes 35, 8, 30, and 7.

Same number on the dashboard. Wildly different teams. One is predictable and healthy. The other is either burning out, blocked intermittently, or being handed wildly inconsistent work - and you cannot tell which from the average alone.

Variance is the part of the story averages are specifically designed to erase. If your dashboard shows you a single number per metric per period, you're seeing the center of the data and none of its spread - which is exactly the piece the original EDA post flagged as essential, and exactly the piece most PM tools quietly drop before the chart ever reaches you.

How Cumulative Charts Hide Deceleration

Burn-up charts, cumulative flow diagrams, "total story points completed" trackers - almost every default chart in a PM tool is cumulative.

And cumulative charts have a built-in visual bias: They can only go up (or flat), never down. That makes them reassuring by construction, regardless of what's actually happening underneath.

A team accelerating steadily and a team quietly grinding to a halt can produce nearly identical cumulative lines for months.

The total keeps climbing either way - it just climbs at a different rate, and rate is exactly the thing a cumulative total visually compresses out of view. You'd need to look at the week-over-week delta, not the running total, to see the deceleration coming. Almost nobody's default dashboard shows you that.

This is the same principle behind the burn-up example above: The total looked fine because totals almost always look fine until the underlying trend has already turned.

Vanity Metrics Make Everyone Feel Good

Some metrics aren't just incomplete - they're barely connected to project health at all, but they're easy to report and satisfying to watch climb.

Tickets closed. Story points completed. Hours logged. Meetings held. Commits pushed.

None of these are meaningless. But none of them, on their own, tell you whether the project is actually going well. A team can close a record number of tickets while shipping the wrong thing.

A team can log excellent hours while spending them on rework nobody asked for.

The useful version of these metrics almost always requires a second number sitting next to the first one:

The left column is what most dashboards default to, because it's easy to count and always trending in a direction that looks like progress.

The right column is what actually tells you whether that progress means anything.

Why this Happens - and it's Not a Conspiracy

None of this is dashboard-builder malpractice. Nobody sits down and deliberately designs a chart to hide bad news.

Default charts in project management software are built to be readable at a glance and reassuring to stakeholders scanning a status page - smooth upward lines, single summary numbers, green-amber-red simplicity.

Those are reasonable design goals. They're just not the same goals as "surface risk as early as possible," and when the two goals conflict, readability usually wins by default.

It's worth connecting this to a different post on this blog - the one on spotting agentic AI dressed up as a marketing feature.

The instinct at play is the same one. A polished surface substitutes for a harder truth underneath, not because anyone's lying, but because the polished version is what gets built and shipped by default. A dashboard that looks calm is more comfortable to look at than one that raises uncomfortable questions every week - so the calm version is what ships, unless someone specifically asks for the other kind.

A Practical Checklist: the PM's Version of EDA

You don't need to run a histogram on your own project data to bring some of that same skepticism to the dashboard you're handed.

A short, non-technical version of the same discipline:

• Ask what's being averaged - and whether the spread matters more than the center. If a metric is a single number, ask what the high and low values behind it actually were.
• Look for the rate of change, not just the running total. Any cumulative chart can be un-flattened by asking, "what did this week alone look like?"
• Ask what the metric would look like if the project were in real trouble. If your honest answer is "about the same as it looks now," it's not a metric that's actually doing any work for you.
• Give the most recent data point extra scrutiny. A chart that's looked healthy for months is exactly the kind of chart that can hide a turn in the final stretch - check the last two or three data points specifically, not just the overall trend line.
• When it matters, ask for the raw or weekly-delta version. Most tools that show you a cumulative chart can also show you the underlying period-by-period numbers. It's one export away, and it's often the difference between finding out in week ten or week fourteen.

To Conclude

Exploratory data analysis, at its core, is a discipline of asking questions before accepting conclusions - checking the distribution before trusting the average, checking for missing values before trusting the summary. Most project managers will never touch raw project data directly. But the dashboard in front of you is somebody's finished analysis, built with defaults that favor a calm surface over an early warning. You don't need a statistics background to ask what it isn't showing you. You just need to ask.

Pick one dashboard you glance at every week. This week, ask it the question it's not designed to answer on its own: what would this look like right before things went wrong - and is that different from what it looks like right now?

Viel Gluck (feel glook)