The links are the schedule.

Change one link and the finish date moves. Change one link badly and the critical path runs straight through the wrong part of the job — while you manage the wrong crew.

So this week we wire the model properly.

Boxes and arrows

Modern scheduling has one shape. Each activity is a box. Each link is an arrow. The arrow means one thing only: this must happen in relation to that.

Nothing else. Not "these people work together." Not "this feels like it comes next." The arrow is a physical or contractual constraint on the order of the work.

You can build this on a wall with sticky notes before you ever open the software — and honestly, that's often the best way to catch the mistakes.

Four ways to link work

There are only four. You'll use two of them constantly, one occasionally, and one almost never.

Finish to start is the workhorse. Pour the slab, then strip the formwork. It's most of your network, and it should be.

Start to start lets work overlap. You don't wait for the entire road base to be finished before paving begins — you start paving three days behind it, and the two crews move down the road together. That three days is a lag: not a delay, just an offset.

Finish to finish ties the ends together. Backfilling can't finish until pipe testing has finished — the two run alongside each other, but one can't get ahead at the end.

Start to finish is the strange one. If you find one in your network, look twice. In nearly every real case it's a mis-click, not a decision.

Lag is physics. Not people.

A lag is a mandatory wait between two linked activities. Concrete cures for seven days whether anyone shows up or not. That's a lag. It consumes no crew, no plant, no money. It's just time the physical world demands.

Now the abuse. A ten-day lag labelled "client review" is not physics. That's a person, doing work, on a deadline — and by burying it inside a link, you've made it invisible. It has no owner, no name, and nobody chases it.

Give it an activity. Put the client's name on it. Waiting that belongs to someone should be visible enough to be someone's problem.

And the mirror image: the lead — a negative lag, letting work start before its predecessor finishes. It's tempting and it's rarely honest. If two activities genuinely overlap, say so with a start-to-start link. A negative number buried in a relationship is a decision nobody can see, and nobody will remember making.

Two faults that break the model

A network has laws. Break them and the schedule stops being able to calculate the truth — usually without telling you.

The first is the dangling activity — one with nothing after it. It looks harmless. It's the most dangerous thing in your model, because it can slip for weeks and never push anything. The software reports comfortable float. The float is fiction. Nothing downstream is listening.

The rule is simple. Apart from the project's single start and single finish, every activity has something before it and something after it. No exceptions, and no "we'll link it later."

The second fault is the loop — A feeds B, and B feeds back into A. You've asked time to run in a circle. Most software will refuse to calculate; some will quietly do something wrong. Either way, work only ever flows one direction: forward.

Where the paths meet

One more structural weakness — and this one you'll recognise instantly from site.

Look at any handover milestone. How many chains feed into it? The structure. The MEP first fix. The facade. The lift.

Every one of those paths is an independent chance to be late. The milestone only hits if all of them do. That's not one risk — it's four risks stacked on a single date.

This is path convergence, and it's where projects quietly break. A milestone with one feeder is a milestone. A milestone with six is a bottleneck wearing a diamond.

When you spot one, do something about it structurally: protect it with visible time, or break the convergence by staging the handover. What you should never do is look at four merging chains and feel reassured because each one, on its own, is currently green.

Your network is chains. The dates you promise are only as good as the logic holding them together — and one bad link is enough.

Practical insight

Before your next update, run three checks on the network.

Does anything have no successor? Does any link loop backwards? And how many chains land on your next big milestone — because that number is your real risk, no matter what colour the report is.

Ten minutes of network hygiene buys you a forecast you can actually defend.

Key takeaways

✔ The logic is the schedule — the bars are only what the logic looks like.
✔ An arrow means a real constraint on order, not a habit or a hunch.
✔ Finish-to-start carries most of the network; SS and FF let work overlap honestly.
✔ A start-to-finish link is almost always a mis-click — check every one.
✔ A lag is physics (curing). Someone's waiting is work — give it a visible activity.
✔ Avoid leads; if work truly overlaps, model it with a start-to-start link.
✔ Every activity needs a predecessor and a successor — dangling activities produce fake float.
✔ Loops make time run backwards; the engine can't solve them.
✔ Watch path convergence: a milestone is only as good as its worst feeder.

What's coming next

The network is wired. It still can't tell you a date.

Because logic alone doesn't produce a schedule — it needs numbers. Next week we tackle estimating: where durations actually come from, why doubling the crew never halves the duration, and how to build an estimate you can defend when someone senior tells you it's too long.

Logic gives the model its shape. Estimates give it its size.