1. Lead time, split into queue time and work time

Most teams can quote an average delivery timeline. Very few can say how much of it was spent waiting. Break the clock in two: hours of actual work, and elapsed days where a project sat idle waiting on a SME, an approval, or a decision. In most functions the waiting is the larger share.

The split matters because the two problems have opposite fixes. Long work time is a capacity problem you solve with people or scope. Long queue time is a governance problem, and adding designers changes nothing.

2. Estimate-to-actual variance by task type, not by project

Project-level variance usually looks acceptable because overruns in one place get cancelled out by padding in another. The signal lives in the task types.

Benchmarks put stakeholder communication at roughly 1.7× estimate, evaluation work at 1.5×, and LMS deployment at 1.27×, while planning tends to come in slightly under.

Until those multipliers sit inside your estimating templates, every forecast you hand the business carries the same built-in error, and you will keep getting surprised in the same three places.

3. The share of capacity that never came through intake

Track the work that arrived by hallway conversation, direct message, or executive favour.

Most functions absorb a fifth to a third of their hours this way and keep no record of it.

This is the number that defends headcount. “We delivered 40 of the 60 requests and absorbed 30% of our hours in work that bypassed intake” is a credible answer to a hard question. “We were stretched thin” is not.

4. Realistic available hours per person, published

Planning against a 40-hour week guarantees over-commitment.

Across industries, people spend only 35–40% of the day on core task work; the rest goes to meetings, admin, and coordination.

Establish what an actual available project hour looks like on your team, then publish the figure. Precision is not the goal.

A published capacity number turns “can you squeeze this in” into a trade-off conversation, which is a different conversation to be in.

5. Rework rate, and where it originates

Count how often a project re-enters design or review after sign-off, and log what triggered it: a stakeholder who arrived late, a requirement that moved, an objective that was never clear.

Rework never appears in a headcount request, but on most teams it burns more capacity than any single program. Once you can attribute it, you will usually find it concentrates in two or three stakeholder groups.

That makes it a solvable relationship problem rather than a permanent tax.

6. Fully loaded cost per program, including participant time

Most L&D budgets report design, development, and delivery, and quietly omit the largest cost line: the salary hours of everyone sitting in the room.

A two-day program for 500 people is not a $40,000 decision. Once participant time is inside the number, prioritization conversations change character and so does your standing in them.

It also gives you a defensible basis for retiring a legacy program, which remains one of the fastest ways to earn credibility with Finance.

7. What share of the portfolio is evaluated beyond reaction

Not everything warrants deep evaluation. A workable distribution is application-level measurement on 30–50% of programs, business impact on 10–20%, and full ROI on 5–10%.

The value of holding a target is that it forces the selection to happen up front. Programs chosen for impact measurement after launch almost never produce credible data, because no baseline was captured and no target was agreed with the business.