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.
Steve Kopecky · 8 minute read
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.
Use it this week
- Open the delivery deskSchedule 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.
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.
Download this article
The French and Spanish sheets are translated at board register on request; the structure, exhibit and checklist are identical in all three.
Kept on this device — no address collected, nothing emailed.
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
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
Article
The Eight Culture Types Are Not Types. They Are Eight Reinforcement Patterns Your Design Is Already Running
The eight culture descriptors in circulation describe what an organization rewards, tolerates and discourages. Read that way they stop being labels to pick and become findings to trace back to the mechanism producing them.
11 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 →
Continue reading
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.
Organizational ArchitectureThe Eight Culture Types Are Not Types. They Are Eight Reinforcement Patterns Your Design Is Already Running
The eight culture descriptors in circulation describe what an organization rewards, tolerates and discourages. Read that way they stop being labels to pick and become findings to trace back to the mechanism producing them.
Program & Project Management“Herding Cats” Is Not a People Problem. It Is Undeclared Authority.
You are accountable for an outcome and you manage nobody who produces it. The advice is to influence without authority. The honest read is that authority was never declared.
Personal EffectivenessA Message on Personal Habits: The Private Architecture Behind Every Executive Result
Architecture determines performance — and that is as true of a person as it is of an enterprise. A long-form message on habit design, 80/20 daily management, and the self-talk that governs behavior.
Organizational ArchitectureThe Architecture That Created Today's Success Rarely Produces Tomorrow's Results
The structure that carried a business to its current size is usually the constraint on its next stage. That is a design problem, not a people problem.
Organizational ArchitectureThe Engagement Layer: Why Slack Sits at the Center of Every Compass Partnership
Most advisory relationships depend on quarterly meetings and email chains. Compass designs the engagement as an operating layer — and Slack is where it lives.
Growth & Value CreationThe Second Curve Begins Before the First One Ends
The right moment to build what comes next is while the current business is still strong — which is precisely when no one feels the need to.
SimplificationComplexity Quietly Consumes Margin, Capacity and Leadership Attention
No one approves complexity. It accumulates one reasonable decision at a time, and it is paid for in margin, speed, and executive attention.
SimplificationFOCUS: The Vital Few Constraints That Create Economic Value
FOCUS is not doing less. It is concentrating effort on the customers, products, and markets that produce disproportionate value — and removing the complexity mirror they cast inside the organization.
Organizational ArchitectureWhat Is Enterprise Business Architecture — and Why Does It Determine Performance?
Enterprise business architecture is the deliberate design of how an organization decides, aligns, and executes. It sets the ceiling on performance long before effort does.
Organizational ArchitectureThe Ten Elements of an Enterprise Architecture — and Why They Only Hold Together
Strategic intent, simplification, leadership, governance, planning, cadence, decision rights, performance, enabling systems, and renewal. Designed together, or not designed at all.
Strategy & ExecutionArchitecture vs. Improvement: Why Better Execution Cannot Fix a Flawed Design
Improvement makes the current system perform closer to its limit. Architecture changes the limit. Confusing the two is the most expensive mistake in the mid-market.
Organizational ArchitectureEvery Organization Is Producing Exactly What Its Design Allows
Decision rights, cadence, reporting lines, incentives and leadership habits are not background. Together they are the machine producing the number on the books.
Organizational ArchitectureArchitecture Is Designed, Not Discovered
The work is concrete: name the few outcomes that matter, place each decision where it is properly made, remove the complexity consuming margin, and rebuild the cadence so commitments close.
The CEO / Owner LensThe Chief Executive Is Not Supposed to Be the Integration Mechanism
When strategy only reaches the work through the chief executive, growth adds volume to an unresolved design. The fix is structural, not personal.
The CHRO / People LensTurnover Is Usually a Structural Reading, Not a Hiring Result
When roles, capability, managers and recognition point in different directions, capable people leave — and the organization reads it as a recruiting problem.
The Operations LensPerformance That Depends on Who Is on Shift Is Not Performance
Where the process is undefined, capable people carry it. The result looks like variable performance and is read as a discipline problem.
The ERP / Systems LensAn ERP Program Is a Process Decision Wearing a Technology Budget
Systems enable the management system; they never replace it. Configuring before the process is designed automates the current mess at scale.
The Exit / Succession LensA Buyer Discounts Precisely What the Owner Cannot Hand Over
Transferable value is documented processes, governed data, named successors and results that hold when the founder is not in the room.
The Leadership Team LensA Team That Meets Often and Decides Rarely Is Compensating for a System
When reviews end in discussion rather than dated commitments, the same root cause is rediscovered every quarter.
The AI & Data LensPilots Demonstrate Capability. Designed Processes Produce Results.
AI moves a measure inside a process. Where the process is undesigned and the data ungoverned, there is nothing for it to move.
The Transformation LensExhaustion Is Routinely Misread as Resistance
Change fails at the point of absorption far more often than at the point of design. Capacity, honesty about recent change, and reinforcement decide the outcome.
The Next-Curve LensThe Next Curve Is Absorbed by the People Already at Capacity
A next curve is designed on paper and delivered by an organization that must also run the current one. Readiness is whether the system can carry both.