How Complex Teams Manage Dependencies Before They Cause Delays: What the Last Planner System and Peak OS Reveal About Reliable Execution

A leadership team can create a clear strategy, establish priorities, assign owners, and still repeatedly miss important commitments.

The problem often appears during execution.

Engineering cannot start because Product has not completed a decision.

Manufacturing is waiting on an engineering release.

Marketing is preparing for a launch based on a date another team no longer believes.

A critical hire assumed in the plan has not been filled.

A supplier dependency appears later than expected.

Finance built its forecast around milestones that have quietly shifted.

Every team may be working hard.

Everyone may understand the company strategy.

Nobody may be obviously underperforming.

Yet the plan continues slipping.

That leads to an important buyer question:

How do we manage dependencies between teams before they cause delays?

The construction industry has spent decades working on a particularly tangible version of this problem.

Complex construction projects involve architects, engineers, general contractors, subcontractors, specialty trades, suppliers, owners, and other participants whose work has to occur in the right sequence. One team's inability to complete work can prevent several other teams from beginning theirs.

The Last Planner System, or LPS, was developed within the Lean Construction movement to improve the reliability of that workflow.

The Lean Construction Institute describes LPS as a collaborative, commitment-based system for project production planning and control designed to create more reliable execution. It was developed by Glenn Ballard and Greg Howell and evolved from work beginning in the 1990s. The "Last Planner" is the person or group closest to the work with enough authority to make commitments about when that work can actually be completed.

The system is organized around five connected conversations:

Should.

Can.

Will.

Did.

Learn.

Pull planning establishes what should happen. Make-ready planning determines whether the work can happen by identifying and removing constraints. Weekly Work Planning creates explicit commitments about what will happen. Teams then evaluate what did happen and learn from the difference.

Peak OS was not developed from the Last Planner System.

Peak emerged through more than two decades of working with hundreds of founders, CEOs, investors, and leadership teams and observing the recurring habits that enabled companies to execute as complexity increased.

But there is a compelling convergence:

A plan becomes more reliable when the people responsible for execution can see dependencies, expose constraints, make clear commitments, measure whether those commitments were kept, and learn from the variance.

That is an important principle for any complex team-of-teams organization—and particularly for aerospace, defense, robotics, advanced manufacturing, autonomy, physical AI, and other frontier-tech companies where execution increasingly depends on handoffs among specialized teams.

Last Planner Came From the Problem of Unreliable Workflow

Understanding where the Last Planner System came from helps explain why it is relevant beyond construction.

The Lean Construction Institute was formed in 1997 by Glenn Ballard and Greg Howell to advance a different approach to managing project work. Early research had revealed an important problem: traditional project schedules and controls could describe what was supposed to happen without reliably producing the workflow necessary to make it happen. LCI describes the development of Last Planner as foundational to creating more predictable workflow and faster learning in projects.

That distinction is powerful.

A master schedule can say:

Complete this milestone by June 30.

But the schedule itself does not ensure the milestone can actually be accomplished.

The work may depend on:

information,

materials,

equipment,

approvals,

prior work,

people,

decisions,

or other commitments.

If those conditions are not ready when they are needed, the schedule remains correct on paper while execution becomes impossible in reality.

Companies experience the same thing.

A One-Year Plan says:

Launch the new platform by Q3.

That may be strategically correct.

But can the organization actually do it?

Does Engineering have the technical capacity?

Is Product clear on requirements?

Can Manufacturing support the design?

Are critical suppliers ready?

Is Quality prepared?

Have the necessary people been hired?

Does Finance support the investment?

Are customer commitments aligned with the execution plan?

The strategic objective is not the same thing as execution readiness.

That distinction sits at the center of the Last Planner System.

It is also fundamental to organizational execution.

“Should” Is Necessary, but It Is Only the Beginning

The first LPS conversation is essentially:

What should happen?

LCI's model begins with milestone planning and pull planning. The project establishes the outcomes and milestones that need to be achieved, then teams collaboratively work through the sequence and handoffs necessary to get there.

Peak begins at a different organizational level, but direction matters just as much.

The Mission establishes why the organization exists.

The Three-Year Vision establishes where the organization intends to go.

The One-Year Plan defines what success should look like at the nearer horizon.

OKRs then translate portions of that plan into current organizational outcomes and capabilities.

Those answers establish what should become true.

But a company can have an excellent One-Year Plan and still struggle.

The question eventually has to move from:

What should we accomplish?

to:

What has to be true for us to accomplish it?

That is where dependencies and constraints enter the picture.

The Plan Usually Breaks at the Handoffs

LCI places significant emphasis on handoffs.

Its guidance on pull planning says teams should identify the flow of work and information required to reach milestones, including the handoffs that trigger subsequent activities. LCI specifically calls handoffs a common source of pain and waste in project processes.

The same is true in organizations.

A product does not move from idea to customer inside one function.

There are handoffs.

Customer information reaches Product.

Product defines requirements.

Engineering develops.

Engineering releases something to Manufacturing.

Manufacturing produces.

Quality validates.

Marketing prepares the market.

Sales creates commitments.

Customer Success prepares implementation.

Finance models the impact.

Each handoff carries information, assumptions, timing, quality requirements, or decisions.

And every handoff creates an opportunity for friction.

The problem may not be that Engineering is slow.

Engineering may have been waiting for requirements.

The problem may not be that Manufacturing missed its schedule.

Manufacturing may have received the release later than expected.

The problem may not be that Sales overpromised.

Sales may never have received updated information from Product.

Looking only inside functions can therefore hide the real execution problem.

The delay lives between them.

This is one reason Peak treats the organization as a team of teams.

Symbiosis is not simply about people getting along. In Peak Teams, it describes different teams understanding their contribution, trusting one another to fulfill commitments, and working collectively toward shared company outcomes.

Reliable execution depends heavily on the reliability of the interfaces.

The People Closest to the Work Need a Voice in the Plan

The term Last Planner itself contains an important idea.

LCI defines the Last Planner as the person closest to the work who has the authority to make decisions about the schedule and make reliable commitments for their discipline. In construction, that may be a superintendent or foreman; in design, it may be a project architect or discipline lead.

Why does that matter?

Because a plan becomes much less reliable when commitments are made primarily by people far from the actual conditions of execution.

Senior leadership may say:

"We can deliver this in Q3."

The team closest to the work may already know that one dependency makes that impossible.

A VP may believe hiring will take 60 days.

The recruiter may know that this specialty routinely takes five months.

Product leadership may assume Engineering can absorb another requirement.

The technical team may know that doing so changes the architecture.

A company can therefore create false certainty when planning is only top-down.

Peak's planning process deliberately includes input from the people closer to execution.

Before leadership planning, functional leaders gather thinking from their teams. After leadership develops organizational direction, teams take that plan back down, evaluate what it means operationally, identify dependencies and constraints, refine their own objectives, and feed material information back upward.

This is not decision-by-committee.

Leadership still has to make choices.

But reliable planning benefits from information held by the people who will actually make the plan happen.

“Can” May Be the Most Important Question in Complex Execution

The second major LPS conversation is:

Can the work actually be done?

LCI calls this Make-Ready Planning.

The objective is to identify constraints far enough in advance that they can be removed before they stop execution. Lookahead planning examines upcoming work and asks whether the necessary prerequisites are available. If not, the team works to make that work ready.

This concept is especially valuable for frontier-tech companies.

Imagine a major aerospace program objective:

Complete flight-test-ready prototype by September 30.

The objective should happen.

But can it?

Does the design have the required maturity?

Are long-lead components ordered?

Has the specialized test equipment been built?

Are the necessary engineers on staff?

Is the software integration environment ready?

Is manufacturing capacity available?

Are quality procedures established?

Has the regulatory or customer approval required for the test been secured?

Does Finance support the necessary expenditures?

Each answer represents a potential constraint.

If the team discovers the constraint six months ahead, it has choices.

If it discovers the constraint two weeks before the milestone, it has consequences.

That creates an important organizational principle:

The reliability of execution depends partly on how early the organization can see what must become true before the work can begin.

This is much more useful than asking only whether teams are "working hard enough."

Dependencies Should Be Exposed During Planning, Not Discovered During Failure

This connects directly with Peak's up-team, down-team, and across-team planning architecture.

Leadership develops the initial organizational plan.

Then the plan gets exposed to the people responsible for executing it.

Engineering looks at its implications.

Product looks at its implications.

Sales looks at its implications.

Finance looks at its implications.

Manufacturing, Quality, Operations, People, Program Management, and other teams do the same.

Then teams look across.

What do I need from you?

What do you need from me?

When?

What has to happen before I can begin?

What assumption are you making about my team?

What constraint do I see that you do not?

This is not very different conceptually from the function LCI describes in collaborative planning: the people responsible for execution jointly identify handoffs and constraints rather than relying on a schedule created by a small number of planners in isolation.

The Peak mechanism is different.

The principle is similar:

The organization should discover dependencies while it still has time to manage them.

A Cross-Functional Dependency Is a Commitment Between Teams

This is where the Last Planner concept of reliable promises becomes especially interesting.

LCI describes Last Planner as a commitment-based planning system. Team members make explicit promises about work they intend to complete, and those commitments matter because other participants are planning their work around them. A reliable promise requires the person making it to have genuine ownership rather than simply receiving an imposed assignment.

Think about what a cross-functional dependency really is.

Engineering tells Product:

We will have the integration complete by June 15.

Product is not simply receiving a date.

It is making subsequent plans based on that commitment.

Marketing may then plan around Product.

Sales may plan around Marketing.

Customer Success may plan around Sales.

Finance may plan around all of them.

The reliability of one commitment affects the reliability of the entire system.

This creates a different way to think about accountability.

Accountability is not only:

Did I complete my work?

It is also:

Could the people who depended on my commitment reliably plan their work around it?

That is team-of-teams accountability.

“Will” Converts Possibility Into Ownership

In the Last Planner System, Weekly Work Planning moves from what can happen to what people explicitly commit will happen.

LCI describes Weekly Work Planning as the point where Last Planners make specific promises about work they will complete.

Peak does not use Weekly Camp to build a construction-style Weekly Work Plan, so the systems should not be treated as direct equivalents.

But Peak shares an important belief about ownership.

An objective needs an owner.

A Key Result needs an owner.

A KPI needs an owner.

An action coming out of Triage needs an owner.

The Peak Teams framework repeatedly reinforces that work becomes more executable when everyone knows who owns what and when the expected result should occur.

There is a huge difference between:

We need to improve onboarding.

and:

This objective is owned by Alex, these Key Results are owned by Alex, Jordan, and Maya, and these are the dates we have committed to.

The second statement can create execution.

The first creates intention.

Reliable Execution Depends on Commitment Quality, Not Just Goal Quality

Companies spend enormous time improving goal quality.

Are the objectives clear?

Are the Key Results measurable?

Are the priorities strategic?

Those questions matter.

But execution also depends on commitment quality.

Did the person who owns the outcome believe it was achievable?

Did they understand the dependencies?

Did they have enough capacity?

Were the necessary inputs available?

Did another team promise something the owner needs?

Was the timing realistic?

Was the commitment negotiated with the people doing the work or assigned from above?

These questions determine whether the plan represents an actual commitment or simply an executive aspiration.

LCI's emphasis on reliable promises reflects exactly this concern. A promise becomes useful to the project because other people can confidently organize their own work around it.

That is a powerful business principle.

A commitment is valuable partly because other teams can trust it.

Why Does the Company Keep Missing Quarterly Commitments?

This is one of the natural buyer questions behind the Last Planner comparison.

A leadership team may conclude:

"Our people aren't accountable."

Sometimes that is true.

But repeated misses can come from several very different conditions.

The company committed work that was never actually ready.

Dependencies were invisible.

People accepted dates they did not believe.

Capacity was overestimated.

Different functional plans conflicted.

Constraints appeared too late.

Priorities changed after commitments were made.

Information did not move across functions.

One team's miss prevented several other teams from completing their work.

Calling all of these an "accountability problem" oversimplifies the diagnosis.

The Last Planner System offers a more interesting question:

How reliable is the planning system itself?

That question also matters in Peak.

If the same team repeatedly produces Off-Course OKRs, leadership should eventually ask more than:

Why didn't they execute?

It should ask:

What is our planning and execution system teaching us?

Perhaps the objective sizing is wrong.

Perhaps dependencies are not being identified.

Perhaps the One-Year Plan assumes more capacity than exists.

Perhaps ownership is unclear.

Perhaps one function is repeatedly blocking another.

Perhaps priorities are changing too often.

That is organizational learning.

“Did” Requires Comparing Commitment With Reality

LPS does not stop after people make promises.

The system measures what actually happened.

One of its best-known measures is Percent Plan Complete, or PPC, which evaluates the percentage of planned weekly commitments completed as promised. Teams can then examine why work was not completed.

The important idea is not the construction metric itself.

It is the comparison:

We said this would happen. Did it?

Peak creates similar transparency through its own mechanisms.

OKRs are visible.

Owners report On-Course, Off-Course, Done, or Pushed.

KPIs show current performance relative to expectations.

To-Dos are reviewed.

The One-Year Plan is revisited during periodic planning.

The organization therefore creates repeated opportunities to compare intention with reality.

Without that comparison, accountability becomes subjective.

"I think we made progress."

"We worked hard."

"A lot happened."

"We're almost there."

Those statements may all be true.

But they do not answer:

Did the commitment happen?

Off-Course Should Trigger Understanding, Not Blame

This is where the Last Planner System's Reasons for Variance become particularly relevant.

LCI includes reasons for variance as part of the learning process. When planned work is not completed, the team analyzes why in order to improve future planning and execution.

Peak follows a similar philosophy when an outcome becomes Off-Course.

The useful response is not:

Who screwed up?

It is:

What is happening?

Triage uses ACT:

Assess the situation.

Consider alternatives.

Take action.

The team seeks to understand the underlying condition before determining what should happen next.

That distinction matters because blaming individuals can hide systemic causes.

The owner may have missed because another commitment failed.

A resource may not have been available.

A decision may have arrived late.

A hidden dependency may have surfaced.

The plan may have been unrealistic.

The environment may have changed.

Accountability still matters.

But reliable execution improves when the organization becomes curious about why reliability failed.

“Learn” Is What Makes the Planning System Better Over Time

The final LPS conversation is:

What did we learn?

LCI describes learning from planning breakdowns as a core part of Last Planner. The system is intended not only to create more reliable workflow but also to improve future planning through repeated analysis of actual performance and variance.

This is another strong parallel with Peak.

Learning is one of the five SCALE behaviors.

Peak reinforces it at multiple horizons.

Weekly Camp reveals what changed during execution.

Triage creates immediate learning around significant variance.

The meeting itself is rated so the team can improve how it operates.

Quarterly or Semiannual Sessions allow the organization to look back at the previous execution period before creating the next one.

Team Surveys create another perspective on how the organization performed.

Annual Sessions bring a year's accumulated learning into the next Three-Year Vision, One-Year Plan, Roles and Responsibilities, and execution horizon.

The organization does not simply plan again.

It should plan better because it has executed before.

Should → Can → Will → Did → Learn Is a Powerful Execution Lens

The five Last Planner conversations offer a useful way to think about the organizational journey from strategy to reliable execution.

Should

What outcome matters?

Can

Are the conditions, resources, decisions, and dependencies in place?

Will

Who is actually committing to what?

Did

Did the commitments happen?

Learn

What should change because of what we discovered?

That is construction terminology and should remain credited to the Last Planner System.

Peak has its own architecture.

But an analogous organizational flow exists:

Mission / Vision / One-Year Plan

What should become true?

↓

Team-of-Teams Planning / Dependencies / Capacity

Can the organization execute it?

↓

OKRs / Ownership / Roles and Responsibilities

Who owns the outcome and what are we committing to?

↓

Weekly Camp / KPIs / OKR Review

Are we actually doing what we said?

↓

Triage / Team Surveys / Quarterly-Semiannual / Annual Review

What are we learning and how should that influence what happens next?

The systems are not interchangeable.

The execution logic is remarkably compatible.

Reliable Handoffs May Matter More Than Individual Productivity

This creates another useful insight for CEOs.

Companies often try to improve execution by increasing the productivity of each function.

Make Engineering faster.

Make Sales more productive.

Make Manufacturing more efficient.

Make meetings shorter.

Those efforts can help.

But in a highly interdependent organization, the largest execution losses may be occurring in the waiting time between teams.

Engineering finishes its part.

Manufacturing cannot start because another requirement is missing.

Product is ready.

Leadership has not made a decision.

Sales has a customer.

The required capability is still in development.

Finance has approved headcount.

The role profile has not been finalized.

The work itself may move quickly once it begins.

The organization loses time because one team is repeatedly waiting for another.

Lean Construction focuses heavily on flow for this reason. LCI describes Last Planner as improving process flow by collaboratively identifying and managing the conditions that allow work to move reliably from one participant to the next.

For a team-of-teams company, the same question is worth asking:

Where is work waiting between teams?

That may reveal more than another productivity initiative inside a function.

Constraint Removal Is an Organizational Capability

This becomes especially important as technical and organizational complexity rise.

Consider a robotics company preparing a new production release.

The Engineering team cannot finish without validation data.

The validation team cannot produce the data until hardware arrives.

Hardware cannot arrive until Procurement finalizes a supplier.

Procurement is waiting for Finance approval.

Finance is waiting for a final volume assumption from Sales.

The visible problem may be:

Engineering is behind.

The actual constraint may sit four teams away.

The Last Planner System intentionally looks ahead for this kind of condition so teams can remove constraints before they prevent work from becoming executable.

Peak's Team-of-Teams planning and operating rhythm create a business mechanism through which similar dependencies can become visible.

The specific constraint system is different.

But the organizational principle is extremely important:

Teams cannot reliably execute work that the organization has not made ready for execution.

This Is Why a Plan Should Move Down and Across After Leadership Planning

The Last Planner comparison strengthens another Peak principle.

Leadership planning is not complete simply because leadership has agreed.

Leadership sees the organizational picture.

The people closer to execution see constraints leadership may not see.

After planning, teams need to interpret the organizational direction.

What does this require from us?

What do we need from others?

What do others need from us?

What does the sequence look like?

Where are the constraints?

What capacity assumption does the plan contain?

What seems unrealistic?

That information moves down and across.

Material learning then moves back up.

This is what makes the plan stronger.

In that sense, the people closest to execution are not merely recipients of the strategy.

They are part of the process that determines whether the strategy can become reliable execution.

What Should Happen When a Commitment Goes Off-Course?

Another buyer question is:

What should happen when an OKR or commitment goes Off-Course mid-quarter?

The weak response is to simply record the miss.

The opposite weak response is to change the plan immediately every time something becomes difficult.

The stronger response is diagnosis.

What changed?

Why?

Does another team depend on this?

Is the commitment still achievable?

What constraint needs to be removed?

Does scope need to change?

Does ownership need to change?

Does another resource need to be added?

Is this a local execution issue or evidence that the larger plan is wrong?

Peak uses Triage to create a structured forum for that question.

The team assesses the situation, considers alternatives, and takes action.

Then the operating system continues monitoring reality.

Some issues are solved locally.

Some require cross-functional support.

Some rise to leadership.

Some eventually become evidence that the One-Year Plan needs adjustment during Quarterly or Semiannual planning.

The important thing is that the organization has a known response path.

Reliable Promises Build Trust Between Teams

LCI connects reliable promises with more than schedule performance.

When team members repeatedly make and keep commitments, other participants can plan their own work with greater confidence. LCI describes this as improving communication and making everyone's work easier because people understand what to expect from one another.

That is a form of operational trust.

Peak calls the broader behavior Symbiosis.

Trust is not only:

I like working with you.

It is:

When your team says this will happen, I can confidently make my own commitments based on it.

That is enormously valuable in a team-of-teams organization.

Engineering trusts Product's requirements.

Manufacturing trusts Engineering's release.

Sales trusts the roadmap.

Finance trusts the hiring forecast.

Leadership trusts functional owners.

The organization gains speed because people spend less time protecting themselves against unreliable commitments.

Reliability therefore creates both accountability and coordination.

Frontier Tech Makes Reliable Dependencies Especially Valuable

The Last Planner System emerged from construction, where physical sequence matters.

You cannot install something that has not arrived.

One trade may literally be unable to begin until another has completed its work.

Frontier-tech organizations share more of this physical dependency than many traditional software businesses.

A spacecraft has sequence.

Manufacturing has sequence.

Hardware integration has sequence.

Testing has sequence.

Certification can have sequence.

Supplier lead times are real.

A decision delayed today may not simply delay tomorrow's task.

It can change a production slot months away.

That is why the concepts of handoffs, constraint removal, readiness, and reliable commitments are particularly relevant to aerospace, defense, robotics, advanced manufacturing, autonomy, and other physical frontier businesses.

The organization needs to know more than:

What is everyone working on?

It needs to understand:

What work is waiting on other work, and what can we do now so the next team is ready when the handoff arrives?

That is a much more sophisticated execution question.

Peak Is Not a Construction Production System

The boundary matters.

The Last Planner System is a Lean Construction system for project production planning and control. It has specific practices around pull planning, make-ready planning, Weekly Work Plans, reliable promises, daily commitment management, Percent Plan Complete, and Reasons for Variance.

Peak OS is not LPS adapted for companies.

It does not replace construction project controls.

It does not use PPC as its core measure.

Weekly Camp is not a Weekly Work Plan.

And Peak's OKRs are not Last Planner commitments.

Peak is a broader organizational operating system designed around the needs of growth-company teams.

The meaningful comparison is at the level of execution architecture.

Both systems recognize that:

direction is not enough,

the people closest to work hold critical execution knowledge,

dependencies need to become visible,

constraints should be addressed before they stop execution,

ownership and commitments need to be explicit,

reality needs to be compared with the plan,

variance should create learning,

and planning quality should improve through repeated execution.

Those principles travel well beyond construction.

A Better Question Than “Why Did We Miss?”

When an organization repeatedly misses commitments, leadership often asks:

Why aren't people more accountable?

Sometimes that is the right question.

But the Last Planner System offers a more revealing sequence.

What should have happened?

Could it actually happen?

What did people genuinely commit would happen?

What did happen?

What did we learn?

Those questions open a much richer diagnosis.

Maybe the problem was accountability.

Maybe it was planning.

Maybe readiness.

Maybe capacity.

Maybe a hidden dependency.

Maybe a poor handoff.

Maybe unclear ownership.

Maybe the original plan.

Peak's value is partly that it creates enough visibility and operating rhythm for those distinctions to become discussable.

The goal is not simply to hold people accountable for missing.

It is to build an organization that becomes increasingly reliable at making and keeping the commitments required to execute its Mission and plan.

Reliable Execution Happens Between the Plan and the Work

This may be the deeper lesson from the Last Planner System.

Many organizations have strategy at the top and activity at the bottom.

What is missing is the system connecting them.

The strategic plan says where the organization should go.

Teams are busy performing work.

But dependencies, constraints, ownership, handoffs, commitments, feedback, and learning remain mostly informal.

That gap is where execution becomes unreliable.

The Last Planner System was built to improve reliability in that gap for design and construction projects.

Peak OS addresses a different but related gap inside growth companies.

Mission and Vision create direction.

The One-Year Plan establishes success.

Up-team, down-team, and across-team planning expose realities and dependencies.

OKRs establish current organizational outcomes.

Roles and Responsibilities create ownership.

KPIs provide operating signals.

Weekly Camp creates recurring visibility.

Triage creates decisions and response.

Team Surveys and periodic planning create learning.

The result is an operating system between strategy and work.

For complex frontier-tech organizations, that layer becomes increasingly important.

Because the company rarely fails because no one was working.

It fails when highly capable teams cannot reliably connect their work to one another.

And that is why one of the most useful questions a leadership team can ask is not simply:

What are our priorities?

It is:

What has to become true across this team of teams for those priorities to actually be executable—and how will we know early when one of those conditions is no longer true?

That is where planning begins turning into reliable organizational execution.

Related Insights

What Is Peak OS?

What Is Organizational Execution?

What Is Organizational Intelligence?

What Is a Business Operating System?

What Is Operating Rhythm?