Two-week lookahead constraint log: turn a start date into ready work

The Buildalytic workflow

Buildalytic offers lookahead constraint follow-up workflows. Its workflow offering uses Brody to request readiness updates, record commitments and surface unresolved constraints for the person responsible for the activity. The steps, contacts, approvals and record destinations are agreed with your team during setup.

The Lean Construction Institute’s Last Planner System guidance describes collaborative planning and making work ready. This article proposes a small coordination log for that conversation. A two-week view is useful for near-term coordination, but it does not replace the longer planning horizon needed for long-lead decisions.

Sources: workflow offering; discuss the setup

Start with the work, location and handoff

An activity should be specific enough for the trade and superintendent to discuss. “Mechanical work” is too broad. “Install the reviewed Level 2 corridor supports in Area C” gives the team a location and a recognizable outcome.

Connect the activity to the current schedule reference and the person coordinating the handoff. Record the planned start and the date the prerequisites must be resolved. These dates may differ: a material problem discovered on the morning of installation is already late for planning purposes.

Keep the activity definition stable enough to compare week to week. If the scope changes, record the change. Otherwise, a task can appear complete because it was quietly narrowed while the remaining work disappeared from the view.

Ask what could prevent the start

Use a small set of prompts: design information, predecessor work, materials, access, labor, equipment, permits or inspections, and project-specific approvals. These categories help the conversation; they are not proof that every technical or safety prerequisite has been met.

Ask the trade to identify the actual constraint. “Materials” is a category. “Supplier has not confirmed delivery of the reviewed support assembly” is a problem someone can act on.

Do not equate confidence with evidence. A person can sincerely expect a delivery while lacking a supplier commitment. The log should distinguish a forecast, a confirmed promise and a verified event. That distinction makes the next follow-up clearer without turning the meeting into an argument about optimism.

Use one row per constraint

One activity can have several rows. That prevents the materials owner from accidentally closing an unresolved design question because the overall activity status turned green.

A fictional readiness review

Assume a ceiling installation is planned for Monday in Area B. The crew is available, but three prerequisites remain: reviewed coordination information, completion of work above the ceiling and delivery of the specified material.

The project engineer owns the information follow-up, the superintendent coordinates the predecessor handoff and the purchasing owner seeks delivery confirmation. Each constraint has a different closure record. An email saying “Monday should work” does not close all three.

By Thursday, the delivery is confirmed and the coordination record is available. The predecessor work remains open. The activity is therefore not yet marked ready. The superintendent decides whether to resequence another area, change the plan or pursue a recovery action. The log preserves the decision and the remaining risk.

This example is deliberately ordinary. The value lies in preventing three separate conversations from becoming one unsupported “ready” status. It does not claim that a particular planning method guarantees schedule performance.

Set the required-by date before the start date

A constraint’s required-by date should leave time for the next step. If the crew needs a delivery on Monday, confirmation on Sunday night may be too late to arrange an alternative. Let the responsible team define the planning lead time.

Use a consistent calendar basis. If one team uses working days and another calendar days, show the difference rather than hiding it in a formula. Site shutdowns, access windows and supplier calendars can matter even within a short lookahead.

Keep a longer-range view for constraints that cannot reasonably be resolved inside two weeks. The near-term log should receive those decisions from earlier planning. It should not become the place where the project first notices a twelve-week procurement requirement.

Run a meeting around decisions

Begin with changes to the upcoming work and the oldest unresolved constraints affecting it. Ask each owner for the next action, expected resolution and evidence. Do not spend the entire meeting reading green rows aloud.

When a forecast slips, discuss the effect on the activity and the decision required. A changed date without an action merely postpones the same conversation. If the responsible person lacks authority to remove the constraint, identify who can make the decision.

End by confirming which activities are considered ready under the project’s process and which remain conditional. Capture those distinctions in the shared record. A meeting summary should preserve uncertainty, not smooth it into a confident narrative.

Keep commitments separate from readiness

A trade can commit to supplying a crew while another prerequisite remains open. Preserve the commitment, but do not treat it as evidence that every constraint has disappeared.

Likewise, a delivery can arrive while an inspection or information question remains unresolved. Work readiness is the combined project decision supported by the relevant records. It is not simply the most recent positive event.

Use the existing subcontractor start-readiness checklist for the trade-specific mobilization conversation. The constraint log coordinates dependencies across trades and owners. The two tools should link to the same activity instead of creating competing versions of the start date.

Sources: subcontractor start-readiness checklist

Verify closure and preserve changes

When an owner marks a constraint resolved, attach the agreed evidence or a link to it. The reviewer should be able to understand why the state changed. “Discussed in meeting” is often insufficient if the actual decision cannot be found.

If a resolved constraint reopens, keep the original closure and record the new event. A design revision, damaged delivery or changed access condition can invalidate an earlier assumption. Reopening is useful information, not something to hide to protect the dashboard.

Keep the source system’s permissions. A broad coordination view can link to a restricted record without copying its contents. Automation should make the handoff easier while respecting who is authorized to review or change each record.

Learn from missed starts

Compare the plan with what actually happened. For missed work, record the observed reason and distinguish a new event from a constraint already known at planning time. Do not force every miss into “trade failed.”

Review repeated causes. If access uncertainty keeps blocking work, change the access-confirmation process. If delivery promises are unreliable, improve the supplier handoff and contingency planning. Counting reminders sent does not show whether the constraint was removed.

Use measures with clear denominators, such as planned activities with unresolved constraints at a defined review point. Avoid claiming a productivity gain from one fictional example or a small pilot without a comparable baseline.

How Buildalytic handles this workflow

Buildalytic’s custom workflows, calls and texts support the request-and-confirmation work around a constraint log. Connect each message to the activity, owner and required decision. Keep the schedule and project records as the authoritative references your team uses.

A useful demo includes the three-constraint ceiling example and one reopened issue. Ask how the team sees unresolved prerequisites, changes owners and records verified closure. The goal is a shared operational picture that survives a busy day on site.

To put this Buildalytic workflow to work, discuss the setup with your project’s source records, responsible people and expected outcome. Use the checks in this guide to verify the agreed process before rollout.

Sources: workflow offering; discuss the setup