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

What a leader wants is the team's best guess about whether this will land — the judgement that used to travel informally, by corridor and tone of voice, and is the first thing lost when teams distribute and organisations grow. That's a project delivery prediction, and the question that produces it is simple: how confident are you the team will achieve their goal by the deadline? It's answerable in seconds, anchored to a specific outcome, and it moves for reasons that are actually about the work.

A recurring confidence vote from everyone on the team satisfies all five. It isn't a new instrument: it's the SAFe fist of five, asked on a schedule and tracked over time rather than once per planning increment — set out in is there a less painful way to do project status reporting?

One interviewee reached for a different analogy:

"Like vital signs at a project level."

Vital signs don't diagnose anything. They're cheap, continuous, and they tell 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 the team will achieve their goal by the deadline? 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: a project delivery prediction from the people doing the work — the judgement you used to pick up by walking the floor, made current, comparable and visible across every project at once.