A wall of Post-it notes can make a pull plan easy to build together. The trouble begins after the meeting, when someone photographs the wall, retypes the plan into a spreadsheet, calculates dates, and keeps a separate list of constraints.
Michael Carr described that handoff in the 2018 Constructrr episode about Touchplan. If an activity moved on the wall, the related permit, submittal, answer, or delivery date did not automatically move with it. The plan and the make-ready work could drift apart during the translation.
This is where digitizing Last Planner can earn its place. The benefit is not a digital copy of the wall. It is keeping the team's commitments and the conditions behind them connected as the work changes.
The plan has to look forward
Michael Carr began with a frustration from his early project-engineering work. Too much control effort documented events after they had already happened. Last Planner shifted attention toward the people closest to the work and the commitments needed for the next handoff.
Michael used flow to explain why that matters. One trade's finish creates the next trade's start. Keeping every company busy inside its own scope can still interrupt the project when those handoffs do not line up.
Four links make a weekly commitment useful
The episode described four pieces that need to stay together:
- Readiness means clearing permits, submittals, answers, materials, and other constraints before the activity is promised.
- Ownership means the trade responsible for the work makes and updates the commitment instead of sending every change through one project engineer or manager.
- Learning means recording why a commitment was missed and adjusting the next similar activity rather than discovering the accumulated delay much later.
- Dependency means changing the due dates for prerequisites when an activity date changes.
Michael Carr described Touchplan as one way to keep those links inside the same workflow, saying “there's no loss in translation.” The product examples belong to 2018. The planning test does not depend on the product name: can the team trace a weekly promise back to its owner, its open constraints, and the reason it changed?
A real-time plan should not create one full-time updater
The host asked about the burden on the person responsible for maintaining project information. Michael Carr's answer was distributed updating. Ten or fifteen participants could each spend a few minutes updating the activities they owned, rather than one person collecting and re-entering every status.
That approach makes the source of an update visible. It also asks each trade to remain connected to the promise it made. Software can lower the effort required to maintain that connection. It cannot make a participant take ownership of the information.
Transparency has to be reciprocal
Michael Carr also described the limits of asking for openness inside a system built around transferring risk. A company may hesitate to expose contingency or a possible problem when it believes others will keep their own protection hidden. One participant sharing everything can feel less collaborative than exposed.
The episode connected transparency to psychological safety for that reason. The planning room has to make it reasonable for every participant to show a blocker before the blocker becomes a missed handoff. A shared screen does not create that condition by itself.
At the next weekly review, choose one promised start and follow its links. The trade should be able to show what is ready, what remains open, who owns the next answer, and how a change will move the dependent dates. When those links are visible, the plan can support the conversation it was built for.
