The Last Planner System I: master and phase planning

The Last Planner System (LPS) is the best known and most widely used lean construction practice. It was developed in the 1990s by Glenn Ballard and Greg Howell, who observed that on typical projects only about half of the work that crews planned to do in a given week actually got done. The rest was blocked by missing prerequisites, materials or information. Their response was a planning system built around a simple idea: the people who will do the work, the last planners in the chain from the master schedule to the crew, should plan it, and they should commit only to work that is actually ready. This lesson introduces the system as a whole and covers its first two levels, the master schedule and the phase plan produced by pull planning. Lessons 5 and 6 cover look-ahead planning, weekly work plans and learning.

Should, can, will, did

Ballard summarized the logic of the Last Planner System in four words. The master schedule says what work should be done. The look-ahead process identifies what can be done by removing constraints. The weekly work plan records what the last planners will do, as reliable promises. Measuring and learning records what they did and why commitments were missed. Traditional planning goes straight from should to the crew and hopes that the work can be done. The Last Planner System inserts the can step, so that will is made from work that is ready.

Who the last planners are

The last planner is the person or group that makes the final decision about what a crew will do on a given day: usually a trade foreperson or crew leader, sometimes a superintendent for self-performed work. They are last in the chain of planning, after owners, schedulers and project managers, and they know what their crews can actually achieve. The Last Planner System gives them a direct role in building the plan and asks them to make promises they are confident they can keep. This is a cultural change for many sites, where forepersons are used to receiving a schedule and being blamed when it slips.

A last planner should be able to say yes, no or not yet to a request. Saying no to work that is not ready is not obstruction; it is information that the work is blocked, which the team can act on. A plan built from honest no's and reliable yeses is worth far more than one full of optimistic promises.

The master schedule in a lean project

The Last Planner System does not replace the master schedule. Most contracts still require a critical path schedule, and CON-210 covers how to build and update one. In a lean project, however, the master schedule is kept at a summary level: major milestones, phases and long-lead items, rather than thousands of detailed activities planned months in advance by someone who will not do the work. Detail is added progressively, as the phase approaches, by the people who will do it. This reflects a basic principle of planning under uncertainty: the further ahead a plan looks, the less reliable its detail is, so detail should be added as late as is responsible and no later.

Milestones in the master schedule should be meaningful hand-offs, not arbitrary dates: building enclosed and dried in, permanent power energized, elevator available for construction use, floor ready for finishes, substantial completion. Each becomes the target for a phase plan.

Pull planning

A phase plan is usually built in a pull planning session (also called a phase scheduling or reverse phase scheduling session). The trades involved in a phase meet, often in front of a long wall or a digital board, and plan backward from the phase milestone. Starting from the milestone, the team asks what must be finished for this to happen, writes each hand-off on a sticky note with the responsible trade, the duration and what that trade needs from others, and places the notes in sequence working backward toward the present. Planning backward from a defined finish forces each trade to state exactly what it needs and when, which reveals hand-offs that a forward-planned schedule hides.

A good session takes two to four hours for a phase and works best with a trained facilitator, the actual forepersons who will run the work rather than estimators or salespeople, and clear ground rules: no blaming, durations without hidden padding and an honest statement of what each trade needs.

From sticky notes to a network

The output of a pull planning session is a network of hand-offs, just like a CPM network, but built backward from the milestone by the trades themselves. It can be checked with the same backward-pass arithmetic that CON-210 uses. The code below turns a set of sticky notes for Willowmere Residences floor 2 into latest start and finish days, working back from the milestone date.

# Pull plan for Willowmere floor 2: backward pass from the milestone (working days)
notes = {  # task: (trade, duration, successors)
    "layout":            ("Northgate", 1, ["top track"]),
    "top track":         ("Framing",   2, ["mech rough-in", "elec rough-in", "plumb rough-in"]),
    "mech rough-in":     ("Mechanical", 5, ["in-wall inspection"]),
    "elec rough-in":     ("Electrical", 4, ["in-wall inspection"]),
    "plumb rough-in":    ("Plumbing",   4, ["in-wall inspection"]),
    "in-wall inspection": ("City/Northgate", 1, ["insulation"]),
    "insulation":        ("Insulation", 2, ["board"]),
    "board":             ("Drywall",   5, ["MILESTONE"]),
}
milestone_day = 40   # floor 2 ready for taping on working day 40
buffer = 3           # project buffer held before the milestone
latest_finish, latest_start = {}, {}
def lf(task):
    if task in latest_finish:
        return latest_finish[task]
    succ = notes[task][2]
    f = min(milestone_day - buffer if s == "MILESTONE" else ls(s) for s in succ)
    latest_finish[task] = f
    return f
def ls(task):
    if task not in latest_start:
        latest_start[task] = lf(task) - notes[task][1]
    return latest_start[task]
for t in notes:
    ls(t)
for t, (trade, d, _) in sorted(notes.items(), key=lambda kv: latest_start[kv[0]]):
    print(f"{t:<20}{trade:<16}{d:>2} d  start by day {latest_start[t]:>2}  finish by day {latest_finish[t]:>2}")
print("Phase must start by day", min(latest_start.values()))

layout              Northgate        1 d  start by day 21  finish by day 22
top track           Framing          2 d  start by day 22  finish by day 24
mech rough-in       Mechanical       5 d  start by day 24  finish by day 29
elec rough-in       Electrical       4 d  start by day 25  finish by day 29
plumb rough-in      Plumbing         4 d  start by day 25  finish by day 29
in-wall inspection  City/Northgate   1 d  start by day 29  finish by day 30
insulation          Insulation       2 d  start by day 30  finish by day 32
board               Drywall          5 d  start by day 32  finish by day 37
Phase must start by day 21

The backward pass shows that layout must start by day 21 for the floor to be ready on day 40 with a three-day buffer. If today is day 18, the phase has three days of float beyond the buffer. If today is day 24, the team must find time: overlapping rough-in trades by zone, adding a second board crew or shortening the inspection lead time. These conversations are the point of pull planning. The trades who will have to deliver the overlap are in the room and can commit to it, or explain why they cannot.

Buffers in phase plans

Every task duration has some uncertainty. In traditional schedules, each trade quietly pads its own durations, and the padding is consumed by the work expanding to fill the time available (Parkinson's law) or by late starts. Lean phase planning asks trades to give realistic durations without padding and then places a single, visible schedule buffer before the milestone, owned by the whole team. Because the uncertainties of different tasks partly offset each other, a pooled buffer can be smaller than the sum of individual pads while giving the same protection. The buffer is consumed as problems occur and tracked so that the team knows when the milestone is at risk. Lesson 8 returns to buffers in more detail.

# Why a pooled buffer can be smaller than the sum of individual pads (seeded simulation)
import random, statistics
rng = random.Random(410)
tasks = [(5, 1.0), (4, 0.8), (4, 0.8), (2, 0.5), (5, 1.0)]   # (planned days, std dev) on the path
N = 20000
totals = []
for _ in range(N):
    totals.append(sum(max(0.5, rng.gauss(d, s)) for d, s in tasks))
p90_each = sum(1.2816 * s for _, s in tasks)                 # padding every task to its own P90
pooled = statistics.quantiles(totals, n=10)[8] - sum(d for d, _ in tasks)
print(f"Sum of individual P90 pads: {p90_each:.1f} days")
print(f"Pooled buffer for P90 of the whole path: {pooled:.1f} days")

Sum of individual P90 pads: 5.3 days
Pooled buffer for P90 of the whole path: 2.4 days

Conditions for a good pull plan

Pull planning works when the right people are present, the milestone is meaningful and the team acts on what it learns. It fails when the session is treated as a meeting to approve a schedule already prepared in the office, when the people present cannot commit their companies' crews, or when the plan is filed and never used. The phase plan should feed directly into the look-ahead (lesson 5), and trades should revisit it when things change significantly.

Last Planner and the contract

The Last Planner System can be used under any contract, but its effectiveness depends on relationships. Under design-bid-build with adversarial subcontracts, trades may be reluctant to reveal what they need or to admit that work is not ready, for fear of backcharges. Collaborative delivery methods such as integrated project delivery and alliancing (CON-340) align incentives so that trades share in the outcome and have reason to plan together. Many general contractors now include participation in pull planning, look-ahead and weekly planning meetings in their subcontracts, and some owners require the Last Planner System by specification. Contract language should support collaboration: it should make participation part of the scope while preserving each party's ordinary rights to notice, time and payment.