The project is slipping and I can't see where.

What to do when a project is slipping and you can't see where

Renton, Washington, the late twenty-tens. Inside Boeing's seven thirty-seven max programme, an engineering reorganisation has been quietly running for years. Engineers who used to report to chief project engineers — the people responsible for the airworthiness of the aircraft they were building — now report to business unit heads. People responsible for production deadlines.

The change is structural rather than visible. Day to day, the engineering work continues. The org chart is the only thing that has changed. The effect of the change, though, is to put production deadlines above quality concerns in the internal hierarchy — and the effect of that is to make it unsafe for engineers to escalate problems.

The MCAS system that will cause the two crashes is built around a single failure-prone sensor. The people who would have flagged that as a design flaw — and there are several — either don't raise it, or raise it to managers who absorb the concern into the system without the information reaching anyone with the authority to act.

Two aircraft go down. Lion Air six-ten, October two thousand and eighteen. Ethiopian Airlines three-oh-two, March two thousand and nineteen. Three hundred and forty-six people die. The global fleet is grounded for over a year.

The lesson isn't that Boeing had bad engineers. They had good ones. It's that the reporting structure had been reshaped in a way that made it costly to tell the truth upwards. The information that would have prevented the disaster was being filtered out of view long before the crashes happened.

When a project is slipping and the manager can't see where, the question is rarely whether the team has the information. The team almost always has the information. The question is whether the reporting structure is shaped to deliver it.

Ask whether the reporting structure is shaped to deliver the truth

So let's go to the office and work through it.

"The project is slipping and I can't see where."

The feeling is drifting.

The dashboards say everything is on track. The status updates are reassuring. The team is working hard. And something, somewhere, is wrong — because the milestones the project should have hit by now haven't moved into your field of vision the way they should have.

When the team is hiding the slip

Two choices. They feel similar. They need different first moves.

Choice one: the team is hiding the slip. The delay is being smoothed over in status updates because someone is worried about what happens when it becomes visible. Not malice. Self-protection. The team has decided, individually or collectively, that the safer move is to keep showing green.

If that's the read, message the team and ask for their advice on where the biggest bottleneck is right now. Not what's gone wrong? — which invites defence. Where's the bottleneck? — which invites diagnosis.

Adam Grant, working on the dynamics of advice-seeking, found that people who are frightened of being blamed for a delay will readily diagnose a system. The diagnosis is what you actually need. The fear stays live, but it stops being the thing running the conversation. The reframe gives the team a way to tell you the truth without having to admit it as failure.

When you're looking at the wrong numbers

Choice two: you are looking at the wrong numbers. The dashboard shows everything green because the dashboard only counts what got finished. The work that didn't get finished is invisible to it. You're measuring the survivors of the system, not the system.

If that's the read, stop looking at completed tasks entirely. Audit only the failed, delayed, or discarded ones.

Nassim Taleb's survivorship bias is doing the work here. The successes are survivors; they tell you nothing about the conditions the system is operating under. The failures are where the information lives, and the information has been filtered out of your view because you've been measuring the wrong side of the ledger.

Hidden, or wrong-numbers. Same project slipping. Two different first moves.

How to expose the slippage first

Three tools. The discipline is to make the delay visible before you try to fix it.

Disaggregate the metric until the slip shows

The first is

KPI Tracking — but in a specific shape.

KPI Tracking as a corporate discipline traces back to Robert Kaplan and David Norton's Balanced Scorecard, formalised in their nineteen ninety-two Harvard Business Review article and the nineteen ninety-six book of the same name. The deeper lineage runs through Peter Drucker's management by objectives tradition of the nineteen-fifties. The contemporary practice — dashboards, OKR systems, executive scorecards — is multi-source.

The reason KPI Tracking matters when a project is slipping is that aggregated metrics are where bad news goes to hide. Top-line KPIs average out operational variance that would be obvious if you looked at the components. The team's average velocity looks fine; the specific tasks five days behind schedule disappear into the average.

The unique insight is that the aggregate is the wrong unit of analysis when you're investigating a slip. The aggregate is the unit of communication; it tells stakeholders the story you want them to hear. The unit of analysis is the disaggregated component, which tells you the story you need to act on. The two units are different. Most teams use the aggregate for both, and slipped projects are the cost.

What you get when you disaggregate is visibility. Not a number; a list. These specific tasks are five days older than they should be. This specific milestone has been moved twice. This specific dependency has been waiting for two weeks. The list is what action plans get built from.

So. How to use it differently.

Pick. Not the headline KPI. The one whose component-level structure exposes the slip. Time-to-merge, time-in-review, days-since-last-deploy, open-defect-age — pick the one whose tail will reveal the delay.

Disaggregate. Don't average. List. Every single instance, ranked by age or duration. The longest tail items go to the top.

Read. The items at the top of the disaggregated list are where the slip is concentrated. Most slips are not evenly distributed; they're clustered. The cluster is the diagnostic.

Act. Each top-item is its own conversation. Why is this older than it should be? What's blocking it? The list directs the work to where it actually needs to go.

The aggregate stays — it does its communication job upward. But the work happens against the disaggregated tail.

Strip the vanity layer and work the raw data

The second is

Analytics and Data Analysis.

Analytics and Data Analysis as a structured discipline traces through the operations-research tradition of the post-war period — Edward Deming and Joseph Juran on statistical quality control, the RAND Corporation on systems analysis — into the contemporary practice formalised in tools like SQL, Tableau, and the modern data-warehouse stack of the twenty-tens. The discipline is older than its tooling.

The reason Analytics matters when a project is slipping is that the vanity layer is doing the team's thinking for them. Most dashboards present numbers as headlines: velocity is up, defects are down, story points completed at record pace. The headlines are reassuring. They are also frequently wrong, because headline framing strips the variance that contains the diagnostic information.

The unique insight is to strip the vanity layer. Velocity-trending-up averages across teams, components, sprints. These specific tasks are five days older than they should be doesn't average across anything. It is a fact about the world rather than a comforting summary.

What you get when you work against the raw data is a different conversation. Not the project is on track — uninformative. Not the project is slipping — alarming. These specific items are slipping by these specific amounts and the cluster is in this specific area. The conversation has somewhere to go.

So. How to use it.

Raw. Not the dashboard. The underlying records — tickets, commits, deploy logs, support cases. Whatever the operational reality is being recorded against.

Filter. Apply the survivor-bias correction. Only the items that are slipping, failing, blocked, or aged. Successes go into a different file you do not look at this week.

Cluster. What do the failing items have in common? Same component? Same dependency? Same author? Same review queue? The clustering is the structural shape of the slip.

Name. The sentence the team needs to hear is the cluster's name. The slip is concentrated in the integration layer. Or the slip is concentrated in tickets that depend on the data team. The named cluster is what the conversation can act on.

Separate the team's slip from the system's

The third is

Performance Monitoring.

Performance Monitoring — APM, application performance monitoring — emerged through the two-thousands as web applications scaled past what manual log-reading could handle. The contemporary practice was formalised by tools like New Relic, founded two thousand and eight, and Datadog, founded two thousand and ten, with the deeper lineage running through telemetry and observability practice in mainframe operations going back to the nineteen-sixties. The discipline is monitoring instrumented systems for behaviour the operators couldn't see otherwise.

The reason Performance Monitoring matters when a project is slipping is that some slips aren't human-workflow slips at all. They are infrastructure slips that look like human slowness because the human team is the visible layer. The team is working full-tilt; the work is being slowed by something underneath that nobody is looking at.

The unique insight is that silent system-level issues tend to look like human slowness until you instrument the system properly. The team is being held responsible for a slip whose cause is sitting two layers below them in the stack. Until the system is instrumented, the human layer takes the blame.

What you get when you instrument is differentiation. The component of the slip caused by the team. The component caused by the infrastructure. The two are different problems with different fixes, and conflating them produces a manager who is fixing the wrong thing while the right thing keeps slipping.

So. How to use it.

Instrument. Not just the application. The whole path the work travels — the source-control system, the CI pipeline, the build infrastructure, the review tooling, the deploy mechanism. Each segment gets a metric on duration.

Compare. What's normal for each segment? If the build pipeline used to take six minutes and now takes thirty, that thirty-minute build is eating multiple hours of human time per day across the team — and the time isn't visible in any human-facing dashboard.

Drift. Most infrastructure slips drift rather than break. The build that's now slow used to be fast. The review queue that's now backed up used to clear daily. The drift is what monitoring reveals; the eye doesn't see it because it happens slowly.

Fix. A slow build is fixed in the build infrastructure, not by asking the team to ship faster. A backed-up review queue is fixed by adding reviewers or simplifying the review process, not by asking authors to write smaller PRs. The instrumentation tells you which layer the fix sits in.

The tool is what stops the manager from fixing the visible layer when the cause is in an invisible one.

A precedent: an instrument the marketing layer can't edit

That's the toolkit. One more story before we close.

The Boeing case at the cold open was about a reporting structure that had been reshaped to filter information out of the executive's view. The story we close with is the structural inverse at a different scale — a chief executive who chose to invest in primary customer-usage data, on the premise that the formal reporting layer she had been receiving was structurally biased toward what vendors want to say, not what customers actually do.

San Francisco, two thousand and twenty-four. Kathleen Barrett takes over as chief executive of Backlight — parent company of media-asset-management platforms Iconik, Wildmoka, and ftrack. The diagnostic problem she walks into is the kind any vendor in a fast-moving category will recognise. The marketing layer the firm has been speaking through is telling customers what Backlight can do. The actual customers are quietly using the product to do something the marketing is not describing.

The slip is not at the project level. It is between vendor-aspirational positioning and customer-actual behaviour at the strategic level — the layer the formal reporting was failing to surface.

Barrett builds a measurement instrument the marketing layer cannot edit. Iconik's internal database holds usage data on more than nine hundred million media assets — what gets uploaded, what gets searched, what gets reused, what sits untouched. Barrett's structural decision is to publish Backlight's strategic story directly out of that data each year, as the Iconik Media Stats Report. The report carries observations the marketing side could not have credibly invented: that despite representing only fourteen per cent of assets, video files consume sixty-four per cent of storage needs; that eleven million AI-powered jobs run through Iconik in two thousand and twenty-five alone; that the customer-base shift is from create more to use what we already have.

Barrett's framing of the discipline, in interview: "We invest in our annual Iconik Media Stats Report because it gives us something genuinely useful to say and it's grounded in how our customers actually work." On AI specifically — the question the entire sector spent two thousand and twenty-four to two thousand and twenty-six over-claiming about: "AI amplifies what's already working. It doesn't fix what isn't." The argument she advances is that the competitive edge in media asset management has stopped being volume and has started being findability, reuse, and governance — a claim her own customers' usage data either supports or doesn't, with the dashboard underneath the report doing the work of forcing the question to be asked honestly.

The deeper point: build a measure of actual customer behaviour

The slip the formal reporting layer was failing to surface at Boeing was filtered out of the executive's view by a hierarchy that had been reshaped to put production above quality. The slip the formal reporting layer is failing to surface at Backlight is the gap between what vendors say and what customers do — and Barrett's response is to build a parallel channel that runs against customer-actual behaviour rather than vendor-aspirational claim. Two scales, two sectors, the same diagnostic root: the formal reporting layer is producing the version of the truth the layer can defend; a parallel channel has to surface the version the layer cannot.

So. Your Next Move from this playbook.

Which behaviour, in your customers' actual day, would your team need to see for your dashboard to be honest evidence that the work is working?