Sequence the Work, Staff the Plan

Schedules don’t slip because people are slow

Open most design schedules and you find a Gantt chart full of dates — bars that say when each task is “supposed” to happen. But a row of dates is not a plan. When a design project slips, it is almost never because someone was lazy. It is because someone was waiting on information that no one sequenced to arrive: the architect couldn’t place the floor plan because mechanical hadn’t sized the equipment, because the owner hadn’t chosen a system.

Think of a patient moving through a hospital. The journey is a series of handoffs — intake to triage to imaging to surgery — and a delay anywhere stalls everything after it. A design project is the same: the project is the patient, the disciplines are the caregivers, and what moves between them is information. Plan the handoffs and the schedule takes care of itself.

Design work flows on information, not effort. Sequence the information, and the work follows.

That is Logic-Based Planning: instead of guessing dates forward, you start from the deliverable and work backward, sequencing the flow of information so every task has what it needs the moment it needs it.

Three kinds of planning, three constraints

Every project plan is really three plans at once, and the PM’s job is to keep them in balance. Each one carries a constraint, and good planning focuses effort on releasing the binding constraint while keeping the team moving toward the goal.

Module 6 built the financial plan (the budget) on top of the task plan (the WBS). This module adds the schedule to the task plan and then lays the resource plan over both. The art is sequencing the work so the binding constraint — usually a piece of information or a single over-booked person — is released before it stalls the team.

Five frameworks, high level to detail

Logic-Based Planning (LBP) ensures design teams work to the logical flow of information between disciplines. It runs in five frameworks, sequenced from the whole phase down to this week’s work — each one keeping the team aligned to the deliverables that matter.

Plan the work in reverse

Pull Planning builds the schedule backward from a milestone. You start at the end — the deliverable that must be true at, say, 30% Design Development — and ask one question over and over: “What is needed immediately before this, in order to deliver it?” Each answer is a handoff: one discipline needs something, and once they get it they provide something to the next, in a stated duration. Chain those handoffs and you have built the critical path of information.

The discipline is to separate deliverables from information, and to phrase every link the same way: “In order for me to provide X, I need Y. Once I have it, I’ll provide X in N days.” Step back through an Oakhaven 30% DD milestone and watch the chain assemble — and the start date reveal itself:

Working backward, the chain reveals that the owner’s system selection is the true start of this milestone — and because the owner needs a review window, the initiating act is the PM putting three system options in front of the owner about three weeks before the deadline. Plan it forward and you’d never see that. Pull it backward and it’s obvious.

One board for the handoffs, one for each discipline’s week

The critical path of needs and provides is best drawn as a swim-lane diagram: one lane per discipline, time across the top, and the information handoffs flowing between lanes. It shows who initiates each handoff, who receives it, and when — the project’s nervous system on one page.

The swim-lane plan deliberately shows only the shared, critical handoffs — the items with the greatest impact on the whole team. The parallel work inside each discipline lives in a Biweekly Work Plan: each group pulls its own tasks back from its milestone commitments and plans in a rolling two-week look-ahead — drop the finished week, confirm the next, add one new week. It keeps the milestone board decluttered while every discipline still sees the whole.

From role demand to real people — and a way to measure progress

The schedule tells you when; the soft-resource plan from Module 6 tells you which role. Lay one over the other and you get a resource heatmap — how many hours of each role the project needs, week by week. That demand is abstract until you hard-schedule it: assign real people, and check that the person you need isn’t already booked solid elsewhere.

Now combine all of it — the work, the hours, the schedule — into one instrument the PM lives by: the Earned Value Plan. A Gantt of the sequenced work, weighted by each task’s share of the fee, produces a curve of how much of the fee should be earned by each point in time. It is the roadmap that lets you answer, every week, the Module 3 question: are we earning value as fast as we’re spending effort?

Planning is a process, not an event

A pull plan, a swim-lane board, and an Earned Value Plan are not documents you build once and file. The whole point of Logic-Based Planning is that it stays alive: the team revisits the milestone plan and its biweekly work plans on a regular cadence, adjusting as information arrives and constraints shift. The Accountable Owner owns that rhythm — appointing a keeper of the plan, distributing it, and protecting the review.

Sequence the information, staff the flow, and keep the plan current — that is how a budget becomes a delivered project.

With Modules 6 and 7, planning is complete: the work is broken down, priced, sequenced, and staffed, with a roadmap to measure it against. Everything in Managing Execution is the act of holding the team to this plan — and adjusting it honestly when reality pushes back.