Event Operations
The dry run is the cheapest insurance you will ever decline
An evening rehearsal against the real network, in the real room, finds the problems while they are still cheap to fix.
Hero art direction: Convention hall mid-build the night before: half-rigged truss, flight cases along one wall, work-lights in a dark space.
Everything works in the warehouse
Kit tested at base works. Software tested on the office network works. What has never been tested is the combination of your kit, your software, this venue's power, this venue's network and this room's radio environment — and that combination is what runs the event.
The dry run is where you meet it, and the only question is whether you meet it the evening before or at 08:15 with delegates arriving.
What a dry run has to include
The real network, not a hotspot. Plug into the circuit you will use on the day. Half the value is discovering that the port in the corner is on a different VLAN with no route out.
The real power. Everything on, drawing simultaneously. Loads that are fine individually trip a breaker together, and you want to find that at 21:00.
A full check-in, end to end. Twenty real records through the actual flow: scan, print, hand over. Not a smoke test — the whole path, with the badge coming out of the printer.
A deliberate failure. Pull the uplink. Confirm registration continues, the queue builds locally, and it reconciles when you plug it back in. If nobody has ever seen this happen, nobody knows what it looks like.
The audio path, with the room empty and then with people in it if you can. An empty hall sounds nothing like a full one, and radio behaves differently with eight hundred phones in it.
Who needs to be there
The on-site lead, one person per discipline, and — this is the part usually missed — the venue's own technical contact.
Most of the problems found at a dry run are venue problems: a circuit that is not where the drawing says, a network port that is not patched, a rigging point that is not rated. Solving those needs someone with venue authority, and finding them at 21:00 the night before is much easier than finding them at 07:00.
Time it properly
Late enough that the room is yours and the build is substantially complete. Early enough that a problem can still be fixed.
The evening before, after load-in, is the standard slot and it works. A dry run at 06:00 on show morning is a systems check, not a rehearsal — there is no time to act on what it finds.
Write down what you found
Two lists: what you fixed, and what you decided to live with.
The second list is the important one. Every event carries some accepted risk — a circuit you are not confident in, a backup path that is slower than you would like. Writing it down means the person on shift at 08:40 knows what to suspect first when something misbehaves.
When it gets cut
The dry run is cut when load-in overruns, which is exactly when it is most needed, because an overrunning load-in means the build is less tested than usual.
If time is genuinely short, cut scope rather than the rehearsal: test the check-in path and the failure case, and skip the rest. Twenty minutes of the right test beats a full rehearsal that never happened.
Questions we get
Follow-ups
01Is a dry run needed for a small event?
A shorter one, yes. Even at 300 delegates, plugging into the real network and running twenty check-ins finds the venue-specific problems, and those exist regardless of event size. Thirty minutes is enough for a single-hall event.
02What if the venue will not give us access the evening before?
Negotiate it into the contract before signing, because it is much harder to obtain afterwards. If it is genuinely impossible, build the earliest possible show-morning slot into the schedule and accept that some problems will be found with no time to fix them — and price that risk honestly.
03Should the client attend?
For the content rehearsal, yes. For the technical dry run, it is usually better if they do not — the team needs to break things deliberately and talk plainly about what is fragile, and an audience changes that conversation. Send them the findings afterwards.
Talk to the team that runs this on the floor
Send the date, the city and the headcount. We reply with numbers.
Further reading
Was this useful?