A project can be busy, disciplined, well staffed and almost entirely on schedule while still failing to produce convincing evidence that it is creating the outcome it exists to create.
That sounds obvious until you look at how most projects are managed.
We count completed tasks. We report milestones. We measure burn rates. We discuss defects, dependencies, sprint velocity, open risks, decisions and percent complete. None of those measures is useless. The mistake is treating them as if they answer the larger question.
What changed in the world because this work happened — and what evidence would convince a skeptical observer that the change is real?
That is a different question from whether the team did the work.
Projects produce activity by default
Activity is easy to see because projects are built to produce it. Plans generate tasks. Tasks generate meetings. Meetings generate actions. Actions generate status. Status generates decks. By the time an executive review arrives, the organization can be surrounded by evidence that people have been working very hard.
But work performed is not the same thing as a condition changed.
A new system can be deployed without reducing cycle time. A process can be redesigned without changing behavior. An AI assistant can be launched without improving the quality or speed of a decision. A transformation can complete every workstream and leave the underlying operating constraint intact.
This is one reason apparently healthy projects can disappoint late. The management system has been measuring the machinery of delivery more precisely than the effect of delivery.
The architectural analogy: observability
The analogy matters because it changes what we ask a management system to do.
If a production service is failing, engineers do not want a weekly narrative saying that the team is working hard and most components are green. They want signals that reveal the state of the system: latency, error rates, throughput, traces, resource pressure and the path a transaction actually took.
Project leadership should aspire to the same quality of visibility.
Not more reporting. Better instrumentation.
For a customer-service transformation, the useful signals might be resolution time, repeat contact, escalation rate and customer abandonment. For a finance automation program, they might be exception frequency, manual touches, close-cycle duration and error correction. For an AI-enabled workflow, they might include acceptance rate, human override, failure mode, time saved and whether the resulting decision improved.
The specific measures vary. The principle does not: the project should emit evidence about the state of the outcome, not merely the state of the work.
Evidence needs a comparison
One common failure is to define an outcome in language that cannot actually be tested.
“Improve collaboration.” “Enable the business.” “Modernize the platform.” “Enhance customer experience.” These may describe desirable directions, but they do not yet define observable change.
A useful evidence statement usually needs at least four things:
A condition. What is supposed to be different?
A baseline. What was true before the intervention?
A threshold. What level of change would be meaningful enough to matter?
A source. Where will the evidence come from?
Without those, a project can drift into a dangerous state: everyone agrees that progress is being made, but nobody has specified what would count as proof.
A milestone is evidence of completion, not necessarily of value
This distinction sounds semantic. It is operational.
Suppose a program has a milestone called “global rollout complete.” Hitting it proves something important: the rollout happened. It does not, by itself, prove adoption, behavior change, reduced cost, improved reliability or any other business outcome that justified the rollout.
Milestones are often evidence of production. Leaders also need evidence of effect.
The two should not be collapsed.
There is nothing wrong with celebrating implementation. The problem begins when implementation evidence is allowed to stand in for outcome evidence.
AI will make this distinction more important
AI is dramatically increasing the amount of work a team can produce: analysis, code, documentation, test cases, plans, summaries and recommendations can all be generated faster than before.
That means activity will become even cheaper.
When the cost of producing artifacts falls, artifact volume becomes a weaker signal of progress. A team may soon be able to generate in a day what once took several people a week. The leadership question therefore moves upward: did the additional production reduce uncertainty, improve a decision, remove a constraint or change an outcome?
This is a recurring pattern in technology. When a capability becomes abundant, the scarce resource moves elsewhere.
In AI-enabled work, the scarce resource may increasingly be credible evidence that the work mattered.
Evidence changes meetings
A project review built around evidence sounds different from a conventional status review.
Instead of asking, “Are we on track?” leaders can ask:
What did we expect to change by now?
What evidence has appeared?
What evidence has not appeared?
Which assumption is now weaker than it was two weeks ago?
What would cause us to change the plan?
What would cause us to stop?
These questions are harder because they expose uncertainty. That is precisely why they are more useful.
A status system often rewards coherence. An evidence system rewards contact with reality.
Management needs its own telemetry
The future of project leadership is not better status writing.
It is designing work so that important changes become observable as they happen.
That means connecting the outcome to evidence before execution accelerates. It means deciding which signals matter, where they originate, who owns their quality and what decisions they should trigger.
Once that is in place, status becomes a by-product rather than a ritual of reconstruction.
This distinction will matter even more as teams become mixtures of people, software agents and automated systems. Machines will be able to produce plans, tasks and reports at extraordinary speed. Leaders will still need to know whether the system is moving toward the condition they intended to create.
Progress is not the amount of work the system can describe. Progress is a meaningful change that the system can prove.
That is a higher bar. It is also a far more useful one.