Every large general contractor eventually arrives at the same uncomfortable realisation: the CPM schedule on the conference room wall and the pull plan on the superintendent's whiteboard tell two completely different stories about the same project. One is updated monthly. The other is redrawn every week. One belongs to the owner. The other belongs to the trades. And for most GCs, the two have never been connected.
This disconnect isn't an accident. It's the predictable result of using two methods that were designed independently, implemented in separate tools, and never given a shared data model. CPM grew out of 1950s aerospace project management. Lean pull planning emerged from Toyota's production system and was formalised for construction by Glenn Ballard and Greg Howell in the 1990s. They've been running in parallel on construction sites ever since — tolerated as separate disciplines rather than integrated as a unified scheduling approach.
For small contractors running a handful of projects, this separation is inconvenient. For large general contractors managing 50, 100, or 200 simultaneous projects — each with their own CPM baseline and their own lean board — it becomes a systemic risk. The schedule that diverges goes unnoticed. The critical path that shifts doesn't update the pull plan. The pull plan that finds a better sequence doesn't update the CPM. And by the time someone reconciles the two, you're already behind.
CPM and lean pull planning are not competing methods — they answer fundamentally different questions at different horizons. The problem isn't choosing between them. The problem is running them in separate tools with no shared data model.
What each method actually does — and who it serves
Before arguing for integration, it's worth being precise about what each method is actually for. They're often described as competing approaches, but that framing misses the point. They operate at different time horizons and serve different audiences.
A top-down, logic-driven scheduling technique that models the full project timeline from mobilisation to closeout. CPM identifies the critical path — the sequence of activities that determines the earliest possible completion date. Changes to critical path activities directly affect the project end date; changes to non-critical activities have float.
A bottom-up, collaborative planning technique where the people doing the work plan backwards from upcoming milestones — identifying what needs to happen in the next three to six weeks, in what sequence, and what conditions must be met for each task to proceed. Reliability of commitments (Percent Plan Complete) is tracked weekly.
The key insight is in that last word: serves. CPM serves the owner, the contract, and the executive team. Lean pull planning serves the field team — the superintendent, the foreman, and the trades who need to know exactly what they're doing on Tuesday morning and what they need from the crew before them to do it.
A large GC can't abandon either audience. The owner requires CPM schedule updates as a contractual deliverable. The trades require pull planning to coordinate daily workflow. The executive team needs CPM to understand portfolio risk. The field team needs pull planning to achieve reliable workflow. These aren't competing needs — they're complementary needs that require both methods running simultaneously.
The divergence problem — when two schedules tell different stories
Here is what happens in practice when CPM and lean planning run in separate tools. It's a pattern so consistent that most experienced project managers will recognise it immediately.
In week one, the CPM schedule and the pull plan are reasonably aligned. The CPM baseline was the starting point; the pull plan was built from it. There's an optimistic sense that the two will stay in sync. By week four, the first cracks appear. The field has found a better sequence for the mechanical rough-in — they can start two weeks earlier than the CPM shows, which would save float on the critical path. But updating the CPM requires a schedule revision meeting. The pull plan moves forward; the CPM doesn't.
By week twelve, the CPM schedule has become a contractual artefact — it reflects the original logic, updated for owner reporting, but increasingly disconnected from what the field is actually doing. The pull plan is where real project management is happening, but it has no visibility into the critical path implications of field decisions. Is the mechanical rough-in sequence change actually helping, or is it eating into float on an activity that was more important than the field team realised? The pull plan can't answer that question. The CPM — maintained separately — doesn't know the sequence changed.
The result is a project team that has effectively lost its integrated schedule. Decisions that should be informed by both the long-range critical path and the short-range field reality are being made from one or the other — never both simultaneously.
Smartapp customers report that project managers running CPM and lean planning in separate tools spend an average of 4–6 hours per week per project reconciling data between the two. For a GC managing 50 projects, that's 200–300 person-hours per week spent on a problem that a unified platform eliminates entirely.
Why GCs end up choosing — and what they lose
Faced with the complexity of running two scheduling methods, many large GCs eventually drift toward one or the other. Here's what each choice costs them.
Neither choice is viable for a large GC. The owner requires CPM. The field requires lean planning. The executive team requires both, aggregated across 50+ projects, available in real time. The only honest answer to "which should we use?" is: both — and they need to be connected.
What a unified platform actually changes
The argument for a unified platform isn't simply about convenience — it's about the decisions that become possible when CPM and lean planning share a data model.
Smartapp PLANNER™ — unified scheduling architectureSmartapp PLANNER™When CPM and lean planning live on the same data model, several things change that aren't possible when they're in separate tools:
- 1 Field sequences update the critical path automatically. When the superintendent finds a better sequence in the pull planning session — starting mechanical rough-in two weeks earlier, for example — that change surfaces immediately in the CPM model. The project manager can see the critical path implications before committing to the change, not after.
- 2 Critical path changes flag in the pull plan immediately. When a material delivery delay shifts a critical path activity, the pull plan is automatically flagged — the superintendent sees the change and can adjust the 6-week lookahead before the field team shows up expecting work that isn't ready. No separate notification. No manual reconciliation.
- 3 PPC (Percent Plan Complete) is meaningful against the CPM baseline. When lean boards are disconnected from CPM, a high PPC doesn't tell you whether you're making progress on the critical path or just completing easy non-critical tasks. With a unified model, PPC becomes a genuine indicator of schedule health, not just activity completion.
- 4 Executive portfolio visibility becomes real. For a GC running 50 projects, ORG Central can show schedule health across the portfolio — drawing from both the CPM status and the lean PPC data simultaneously. A project showing a healthy CPM but deteriorating PPC is an early warning signal that's invisible when the two systems are separate.
- 5 One platform means one source of truth for the entire project team. The executive, the PM, the superintendent, and the foreman all see the same project — at different levels of detail, but from the same underlying data. "Which schedule are we working from?" stops being a question anyone has to ask.
"We'd been running CPM in Primavera and lean planning on whiteboards for years. When we moved both into
— Project Director, Gilbane Building Company
How to run both methods without doubling the work
A common objection to running both CPM and lean planning simultaneously is the workload: it feels like maintaining two schedules instead of one. In a disconnected tool environment, that objection is fair — it is more work. On a unified platform, the dynamic is different.
Start with the CPM as the backbone
The CPM schedule establishes the project's phase milestones, logic dependencies, and critical path. In Smartapp PLANNER™, this becomes the backbone of the project — the structure from which the pull planning sessions work. The superintendent doesn't start the pull plan from a blank whiteboard; they start from a view of the next 8–12 weeks of CPM activities, filtered to their scope and area of responsibility.
Run weekly pull planning sessions against CPM milestones
Pull planning sessions work backwards from the next CPM milestone — typically four to six weeks out. Trades commit to what they will actually complete in the upcoming weeks, identify constraints that need to be resolved, and flag sequencing opportunities or conflicts. Because the milestone is anchored in the CPM, the field team's commitments are always made in the context of the long-range schedule — not in isolation.
Let the field update the schedule — with guardrails
On a unified platform, field-initiated sequence changes in the pull plan can be configured to update the CPM automatically — or to flag for PM review before the CPM is updated. This gives the field team genuine agency over the schedule (which is essential for lean planning buy-in) while giving the PM oversight of critical path implications (which is essential for contract compliance). The guardrail is the critical path: changes to non-critical activities flow freely; changes to critical path activities require PM approval.
Review PPC in the context of CPM float
Weekly PPC reviews are more meaningful when framed against CPM float data. A 75% PPC on non-critical activities is very different from a 75% PPC on critical path activities. On a unified platform, the PPC dashboard shows which planned tasks sit on the critical path — so the conversation in the weekly review is focused on the tasks that actually matter to project completion, not just the tasks that happened to be in the six-week window.
What to look for in a unified scheduling platform
Not all platforms that claim to support both CPM and lean planning actually integrate them meaningfully. Here are the questions to ask when evaluating whether a platform genuinely unifies the two methods — or just offers both as separate modules with a logo on the same login screen.
- 1 Do they share a data model? The pull plan and the CPM schedule should draw from the same underlying activity and resource data — not two separate databases that are periodically synced. If the answer involves a "sync" button or a nightly batch process, they're not truly unified.
- 2 Does a pull plan change update the CPM in real time? The clearest test of integration: change a sequence in the pull plan and watch whether the CPM critical path recalculates immediately. If it doesn't, the two are not connected.
- 3 Can the pull plan be generated from the CPM automatically? Building a pull plan manually from a CPM baseline is time-consuming and error-prone. A unified platform should allow the superintendent to pull the relevant CPM activities directly into the 6-week pull plan window with one step — not by retyping activities from a PDF export.
- 4 Is PPC tracked against CPM activities? Percent Plan Complete should be reportable against specific CPM activities — not just as a standalone lean metric. This is what allows PPC to be a meaningful critical path health indicator rather than just an activity completion counter.
- 5 Can the executive team see both in a portfolio view? For a large GC managing 50+ projects, the scheduling platform needs to aggregate both CPM health (schedule variance, critical path status) and lean health (PPC trends, constraint backlog) across all active projects — in a single executive view, without requiring a project-by-project drill-down to understand portfolio risk.
The bottom line
CPM and lean pull planning have coexisted awkwardly on construction sites for thirty years — respected separately, rarely integrated, consistently blamed on each other when the schedule goes wrong. The CPM is too rigid, say the lean advocates. Lean planning lacks rigour, say the CPM defenders. Both sides are identifying real symptoms of a structural problem: the two methods were never designed to be used in the same data environment, so they weren't.
For large general contractors, the cost of that separation is no longer just a management inconvenience. It's a compounding risk across a portfolio of 50, 100, or 200 simultaneous projects — each one carrying the gap between what the contract says will happen and what the field says is actually happening. Every week those two pictures are allowed to diverge is a week of schedule risk that someone will eventually have to account for.
The solution isn't to choose a better CPM tool or a better lean planning tool. It's to stop treating them as separate problems. When CPM and lean planning run on the same data model — as they do in Smartapp PLANNER™ — the gap disappears. The field plan and the contract schedule are the same document, viewed at different levels of detail, kept in sync automatically. The executive sees portfolio health. The superintendent sees next week's work. The owner gets accurate CPM reports. And the PM stops spending 4–6 hours a week reconciling two schedules that should never have been separate in the first place.
Smartapp PLANNER™
See CPM and lean planning unified in Smartapp PLANNER™
Request a demo and we'll walk through how Smartapp connects your CPM baseline to your pull planning sessions — with your project types and team structure.
