Why doesn't project delivery have a metric?

Every other function got one

Walk through a leadership meeting and notice the asymmetry.

Finance reports revenue, burn, and runway. Precise, agreed, and comparable across periods.

Sales reports pipeline: deals at defined stages with values and expected close dates. Imperfect — every sales leader discounts their own forecast — but it's a standing quantitative view of the future that everyone in the room can read.

Customer success reports NPS or a similar satisfaction measure. Methodologically contested, and still: one question, asked on a schedule, aggregated, tracked over time.

Project delivery reports… a narrative. Occasionally a traffic light attached to the narrative. When someone asks how the platform rebuild is going, the answer is prose, its accuracy depends on who wrote it, and there is no way to compare this month's answer against last month's except by reading both.

An engineering leader in our research described the situation his organisation had reached:

"Reporting out became a complex melange of everyone's metrics. And it's hard to figure out what those metrics are in a growth company."

He ended up hiring an analyst specifically to produce a data and systems report — a full-time role to answer a question other functions answer with a number.

But engineering has loads of metrics

True, and this is where the question usually gets waved away. Story points, velocity, burndown, cycle time, deploy frequency, escaped defects, DORA metrics. Some are genuinely useful.

None of them answers the question leadership is asking.

Every measure in that list describes work that has already happened. Velocity tells you how much the team completed in past sprints. Burndown shows progress against a scope that may itself have been wrong. Cycle time measures how long finished work took to finish. They're lagging indicators, and they're measures of activity rather than of outcome.

The question a leader actually asks is forward-looking: is this going to land, and does it need my help? A VP of engineering responsible for 120 engineers put it exactly that way:

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

No activity metric answers that. A team can be running at healthy velocity into a wall it can already see.

Why the gap persisted

Three reasons, and they're better reasons than "nobody thought of it."

The measurable thing isn't the useful thing. Delivery activity is easy to count and doesn't answer the question. The answer requires a forecast, and forecasts aren't emitted by systems — they exist in people's heads.

The obvious source was already compromised. The natural person to ask is the project manager. But one person's forecast carries their optimism bias and their exposure to the consequences of pessimism, which is the whole reason status reports drift from reality — covered in why status reports don't reflect what's actually happening.

Asking everyone was impractical. The alternative — ask the whole team, regularly, and keep the answers — wasn't feasible when it meant a meeting or a survey. The cost per data point was too high to run weekly, which is exactly why the practices that got closest to this stayed informal: the standup thumb check produces no record, and the niko-niko calendar lived on a whiteboard.

That third constraint is the one that changed. When the response is a single click in a tool the team already has open, the cost per data point approaches zero, and something that was impractical becomes routine.

What a delivery metric would have to be

Working from what the other functions have:

• Forward-looking. About whether the thing will happen, not what has happened.
• Comparable over time. Same question, same scale, same cadence — so this month can be read against last.
• Cheap enough to run continuously. A metric collected quarterly is a report.
• Sourced from people with the evidence. Which means the team, not a summariser.
• Aggregated, not editorial. Arithmetic has no reputation to protect.

What you actually want to measure

It's worth being precise about the target, because it's easy to reach for the wrong thing. What a leader wants is a current read on how the team feels about the work — the collective sense of whether this is going well, which in any healthy organisation exists informally and travels by corridor, tone of voice and who looks tired. That's team sentiment, and it is the thing that has always been lost first when teams distribute and organisations grow.

Sentiment as such is difficult to measure directly and easy to measure badly. Ask people how they feel and you get a mood reading, which drifts with the weather, the commute and last week's reorganisation, and which tells you very little about a specific deliverable.

So Genchi measures a confidence score as a proxy for team sentiment: how confident are you that we'll achieve our goal? That question is answerable in seconds, anchored to a specific outcome rather than a general state of mind, and it moves for reasons that are actually about the work. It's a narrower question than "how are things?" — deliberately — and it captures the part of team sentiment that predicts delivery.

A recurring confidence rating from everyone on the team satisfies all five. It's closest in shape to NPS — one standing question, asked on a schedule, aggregated and trended — though it measures likelihood of an outcome rather than loyalty, and shares none of NPS's promoter-and-detractor arithmetic.

One interviewee reached for a different analogy, and it may be the better one:

"Like vital signs at a project level."

A pulse doesn't diagnose anything. It's cheap, continuous, and it tells you when to look closer — which is precisely the job.

How Genchi does this

One question, every team member, at a cadence you choose: how confident are you that we'll achieve our goal? One to five, about two seconds, in Slack, email or the app.

Aggregated per initiative, tracked over time, rolled up across a portfolio. The output is a number and a direction you can put in front of a leadership meeting — which is what finance, sales and customer success have had all along.

The number is a confidence score. What it stands in for is the team's sentiment about the work — the thing you used to pick up by walking the floor, made current, comparable and visible across every team at once.