Why do event plans fail before the event even starts?
Event plans rarely fail on event day. They fail weeks before, in preparation, when quotes, bookings and supplier changes pile up faster than anyone records them.
The root cause is that most teams have no way to separate the agreed plan from the moving plan, so the real plan fragments across emails, calls and spreadsheet versions. The fix is structural: freeze the confirmed plan as a baseline, run the changes in a live plan next to it, and log every change with its budget impact.
Every event I have ever worked on had two plans.
The one everybody agreed on. And the one we were actually running.
The agreed plan lived in a document with a date on it. The real plan lived in emails, phone calls, supplier memos, and three versions of an Excel file called FINAL_v7. The gap between the two grew every day, and nobody could say exactly where the truth was at any given moment.
That gap is where events go wrong. In 25 years of major events, including the Lahti 2017 Nordic World Ski Championships as event director, I have seen it in every project, at every scale. This article is about why the gap opens and what closes it.
Where does the gap come from?
Planning ends with a confirmed plan. Then preparation starts: quotes, orders, bookings, confirmations. And preparation is nothing but changes.
A supplier offers a better product than the one you specified. A quantity doubles when the registration numbers come in. A venue moves a build day. Events are a "something's come up" industry, and none of this is a planning failure. It is the normal physics of pre-production.
The failure is what happens next. In most teams, every change means editing the plan by hand, updating the budget by hand, and telling the supplier by hand. Three manual steps per change, dozens of changes per week. Some steps get skipped. The plan, the budget and the supplier drift apart, and each keeps their own version of the truth.
Worse, when the confirmed plan and the changed plan live in the same file, every edit overwrites history. After a few weeks nobody can show what was originally agreed, which makes every budget discussion an argument about memory.
A plan that cannot survive changes is a document, not a plan.
The one-question test
You can diagnose this in any event project with one question: where is the real plan?
If the answer is one sentence, the project is fine. If the answer starts with "well, the master file is here, but the catering changes are in Anna's email, and the venue confirmed the new build day by phone", the gap is already open. The event will still probably happen. It will just cost more than anyone can explain afterwards.
What actually closes the gap?
The fix is structural, and it has three parts.
Freeze the agreed plan. The moment the plan is confirmed, lock it as a baseline that never changes again. This is the reference point every later discussion returns to. Without a frozen baseline, "over budget" and "changed since we agreed" are opinions, not facts.
Run the changes in a live plan. Open an identical copy next to the baseline and let all preparation happen there. Every quote, booking and supplier change lands in the live plan, with the baseline standing behind it. The two-plans problem doesn't disappear; it becomes deliberate. Two plans, one gap, measured daily.
Log every change with its consequences. A change should show its budget impact before it is accepted, and record who made it, when, and why. When the change log is automatic, the question "where is the real plan" has a one-word answer: here.
This only works if the plan itself is structured enough to carry it. A flat task list can't, because a change to one line says nothing about what else it touches. The structure that can is the chain I use in all event planning work:
The event is designed as a journey of storyboards, stages and steps. The resources are held in one bank, sorted by the 4S Framework. The script connects the two: every step gets its resources with quantities, prices and timing. When a change hits one connection, the structure shows exactly what else moves — which step, which supplier, which budget line.
What this means for suppliers
The same structure fixes the supplier side. Instead of emailing plan extracts that are outdated the day after sending, each supplier gets a live view of their slice of the plan: what is needed, where it is used, and when. Not the budget. When the plan changes, their view changes with it.
This removes the most expensive sentence in pre-production: "we were working from the version you sent us."
Where I learned this the hard way
I learned this by failing at it. In 2020 I built an event planning app that planned events well and then died in exactly the gap this article describes. I parked it for five years before rebuilding it around the baseline-and-live-plan structure above. That story, including what the rebuild took, is in building an event planning app: what failed and what finally worked.
The rebuilt app, Bonacube App, is the structure of this article as working software: frozen baseline, live plan, automatic change log, live supplier views. There are three complete demo events open to anyone, no signup.
If you want the wider planning logic this sits inside, from programmes down to single tasks, start with the Program and Project Planning Framework for major events.
