Constraint logs and making work ready

A task is ready when everything it needs is in place: the previous work is finished, the information is complete, the materials are on site, the crew and equipment are available, the space is clear and any required approvals have been given. Anything missing is a constraint. The look-ahead identifies which tasks are coming; the constraint log identifies what stands between each task and readiness, who is responsible for clearing it and by when. Together they drive the make-ready process that CON-410 described as the heart of the Last Planner System.

This lesson shows how Dana's team runs the constraint log on Larkspur Commons: how constraints are found and categorized, how ownership and due dates are assigned, how the log is reviewed each week, which measures show whether the process is working, and why even a small number of uncleared constraints can wreck a weekly plan.

Categories of constraint

Constraints fall into a small number of categories. Sorting them helps the team see where the problems are concentrated and who must act.

The categories are not just labels. Over the first month of interiors, Omar found that more than a third of the constraints on the log were information and submittal items, most of them created by questions that had been sitting unanswered for weeks before anyone noticed they would stop work. That finding changed how Mei managed questions to the design team: each question was now linked to the look-ahead task it affected, so its urgency was obvious.

Finding constraints

Constraints must be found early, ideally when the task first enters the look-ahead six weeks out. Dana's team uses four habits to find them.

• Screening each new task. When a task enters the look-ahead, Omar and the trade foreman go through the categories one by one: do we have the drawings, the materials, the crew, the equipment, the space, the inspections and the prerequisite work?
• Asking the foremen. Foremen know their own needs best. At the coordination meeting, each foreman is asked what could stop his crew in weeks three to six.
• Walking ahead. Once a week, Dana or Omar walks the zones that will receive new wagons in two to three weeks, looking for physical problems: incomplete work, damage, stored materials, missing guardrails.
• Reviewing the logs. The question log, the submittal log and the procurement schedule are checked against the look-ahead for items that will be needed soon.

The screening questions are simple, but asking them systematically makes the difference. Without a screen, constraints are discovered when the crew arrives, which is too late.

The constraint log

The constraint log is a list, usually a shared spreadsheet or a module in the field management software, with one line per constraint. On Larkspur Commons each line records the following.

Two features of the log matter most. Each constraint has one named owner, so there is no doubt who must act. And each has a need date tied to the task, so its urgency is visible. A constraint whose promise date is later than its need date is a problem that must be escalated immediately, not discovered on the day.

Reviewing the log each week

The constraint log is reviewed at the weekly coordination meeting, right after the look-ahead. Dana does not read every line aloud. Instead she sorts the log by need date and walks through the items due in the next two weeks and any that are overdue. Each owner reports on their items. Items that are stuck are escalated: to the project manager if they need a contractual or owner decision, to the subcontractor's project manager if they need labour or materials, or to the design team's lead if a question has stalled.

Two weekly measures show whether the make-ready process is working. The first is the number of open constraints and their age: a log that grows every week, with older and older items, means the team is finding constraints faster than it clears them. The second is the constraint removal rate, the share of constraints due in the week that were actually cleared by their need date.

Omar keeps both measures in a short report generated from the log. The script below shows the calculation for one week of the Larkspur Commons log.

# Weekly constraint log report (illustrative extract; working days)
today = 255
log = [  # (id, category, raised, need, cleared or None)
    (101, "Information", 238, 252, 251), (102, "Submittal", 236, 254, None),
    (103, "Materials",   241, 253, 253), (104, "Crew size",    246, 255, 254),
    (105, "Information", 240, 255, None), (106, "Inspection", 249, 254, 254),
    (107, "Prerequisite", 247, 253, 255), (108, "Equipment", 250, 255, 252),
    (109, "Information", 244, 262, None), (110, "Submittal", 243, 265, None),
    (111, "Space",       252, 256, None), (112, "Owner",     239, 270, None),
]
due = [c for c in log if today - 5 < c[3] <= today]           # due in the last week
on_time = [c for c in due if c[4] is not None and c[4] <= c[3]]
print(f"Due this week {len(due)}, cleared by need date {len(on_time)},"
      f" removal rate {len(on_time) / len(due):.0%}")
open_items = [c for c in log if c[4] is None]
for cid, cat, raised, need, _ in sorted(open_items, key=lambda c: c[3]):
    age, late = today - raised, need < today
    print(f"  #{cid} {cat:<12} open {age:>2} days, need day {need}{'  OVERDUE' if late else ''}")
cats = {}
for c in open_items:
    cats[c[1]] = cats.get(c[1], 0) + 1
print("Open by category:", ", ".join(f"{k} {v}" for k, v in sorted(cats.items(), key=lambda kv: -kv[1])))

Due this week 8, cleared by need date 5, removal rate 62%
  #102 Submittal    open 19 days, need day 254  OVERDUE
  #105 Information  open 15 days, need day 255
  #111 Space        open  3 days, need day 256
  #109 Information  open 11 days, need day 262
  #110 Submittal    open 12 days, need day 265
  #112 Owner        open 16 days, need day 270
Open by category: Submittal 2, Information 2, Space 1, Owner 1

Eight constraints were due this week and five were cleared on time, a removal rate of 62 percent. One submittal is already overdue and an information item is due today, so both are blocking or about to block work. The open items are dominated by information and submittals again. Dana's response is to hold a short meeting the next morning with Mei and the architect's project lead to work through the open questions, rather than waiting for them to be answered one by one.

Why every constraint matters

It is tempting to think that clearing most constraints is good enough. It is not, because a task needs all of its constraints cleared to start. If a task has several independent constraints, each with a good chance of being cleared on time, the chance that all of them are cleared together is much lower. Mei illustrated this at a coordination meeting with a short simulation.

# Chance that a task is ready on time when it depends on several constraints (illustrative)
import random
random.seed(7)
def ready_share(n_constraints, p_each, trials=20000):
    ok = 0
    for _ in range(trials):
        if all(random.random() < p_each for _ in range(n_constraints)):
            ok += 1
    return ok / trials
for p in (0.80, 0.90, 0.95):
    row = [f"{ready_share(n, p):.0%}" for n in (1, 3, 5, 8)]
    print(f"Each constraint cleared {p:.0%} of the time -> ready with 1, 3, 5, 8 constraints: {', '.join(row)}")
print(f"Exact value for 5 constraints at 90%: {0.9 ** 5:.0%}")

Each constraint cleared 80% of the time -> ready with 1, 3, 5, 8 constraints: 80%, 52%, 32%, 17%
Each constraint cleared 90% of the time -> ready with 1, 3, 5, 8 constraints: 90%, 73%, 59%, 43%
Each constraint cleared 95% of the time -> ready with 1, 3, 5, 8 constraints: 95%, 86%, 77%, 66%
Exact value for 5 constraints at 90%: 59%

A task with five constraints, each cleared on time nine times out of ten, is ready only about 59 percent of the time. With eight constraints at 80 percent, it is ready less than one time in five. This is why tasks that look well prepared still fail, and why the make-ready process must aim for very high reliability on each constraint, not merely a good average. It also explains why reducing the number of constraints on each task, for example by delivering materials earlier or by resolving design questions in batches, improves reliability so much.

Screening before committing

The constraint log feeds directly into the weekly work plan. CON-410 explained that tasks should be committed to the weekly plan only when they are free of constraints, a step sometimes called screening or shielding production. On Larkspur Commons, a task with any open blocker in the constraint log cannot be put into next week's plan. If the task is critical, the team works to clear the constraint before the weekly meeting; if it cannot be cleared, the crew is assigned to other ready work, and the delay is dealt with openly.

Screening can feel uncomfortable at first, because it means admitting in advance that some planned work will not happen. Foremen and project managers may push to include tasks 'in case the material arrives'. Dana resists this, because tasks committed without being ready are the main reason weekly plans fail, and a plan that routinely fails teaches everyone to ignore it. It is better to plan less and deliver all of it than to plan more and deliver half.

Ready backlog

The make-ready process should produce a small reserve of ready work, often called the workable backlog. These are tasks with all constraints cleared that could be done if a crew finishes early or if a planned task falls through. On Larkspur Commons, the backlog includes podium and retail work, stair and shaft work, prefabrication of plumbing assemblies in the parking level and touch-up items from earlier zones. A healthy backlog of a few days of work for each major trade keeps crews productive without breaking the trade train.

Too much backlog is also a problem. Work made ready far too early ties up materials, space and attention, and may need to be redone if conditions change. The aim is enough ready work to absorb variation, not a warehouse of tasks waiting their turn.

Escalation

Some constraints cannot be cleared by the people on site. An owner's decision on a layout change, a design team that is not answering, a supplier with a long back order or a subcontractor that cannot staff its crews all need escalation. Dana's rule is that any constraint whose promise date is later than its need date, or that is overdue, goes to the project manager the same day with a clear statement of what it affects. The project manager then takes it to the owner, the design team or the subcontractor's management. Escalating early, with facts, is more effective than escalating late with complaints.

On Larkspur Commons, which uses a CCDC 2 stipulated price contract with the owner, many owner-side constraints, such as late decisions or late answers from the consultant, may also give the contractor grounds for a change in contract time. CON-420 explained the notice requirements; the constraint log, with its dates and owners, is valuable evidence if a claim is ever needed.