Mobilisation usually feels productive.
People are appointed, plans take shape and governance starts. Meetings fill the diary, reporting begins and the programme starts to look like something that can be managed.
That visible activity is reassuring. It is also one reason some of the conditions that cause problems later can be missed.
Because mobilisation does not only establish how work will start. It establishes many of the assumptions on which the work will subsequently depend.
That includes who owns what, which decisions need to be made and when, what one team expects from another, and which dependencies are genuinely understood. It also includes something more basic: what success means in practice rather than in the business case or programme plan.
When those things are clear enough, mobilisation creates a useful foundation.
When they are not, delivery can still move.
It just starts carrying the uncertainty with it.
What this usually looks like in practice
Mobilisation problems created by unresolved assumptions or dependencies rarely look like failure at the point they form.
A dependency is understood slightly differently by two teams. An assumption remains open because there is no immediate need to resolve it. A decision can wait until more information is available. A responsibility sits between functions, but everybody broadly knows what needs to happen.
Individually, none of these necessarily looks serious.
People compensate. Someone follows up more often, a delivery lead joins another meeting, or a team keeps a separate tracker because the main one does not quite give them what they need. A decision is provisionally assumed so work can continue.
Progress remains visible, but the programme has started to depend on additional effort to preserve it. That distinction matters.
An unresolved assumption that genuinely does not affect anything can wait. One that is being quietly compensated for has already started to consume capacity.
Mobilisation can create certainty that the programme does not yet have
Early reporting tends to describe what can be seen: milestones, actions, risks, decisions and delivery activity.
That is useful, but it can create an odd effect.
The programme becomes more visible without necessarily becoming more controlled.
More information appears, more people become involved and oversight increases, yet some of the conditions underneath delivery remain uncertain.
This is the point where visibility increases but control does not and the underlying delivery condition starts to become commercially visible.
It is also where governance pressure starts to build.
The response is often to increase reporting further because reporting is the visible mechanism available to improve confidence. Additional forums, checkpoints and status information can certainly help where the problem is insufficient visibility.
They help much less where the real problem is that an assumption has not been tested, a dependency has not been agreed or ownership is still ambiguous.
The programme can then become very good at describing a condition it has not actually resolved.
The hidden cost is the effort required to keep delivery looking stable
When unresolved mobilisation conditions are compensated for rather than resolved, the first cost is rarely a dramatic delay or budget overrun.
It is the extra work required to prevent one.
People chase information that should already flow, meetings compensate for unclear handoffs, and decisions are revisited because their original basis has changed. Teams start working around dependencies rather than resolving them.
For a while, capable people make this look surprisingly normal.
That is why reporting increases but outcomes do not is often noticed later than it should be. The reporting itself is not necessarily the problem. The issue is what has become necessary to keep the reported position intact.
Confidence is being carried by effort.
Across a large programme, that effect can multiply quickly. One small ambiguity crossing several teams becomes repeated coordination. One unresolved dependency becomes several local workarounds. One provisional decision becomes a constraint that later decisions have unknowingly inherited.
The programme is still moving, but more of its capacity is being used to maintain movement rather than create progress.
Workarounds established early have a habit of becoming normal
Workarounds introduced during mobilisation can be entirely sensible when assumptions, dependencies or ownership cannot yet be fully resolved.
The risk appears when temporary arrangements stop being recognised as temporary.
A manual handoff remains because it works. An additional meeting continues because removing it feels risky, while one person becomes the informal connection between two teams because that is quicker than resolving the underlying ownership.
Nothing has formally changed, but the way delivery actually works has.
That matters because the longer it continues, the more the workaround, cost or assumption becomes embedded.
Later, when pressure increases, the programme may diagnose the resulting symptom rather than the condition that created it. Capacity appears insufficient. Governance appears cumbersome. Decisions appear slow. Delivery appears harder to coordinate.
Adding resource or reporting may relieve some of that pressure.
It does not necessarily remove its source.
The useful mobilisation question is not simply whether work has started
A stronger question is:
Where is effort being absorbed without producing equivalent progress?
That changes what the programme looks for.
Repeated clarification matters, as does the same dependency appearing in different conversations. So do decisions that technically exist but keep being reopened, or additional coordination that has quietly become essential.
None proves that a programme is failing. Nor does every workaround need to be eliminated.
They are useful because they show where the delivery model may already be consuming more effort than its visible progress suggests.
That is an earlier and more actionable signal than waiting for a milestone to slip.
The expensive problem may still look quite small
An unresolved mobilisation assumption or dependency can remain relatively small while delivery is still being built around it.
By the time it becomes a recognised delivery problem, much more may depend on it.
Plans have been built. Commitments have been made. Teams have adapted. Costs have been incurred. Other decisions have used the original assumption as their starting point.
Changing it is now more disruptive precisely because delivery has progressed.
That is why some of the most expensive problems are created during mobilisation rather than during failure.
The cost does not necessarily arise because the original issue was large.
It arises because a small unresolved condition was allowed to become structural.
The useful intervention is therefore not more control for its own sake. It is identifying where visibility, activity and confidence are being maintained through disproportionate effort — and testing what sits underneath.
For organisations seeing that pattern, the Full Delivery Scorecard provides a broader diagnostic view of where delivery confidence may already be weakening.
Related Observations
When programme scale starts to expose instability
Where coordination and interdependence increase, apparently small delivery conditions can become much harder to contain.
When delivery confidence starts weakening before failure is visible
A useful next observation where reporting remains positive but maintaining that position is requiring increasing effort.
When effort stops converting cleanly into progress
The next question is whether additional activity is genuinely moving delivery forward or simply compensating for friction already embedded in the system.