Benchmarks
Project Execution Benchmark: state clarity, handoffs, exceptions, and completion
Benchmark project execution using visible state, ownership, dependency, and completion evidence.
Executive summary
Measure the operating outcome, not the AI activity.
Project tooling measures tasks. This benchmark measures execution: whether the true state of the work is visible without asking someone, whether every open item has a real owner, how long work waits at handoffs, and whether completion means an accepted outcome rather than a checkbox someone ticked.
The problem
What Project Execution Benchmark is trying to fix.
Project management tools are excellent at recording intent and poor at reflecting reality. A board can show a healthy distribution of cards while the actual state of the project lives in a status meeting, a private message thread, and the memory of two people. The gap is rarely deliberate; updating a task is unrewarded work, so the record drifts from the truth in exactly the periods when the project is busiest and the record matters most.
The most expensive form of that drift is ownership ambiguity. An item marked in progress with a team rather than a person assigned is, operationally, unowned. Work sits at handoff boundaries -- waiting for review, waiting for a decision, waiting for another team to pick it up -- and this waiting time typically dwarfs the working time. Because tools measure task age rather than wait time at a boundary, the largest source of delay is the least visible thing on the board.
Completion suffers from the same weakness. A task marked done may mean shipped and accepted, or it may mean handed to someone else, or it may mean abandoned and closed to clean up the board. Without acceptance evidence attached to completion, velocity charts measure card movement. Benchmarking on state clarity, real ownership, handoff wait time, exception visibility, and accepted completion measures whether the project is actually executing.
A further distortion comes from planning artefacts that are never revised. A plan is built at the point of least information, approved, and then treated as the reference against which progress is reported for months. Because revising it is socially expensive, teams report against the original dates long after everyone privately knows they are wrong, and the board becomes a performance rather than a record. The measurable symptom is a project that reports amber for a long period and then jumps directly to red, which is almost always a reporting artefact rather than a sudden change in the work.
Underneath that sits the estimation problem, which no amount of tooling resolves. Estimates are produced by people who will be held to them, which reliably biases them, and then aggregated as though the errors were independent. What a benchmark can do is stop treating estimate accuracy as the primary signal and measure instead the things that are observable without forecasting: how long work waits at boundaries, how many items are unowned, how often an item stalls, and whether completion produced accepted output.
Architecture
How UbiVibe measures this.
Each benchmark dimension maps to a stage of connected execution, so the measurement comes from running the workflow rather than from a survey about it.
Step 01
State derived from connected systems
Where possible, work state is inferred from the systems where the work actually happens -- code repositories, document tools, ticketing, calendars -- rather than from manual status updates. Derived state drifts far less than reported state, which is the main reason the benchmark treats manual-update dependence as a risk indicator.
Step 02
Single accountable owner per item
Every open item resolves to one person who is accountable now, with team assignment treated as unowned. This is a deliberately strict rule, because the benchmark's ownership dimension exists to surface exactly the items that everyone assumes someone else is holding.
Step 03
Dependency and blocker modelling
Cross-item and cross-team dependencies are recorded explicitly so that a blocked item is distinguishable from a slow one. Distinguishing those two is what allows wait time to be attributed to a boundary rather than being absorbed into general task duration.
Step 04
Handoff instrumentation
Every transition between owners or teams is timestamped on both sides, making wait-at-boundary a first-class measurement. In most projects this reveals that the largest recoverable time is not in execution speed but in queues that nobody was watching.
Step 05
Exception surfacing
Items that stall beyond a defined threshold, lose their owner, or depend on something closed are raised automatically rather than discovered at a status meeting. ARIA can summarise the current exception set in business language so the review starts from the problems rather than from a walkthrough of the board.
Step 06
Acceptance evidence at completion
Completion requires stated acceptance -- the deliverable exists, the reviewer signed off, the outcome was confirmed -- recorded with the item. This is what makes completion rate a measure of delivered work rather than of board hygiene, and it is the dimension most project tooling leaves entirely to convention.
Step 07
Stall detection with thresholds
Items that have not moved within a defined period for their type are surfaced automatically rather than discovered at a status meeting. Stall thresholds are set per work type because a two-day pause means something different for a support fix than for a procurement decision, and a single global threshold produces noise nobody reads.
Step 08
Plan revision as a recorded event
When dates or scope change, the revision is recorded with its reason and date rather than silently overwriting the previous plan. This preserves the ability to see how a project actually evolved, and it removes the incentive to keep reporting against a plan everyone already knows is obsolete.
Methodology
Rule 1
Define the business outcome and the start/end state before measuring activity.
Rule 2
Use first-party runtime, workflow, connector, and product evidence where available.
Rule 3
Separate observed measurements from estimates, modeled scenarios, and qualitative interpretation.
Rule 4
Do not publish a benchmark value until its source, population, period, and calculation are reproducible.
Rule 5
Retain human review for consequential financial, legal, clinical, employment, coverage, or other material decisions.
Measurement framework
Five dimensions worth measuring repeatedly.
Outcome completion
Qualified intents that reach the expected business outcome
Activity counts do not prove that the workflow delivered value.
Cycle time
Elapsed time from trigger to completed outcome
Faster completion is one of the clearest benefits of connected execution.
Human intervention
Manual touches, approvals, retries, and escalations per completed outcome
Automation should reduce avoidable work without removing appropriate oversight.
Exception rate
Runs that leave the expected path or require recovery
Exception frequency exposes brittle workflows and poor context.
Data provenance
Share of material decisions supported by current authoritative sources
AI output quality depends on trusted operating context.
Examples
Project Execution Benchmark in practice.
Concrete situations this framework is designed to resolve. Scenarios are illustrative operating patterns, not customer case studies.
A green board and a late project
Status reporting looks healthy while delivery slips. Measured on state derivation, most items were last updated manually more than a week before, and the real state lives in a weekly meeting. The benchmark identifies manual-update dependence rather than team performance as the constraint, which changes the intervention entirely.
Eleven items owned by a team, not a person
An ownership audit finds a cluster of items assigned to a group. All eleven have been static for weeks, each assumed to be someone else's. Reassigning to individuals moves most of them within days, which is why the benchmark counts team assignment as unowned rather than as partially owned.
Wait time exceeding working time three to one
Handoff instrumentation shows work spends far longer awaiting review than being done. No individual is slow. The recoverable time is entirely in the queue, and a review-scheduling change outperforms any productivity effort aimed at the people doing the work.
Done that meant handed over
A workstream reports completion while the receiving team considers nothing delivered. Requiring recorded acceptance at completion surfaces the disagreement in the week it occurs rather than at the end of the quarter, when the cost of the misunderstanding has fully compounded.
Amber for eight weeks, then red overnight
A workstream reported amber while its dependencies slipped and jumped to red the week before a deadline. Nothing changed suddenly; the reporting had simply stopped reflecting the work. Stall detection and recorded plan revisions surface that drift continuously rather than at the point where recovery options have already closed.
A dependency on a closed item
Two items were blocked by a third that had been closed as duplicate months earlier. Nobody noticed because the blocked items still showed a valid dependency. Explicit dependency modelling with validity checking turns this into an automatic exception rather than a discovery during an escalation.
Estimate accuracy chased for a year
A team invested heavily in improving estimation and accuracy barely moved. Measuring wait at handoff boundaries showed most variance came from queues outside the team entirely. Redirecting effort from forecasting to boundary management produced the improvement estimation work never could.
Completion that nobody had accepted
A quarter of items marked done had no recorded acceptance, and a sample review found several the receiving team considered incomplete. Requiring acceptance evidence for items above a size threshold made the gap visible weekly rather than at a quarter-end review.
What to do next
Recommended actions.
Action 01
Measure one bounded workflow first.
Action 02
Record the baseline and evidence period.
Action 03
Compare like-for-like workflows and populations.
Action 04
Treat modeled ROI separately from observed outcomes.
Limitations and evidence standard
What this benchmark does not claim.
- This page publishes a benchmark definition, not values. No velocity, cycle-time, or completion figures are presented as observations, and any released figure will carry its source, population, period, and calculation.
- Derived state is only as good as system coverage. Work happening in tools that are not connected, or in conversations, will still depend on manual updates, and the benchmark should state which portion of state is derived versus reported.
- Strict single-owner accounting can feel punitive if used for individual performance assessment. It is designed to surface unowned work, and using it as a personal metric reliably corrupts the data it depends on.
- Handoff wait time is comparable within a similar delivery process only. Teams with deliberate batching or scheduled review cycles will show structurally higher wait that is not necessarily waste.
- Acceptance evidence adds friction at completion. For very small items the overhead can exceed the value, so a threshold for which items require recorded acceptance should be set and stated rather than applied universally.
- Stall thresholds are a tuning exercise. Set too tight they generate noise that teams learn to ignore, which is worse than no detection at all, and the right values differ by work type and team.
- Recorded plan revisions can be misread as instability by stakeholders unused to seeing them. The alternative -- silent overwriting -- hides exactly the information a sponsor needs, so the practice usually requires an explicit conversation before it is introduced.
- The benchmark measures execution mechanics, not whether the project should continue. A well-executing project delivering something the business no longer needs will score well, and that judgement belongs to a separate review.
FAQ
Questions about Project Execution Benchmark.
Why treat team assignment as unowned?
Because operationally it behaves that way. Items assigned to a group stall far more often than items assigned to a person, since nobody holds individual accountability for the next action. The rule is strict deliberately: its purpose is to make that invisible category visible, not to describe how teams collaborate.
What is the difference between derived and reported state?
Derived state is inferred from the systems where the work happens -- a merged change, a signed document, a completed booking. Reported state is a person updating a card. Reported state drifts most in exactly the busy periods where accuracy matters most, so the ratio between the two is itself a useful health signal.
Why measure wait time at handoffs separately?
Because it is usually the largest recoverable component of delivery time and the least visible. Task-age metrics blend working and waiting together, which pushes teams toward individual productivity interventions when the actual constraint is an unwatched queue at a boundary.
What counts as acceptance evidence?
A recorded confirmation that the intended outcome exists and was received: a reviewer sign-off, a deliverable link, a confirmed handover. It does not need to be heavyweight. The requirement is that completion points at something inspectable rather than at a status field someone changed.
Why measure wait time instead of improving estimates?
Because wait time is observable and estimates are forecasts made by people accountable for them. Most delivery variance in multi-team work comes from queues at boundaries rather than from mis-sized tasks, so measuring the queue produces improvement that estimation effort reliably does not.
What does the amber-then-red pattern indicate?
Almost always a reporting artefact rather than a sudden change. Status held steady because revising the plan was socially expensive, so the record diverged from reality until a deadline forced the correction. Recording revisions as dated events removes the incentive that produces the pattern.
How do you set stall thresholds sensibly?
Per work type, based on how long that type normally takes to move when healthy. Global thresholds produce noise on slow-moving work and miss stalls on fast-moving work, and a detection system that produces noise gets ignored within about two weeks.
Start with ARIA
Ask ARIA to act on Project Execution Benchmark.
Reading it is one thing; running it is another. Tell ARIA the outcome you want from this and it works out which capabilities, systems, and data the work needs — then executes inside the permissions you set.
- ARIA acts only through the systems and permissions you connect.
- Connections use scoped credentials you can change or revoke.
- Actions are recorded, and consequential ones can require approval.
Continue
Turn Project Execution Benchmark into a working result.
ARIA can take this from framework to running work — building the surface, connecting the systems that stay authoritative, and operating the loop afterwards.