Program & Project Management
Programs Rarely Slip on Schedule. They Slip at the Hand-Off Nobody Owns.
The program manager is told the problem is the schedule. It almost never is. The schedule is where a dependency failure becomes visible to leadership — long after it became visible to the people doing the work.
Written by Steve Kopecky · 8 minute read
Founder & Principal, Compass Performance, Inc.
01
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.
02
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.
03
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.
Use it this week
- Read the delivery architectureSchedule 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-offScore the hand-offs you already distrust on severity, occurrence and detection, and give the high ones a named control before the next gate.
04
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.
Exhibit
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.
| Hand-off | Artifact | Accepted by | Standard | Need-by | Decision owner |
|---|---|---|---|---|---|
| Design to build | Frozen configuration workbook | Build lead | All open decisions closed | Two weeks before build start | Program manager |
| Build to test | Migrated data set | Test lead | Reconciles to source | Test entry gate | Sponsor |
| Test to go-live | Trained role playbooks | Function leader | Signed-off competence check | Cutover minus one week | Steering forum |
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.
Interactive exercise
Owned, or assumed?
Click each hand-off, then place it.
The other side of the argument
Send a question or an insight
Nothing here is published. Your note goes directly to Steve Kopecky, who reads every one — reader questions decide what gets written next.
Aligned to FOUNDATION™
Who are we, and what business are we actually trying to build?
Present reality, leadership capability, purpose and organizational health.
Article
Choose the 80 Before You Design the Enterprise: Building a Front-to-Back Strategy on the Vital Few
80/20 is not a cost exercise. It is the first strategic design decision — naming the vital few markets, customers, products and channels the enterprise intends to win, and then connecting that choice front to back.
11 minute read
Article
Clean Sheet Organization Design: Building the Structure the Strategy Requires
A clean sheet design starts from the strategy and the vital few opportunities, not from the current org chart. This is the process, the ownership and the SIPOC that governs it.
9 minute read
Assessment
FOUNDATION™ Diagnostic
A structured read on leadership capability, clarity of purpose, trust and organizational health.
Maturity read on screen, a print sheet, and an emailed copy.
Assessment
Lifecycle Stage Diagnostic
Fifteen statements that locate the business on the curve — Honeymoon through Reinvention — and name the binding constraint.
Stage placement, constraint, and the first move for that stage.
Instrument
30 / 60 / 90 Day Action Plan
Turns the lifecycle result into sequenced work: the stage supplies the architectural move, the lowest-scoring domain supplies what removes the constraint. Owners, dates and check-off included.
A checkable plan on screen and a board-quality PDF of the three horizons.
Instrument
Lifecycle Before & After Sheet
Holds the diagnostic result as the before, the stage and domain targets being architected as the after, the operating measures the change is judged against, and the reinvention actions carried from the ninety-day plan.
A one-page board-quality before-and-after PDF, plus an emailed copy.
Podcast
Kristina George — How an office manager became an owner leading a team of eighteen.
Kristina George describes the move from operator to owner and the decisions that made it hold. The conversation examines anchoring the agency on explicit values, investing in employee engagement, and simplifying the operating model so growth did not dilute the culture.
Podcast
Mike Domitrz — How a mission born from tragedy became a leadership standard.
Mike Domitrz shares the origin of The Center for Respect after his sister's assault in college, and how the work grew into a program trained across universities, high schools, the military, and businesses. The conversation examines how respect becomes an observable leadership behavior rather than a value on a wall.
Guide
Read the Curve Before You Build the Next One
The second curve is a timing decision before it is a strategy decision. Most companies read the curve years late, at the point where the options are cheapest to see and most expensive to take.
7 minute read
Engagement
Compass Executive Forums
A confidential peer table of owners and executives working the same architecture, month after month.
Monthly, by invitation
Engagement
The Compass Enterprise Architecture™
The core architecture Compass designs and installs with a leadership team.
The authoritative source
Related insights
Where this reading continues
- Program & Project Management
The Next Phase Is Delivered Across Boundaries — Which Is Why Program Management Becomes a Capability, Not a Role
The longer read: why program management is a capability the enterprise installs, not a coordinator it appoints.
13 minute read → - Organizational Architecture
Effort Cannot Solve a Design Problem
Why a tighter tracker and a firmer tone produce a short improvement and then revert.
6 minute read → - The Strategic Program Lens
Becoming Efficient at Work You Never Chose
The same problem read from the sponsor's chair, where the chosen work is decided.
6 minute read →