Hope Is Not a Delivery Strategy

Early in my events career, I had a brutal “I didn’t know what I didn’t know,” moment. My client was out on paternity leave — which meant I was running the show and I’d never even heard of a run of show. I knew tech.

It was the last morning of the event when I got a call asking about the post-event survey. It should have gone live the night before but…it hadn't. I hadn't thought to check it — with my previous CMS vendor, that had always just happened automatically.

I walked over to the tech team and asked why the survey wasn't live. They looked at me with complete reasonableness and said: "We don't do that. The client does."

My response was: "Turn on the $&#% survey."

It went live — and what I learned in that moment wasn't just that I needed to check the survey. It was that I had been operating on assumptions, not documented processes.

No checklist
No pre-event verification steps
No documented ownership of who activated what and when

Just two parties with different mental models of how things worked, and nothing to surface that gap before it became urgent.

That's operational readiness. Or rather, that's what happens when it's absent.

What readiness actually is

Operational readiness is the dimension of event delivery that lives between strategy and execution that determines whether your team is actually prepared or just optimistic.

It's built from four interconnected elements:

Clear requirements that establish what's been agreed to and what's out of scope
Documentation that captures decisions, ownership, and current-version locations so that critical knowledge doesn't live only in someone's head
Processes that create shared rhythms for building, reviewing, and testing
pre-event verification that confirms systems are actually live and configured correctly — not assumed to be

That last one is worth taking a moment on. There's a meaningful difference between a system that's been built and a system that's been verified. The survey was built. It was configured. It was ready to go live. Nobody had confirmed it was actually live, because nobody had documented that confirmation as a required step — or established whose step it was.

Requirements, documentation, processes, and testing aren't just administrative overhead, but instead are what prevent last-morning crises. You can't test what isn't documented, and you can't document what was never agreed on. When readiness gaps show up onsite, they almost always trace back to an assumption that was never made explicit somewhere upstream.

What readiness failures actually look like

The post-event survey story is a clean example because nothing broke. The gap was invisible right up until it wasn't. Most readiness failures follow that pattern — not a dramatic system crash, but a simple assumption that nobody questioned until it mattered.

These types of failures can look like:

A run of show that monitors the schedule but has no escalation paths, so when something goes wrong people know what's happening but not what to do about it.
A scope document that describes deliverables in general terms, so when a stakeholder asks for something adjacent three days out there's nothing to point to.
A testing protocol that confirms features work in isolation but never simulates actual show-day conditions.
A change made on the fly by someone trying to help that triggers a refund, an alert, or a cascading failure nobody anticipated.

None of these are sabotage. They're what happens when good people are working in systems that don't support them — systems where the scaffolding was assumed rather than built.

Operational Readiness is the fifth dimension of the ACCORD framework because it's where the upstream work either coheres or doesn't. A clear strategy, well-communicated and collaboratively owned, running on properly governed technology — all of that can still produce a last-morning phone call if the readiness layer isn't there. Preparation is what converts good intentions into reliable execution.

Your team shouldn't have to be the system. Operational readiness means they don't have to be.

‍