I have never found workstream percentage complete especially useful on complex programmes. It is attractive because it appears precise: one team is 70% complete, another is 85%, another is 60%. Put the numbers on a dashboard and the programme seems measurable.
The problem is that percentages say very little about whether the programme can achieve its next meaningful outcome. A workstream can be 90% complete while the remaining 10% contains the dependency that everything else is waiting for. Another team can be only 50% through its total activity but have already delivered exactly what the next programme milestone needs.
Those two situations look very different operationally even if a percentage-based dashboard suggests the opposite.
Programmes fail at the interfaces
Most large programmes are divided into workstreams for good reasons. Legal, Finance, Product, Data, Infrastructure, Operations and other functions need clear ownership and enough autonomy to manage their own work. But the programme outcome rarely exists inside one workstream; it exists where those plans meet.
On acquisition and integration programmes I have led, a technology team could be locally green while still depending on access, a supplier decision, regulatory approval or operational readiness owned elsewhere. On infrastructure programmes, hardware or platform work could be technically complete while environments, monitoring, support or downstream services were still not ready.
That is why I tend to spend more time on the dependencies between workstreams than on the amount of activity completed inside each one. The interfaces tell you whether separate pieces of progress are actually converging into a usable outcome.
The next milestone is a better unit of control
A more useful programme conversation starts with the next meaningful milestone or decision point. What has to be true for that outcome to happen? Who owns each input? Which dependencies are already secured, which are still assumptions, and which decisions have to arrive before the remaining work can proceed?
Once those questions are visible, percentage complete becomes much less important. The programme can distinguish between activity that is progressing and conditions that are becoming ready. Those are not the same thing.
This is particularly useful when a milestone depends on several functions at once. A single workstream reporting good progress does not compensate for a critical input elsewhere remaining unresolved.
A dependency has more than a due date
Poor dependency tracking often reduces a dependency to two fields: owner and date. That is better than nothing, but it still misses the most useful information.
I want to know what is being provided, who needs it, what evidence will show that it is ready, and what happens if it arrives late. That makes the dependency actionable and gives the programme a much clearer basis for escalation.
The conversation stops being “Team A is late” and becomes “Milestone X cannot proceed until this specific input is available, and the current forecast moves by Y if it is not resolved.” That is a much better basis for leadership intervention because the consequence is visible, not just the delay.
Dependencies expose false green status
This links directly to the problem of programme status. A workstream can report green because its own activities remain within plan, while a dependency it relies on is deteriorating elsewhere. In that situation the workstream status may still be technically accurate, but programme-level confidence is already falling.
Looking across dependencies makes that deterioration visible earlier. The important question is not whether each team believes it is on track in isolation, but whether the network of commitments required for the next outcome still holds together.
That is a more demanding form of governance, but it is also more useful because it creates the possibility of intervention before a missed dependency becomes a missed milestone.
The programme layer should not duplicate team plans
This does not mean central programme management should absorb every detail from every team. That would create exactly the reporting overhead good governance is supposed to avoid.
Teams should retain ownership of their detailed plans. The programme layer should concentrate on what crosses boundaries: shared milestones, dependencies, decisions, risks, capacity constraints and readiness evidence. That is the level at which coordination adds value.
The objective is not to build one enormous central plan containing every task. It is to understand enough about the interfaces between plans to know whether the programme outcome remains credible.
Progress is only useful when it changes readiness
Activity matters. Teams need to execute a great deal of work to deliver complex change, but programme leadership needs to understand which activity is actually changing the probability of the next outcome being achieved.
That is why I would rather know that five critical dependencies are secured than be told that six workstreams are each 80% complete. The percentage describes activity; the dependency view tells me whether the programme is becoming ready.