Programs Slip at the Hand-Off, Not the Schedule

What the status meeting is actually telling you

Every function reports honestly. Engineering is green on its own scope. The vendor workstream is green. Finance is close to plan. Operations is watching one integration issue. The roll-up is amber because somebody felt amber was fair, and the meeting moves on.

A month later the integrated date moves. Nothing in any single report was false. The program still slipped, because the thing that broke was not inside any of those reports — it was between them. One team finished its part on the date it promised, in a form the receiving team could not use, on a day the receiving team had no capacity to receive it.

That is a hand-off failure, and it does not appear on a functional status line. It appears three weeks later as a date.

A dependency is the only part of a program that belongs to two functions and is owned by neither.

Why the dependency is invisible until it is expensive

Each function plans as though it were the only claim on its own people. That is not arrogance; it is the only plan a function can build with the information it holds. The result is a set of internally coherent plans that are collectively impossible, and the impossibility is only discoverable where they touch.

Then there is the definition problem. Two teams agree on a date and never agree on the deliverable: what form it arrives in, whose standard it must meet, who confirms it is fit to use, and what happens on the day it is late. A date without those four things is a hope with a calendar entry attached.

And there is the authority problem. When the hand-off does fail, the two functions cannot resolve it, because resolving it means one of them re-planning for the benefit of the other. So it escalates — which takes two weeks, because the forum that could decide it meets monthly and its agenda is full of reporting.

Diagnostic

Five questions per hand-off

For each dependency between functions: What exactly is being handed over, described as an artifact rather than an activity? Who accepts it, by name? What standard makes it acceptable? What date does the receiving team need it, as distinct from the date the sending team plans to finish? And who decides, within a week, when it is late? A dependency that cannot answer all five is not scheduled. It is assumed.

This is not a discipline problem in your team

Program managers carrying this pattern usually reach for more control: a tighter tracker, an extra stand-up, a firmer tone in the weekly. It produces a short improvement and then the system pulls the result back, because none of it changed the two conditions creating the failure — that dependencies have no owner, and that the forum able to resolve them meets too rarely to matter.

Read as a condition rather than a character flaw, the pattern is almost boring: the work crosses boundaries that the operating design never gave anybody authority over. The people are behaving rationally inside that design. So the fix is structural and small.

Name every cross-boundary dependency as its own line of work, with one accountable name, an artifact, an acceptance standard, a need-by date and a decision owner. Put a short weekly forum in place whose only agenda is dependencies at risk and the decisions they need. Then let the functional plans stay functional — they no longer have to carry what they were never able to see.

Herding cats is what it feels like to be accountable for a boundary you were never given authority over.

• Read the delivery architecture Schedule with logic and float, activity-level RACI with one accountable name, stage gates that pass on evidence, and an FMEA on the way of working — one record rather than five functional views.
• Run an FMEA on the hand-off Score the hand-offs you already distrust on severity, occurrence and detection, and give the high ones a named control before the next gate.

What good looks like at the next gate

A sponsor should be able to ask two questions and get answers in a day: is the promised date still achievable, and what would it cost to hold it. Both answers depend on the same thing — a record that holds the dependencies, not a set of reports that each stop at a boundary.

When that record exists, the weekly conversation changes character. It stops being a recital of activity and becomes a small number of decisions with owners and dates. That is the whole difference between a program that is being reported and a program that is being run.

The dependency line

One row per cross-boundary hand-off. If a row cannot be completed, the dependency is assumed rather than scheduled — which is the finding.

Three rows is usually enough to expose the pattern. Most programs have between eight and twenty of these, and can name three.

Is your slippage a schedule problem or a hand-off problem?

• The same decision has come back to the steering forum more than twice.
• Every workstream is green and the integrated date has moved.
• Two teams disagree about whether something was delivered.
• A dependency date is written down, but the acceptance standard is not.
• Escalation takes longer than the slippage it was meant to prevent.
• You are spending more of your week assembling status than resolving decisions.

If you want a straight read on one program you are carrying, take the five questions above to your next weekly and use them on three hand-offs. Most program managers find at least one dependency that nobody owns — and that finding, written down, is more useful to a sponsor than any status deck. If it would help to have somebody outside the reporting line look at the pattern with you, that conversation is available and costs nothing.

An unowned hand-off is a design condition, not a scheduling accident — read through LEAD™ accountability and governed delivery.