How a schedule gets built.

These nine steps aren't a bureaucratic checklist. They're an assembly line. Each step depends on the one before it: you can't estimate a duration before you know who's doing the work, and you can't find the critical path before the logic is in.

Here's the whole line, start to finish.

They fall into three stages. Let's walk through each.

Build the skeleton (steps 1–3)

Step 1 — Milestones. Start with the anchors. Milestones are moments, not work: zero duration, no resources. "Site access approved." "Phase 1 safety sign-off obtained." They're the fixed points everything else hangs between — clear and binary, either done or not.

Step 2 — Activities. Now turn the WBS into real, doable work. But not just any work. A proper activity has three things.

It's named so anyone knows exactly what it is — a verb, an object, a location. Not "pour the wall." Try "pour Zone A, east facade foundation." It has one accountable owner. And it's short enough that if it slips, you catch it within a reporting cycle or two — not three months later.

Step 3 — Logic. Link the activities by how the work actually happens. Most links are simple: finish this, then start that. Some overlap; a few are trickier. We'll take the link types apart in a later week.

One rule matters now: nothing should dangle. Except the very first and very last, every activity needs something before it and something after it. A floating activity with no successor is a hole in your forecast — the model can't tell you what its delay would cost.

And a warning: don't hide someone else's work as a gap. If the client needs ten days to review, don't bury that as a "lag" in the logic — the responsibility disappears. Give it a visible task with the client's name on it. What has an owner gets done.

Make it calculate (steps 4–6)

Step 4 — Resources. Only now can you talk about duration — because duration depends on who's doing the work. A senior foreman and an apprentice pour the same slab at very different speeds. Assign the crew and the plant first; the honest duration follows from real productivity, not from a wish.

Step 5 — Durations. Sometimes one number is enough — routine work you've done a hundred times. For risky or first-of-a-kind work, a single number is false precision. There you use a range — optimistic, likely, pessimistic — so you can tell the client "we're 80% likely to finish by this date" instead of a promise you can't keep.

Step 6 — Run the network. With logic, resources and durations in place, the model finally calculates. It works forward to find the earliest each activity can happen, then backward to find the latest. The gap between them is float — the slack an activity has before it starts pushing the finish date.

The activities with zero float form the critical path — the chain that controls your completion date. Touch anything on it, and the end moves. The full forward-and-backward-pass maths gets its own week; for now, know this is the moment the schedule starts telling you where the danger is.

Make it real (steps 7–9)

Step 7 — Compress, if you must. The model gives you a date. It's too late. Now what?

You have two moves. Crash the critical path — throw more crews or overtime at it. It works, but it costs money. Or fast-track — overlap activities that were meant to run in sequence, like starting procurement while the design is still finishing. That costs nothing up front, but it buys you risk and rework. You trade cost against risk until the date and the stakeholders both agree.

Step 8 — Baseline. Once the plan is approved and realistic, you freeze it. That frozen snapshot is your baseline — and there's a hard rule: no physical work starts without an approved baseline. It's the immutable line every future measurement is judged against. Lose it, and you've nothing to compare reality to.

Step 9 — Layer it. The same model, shown at different altitudes. The sponsor sees a handful of milestones. The project team sees the interfaces and the critical path. The site sees this week's tasks. One model, many views — so nobody drowns in detail, and nobody flies blind.

That's the whole line. And underneath all nine steps sits one simple truth:

Logic sets the dates. Resources set the durations. The baseline fixes reality.

On site, you never cut a beam on the first measurement. You measure twice, because the cut is permanent.

A baseline is the same. Get the plan right before you freeze it — because from that moment on, every delay, every claim, every forecast is measured against it.

Practical insight

You don't need to memorise nine steps. You need to respect the order.

Before you calculate a date, ask: are the milestones set? Is every activity named, owned, and small enough to control? Does the logic hold, with nothing left dangling? Only then does the network mean anything.

A schedule built in the right order calculates the truth. One built out of order just draws a picture.

Key takeaways

✔ A schedule is assembled in nine steps, in order — not typed.
✔ Milestones are zero-duration anchors; activities are named work with one owner.
✔ Name activities by verb + object + location, small enough to catch a slip.
✔ Link the logic so nothing dangles — every activity needs a predecessor and a successor.
✔ Give someone else's wait, like a client review, a visible task — not a hidden lag.
✔ Resources set the durations; the network reveals float and the critical path.
✔ Shorten with crashing (costs money) or fast-tracking (buys risk).
✔ No physical work starts without an approved, frozen baseline.

What's coming next

This week we walked the whole assembly line, end to end. Next, we slow down and open the toolbox.

Week 8 goes deep on the components themselves — the activity types you'll actually use, the calendars that decide what a "day" even means, and the data that makes a schedule behave. The nuts and bolts behind the nine steps.

We've seen how a schedule is built. Now let's master what it's built from.