What "Load In Sequence" Actually Means, And Why It Drives Everything Else

A load in sequence is the order in which the elements of an event build must happen, based on what each one depends on; power in and tested before anything draws load, ground protection down before heavy plant crosses turf, rigging points certified before anything is hung. It is not the same as the load in schedule, which sets arrival times and call times. The sequence resolves the dependencies. The schedule publishes the timings once those dependencies are known.

Confuse the two and you end up managing arrival times while the real problem (what has to be finished before the next thing can start) goes unmanaged until it surfaces on the ground.

Sequence vs schedule: why the distinction matters

Ask ten people on site what the load in sequence is and most will describe a timetable: who arrives when, which truck backs in first, when the marquee crew get access. That is the visible version, and it is the version that gets teams into trouble.

A sequence answers a harder question than "when." It answers "in what order, given what has to be true first." Power distribution has to be in and tested before anything drawing load can be commissioned. Ground protection goes down before heavy plant crosses turf you are contractually obligated to return intact. Rigging points get certified before anything hangs from them. Structural elements land before the trades that dress them can begin. None of that is about time of day. It is about what depends on what.

Map it as dependencies and the timetable almost writes itself. Map it as a timetable first and you spend the build discovering dependencies you should have found on paper.

What a broken load in sequence looks like on site

None of these read as a sequencing problem in the moment:

• A forklift sitting idle because the deliveries it needs are stacked behind the deliveries that came in the wrong order.

• A crew stood down on penalty rates because the area they were booked to work is still occupied by the trade that should have finished yesterday.

• A generator that cannot be positioned because the cable run was planned after the structure went in, not before.

• A ground protection dispute with the venue at 6am because plant has already crossed grass that was meant to be boarded first.

Every one of those gets logged as a delay, a labour overrun, or a venue issue. The root cause is upstream: two things were allowed to compete for the same space, access point, or moment, because the order they depended on each other was never made explicit.

How to sequence by dependency, not convenience

The most common failure is sequencing by convenience: the order that suits each supplier's own logistics, or the order things happened to get booked. Suppliers optimise for their own load, which is fair enough. Your job is to optimise for the whole site, which sometimes means asking a supplier to arrive later, stage off site, or split a delivery so the critical path stays clear.

A quick way to pressure test a draft sequence: for every major element, ask what has to be physically complete, certified, or powered before this can begin, and what this blocks if it slips. If you cannot answer both for an element, that element is a risk, not a plan.

Why the sequence drives everything downstream

Get the sequence right and the rest of the build inherits it. Labour call times become defensible because they are pinned to readiness, not optimism. The schedule carries slack in the right places because you know which links are load bearing. Safety improves because you are not running incompatible activities in the same footprint at the same time. And the budget holds, because the expensive failures (idle crews, redos, penalty rates, remediation) are exactly the failures a good sequence prevents.

Get it wrong and none of that is recoverable on the day. You cannot re-sequence a build once trucks are rolling and crews are booked. You can only absorb the cost.

The takeaway

The load in sequence is the most consequential document you produce before build, and it is the one most often treated as an afterthought to the run sheet. It deserves the opposite: resolve the dependencies first, and let the timetable fall out of them.

It is also the clearest case for testing a sequence before you commit to it; walking the order of build against the site, the access points, and the real constraints while changes still cost nothing. The cheapest place to find a sequencing clash is on a plan. The most expensive is at 6am on a live load in.

FAQ

What is the difference between a load in sequence and a load in schedule? The sequence is the dependency order what must be complete, certified, or powered before the next task can start. The schedule is the published timeline of arrivals and call times, built once the sequence is resolved.

What happens when a load in sequence is wrong? The symptoms show up as delays, labour overruns and venue disputes; idle plant, crews stood down on penalty rates, generators that cannot be positioned. The root cause is upstream: two tasks competing for the same space, access or moment.

How do you pressure test a load in sequence? For every major element, ask what must be physically complete, certified or powered before it can begin, and what it blocks if it slips. If you cannot answer both, it is a risk rather than a plan.