The document that keeps a project on course
Every project I run rests on one document. I built it myself over the years and I have made it more detailed as the events got more complex. It is not a reporting file and it is not for the client's benefit: it is the thing that stops me losing the thread when twenty emails arrive in a morning and each one asks for something new.
Why one document and not five
Most projects I am brought into have the information, but scattered. Timings in one file, the budget in another, supplier contacts in an email thread, the running order in a deck someone shared three weeks ago.
Nothing is missing. The problem is that no single place tells you where the project stands, so answering a simple question means opening four files and hoping they agree with each other. They usually do not, because each one was last touched at a different moment.
I keep it all in one place instead. Not because I like spreadsheets, but because a project has one state at a time, and if that state lives in four files it does not really exist anywhere.
What it holds
Five things, side by side, so they can be read against each other.
The timings
Every deadline, in the order it falls, built backwards from the event date. Not a wish list: the dates the suppliers and the venue actually gave me.
The overall control of the project
What is closed, what is open, what is waiting on someone else. At any moment I can say where the project stands without asking anyone.
The accounts with the suppliers
Quoted, confirmed, invoiced. Each one against what was agreed, not against memory.
The accounts with the client
The same figures from the other side, so the two never drift apart. This is the part that makes the reconciliation quick instead of painful.
The evolution of the event
What has changed since the brief, and when. Events change constantly, and a plan that only records the original intention becomes fiction by week three.
What it is actually for
The obvious answer is planning. It is not the real one.
The real value shows up in the ordinary days, the ones with no milestone in them. An email arrives asking whether we can add a second shuttle. Another asks to move a session by half an hour. A supplier writes that a delivery slipped by a day.
Each of those, on its own, sounds small and reasonable. Together, over a few weeks, they are what makes a project drift: nobody ever decided to change the plan, and yet the plan is no longer the one you agreed.
Opening one document and seeing what that request touches is what keeps the direction. The shuttle is not just a shuttle: it is a timing, a cost, a supplier confirmation and possibly a venue access. Seeing all four at once takes seconds. Reconstructing them from an inbox takes an afternoon, and usually nobody has the afternoon.
The requirements change. The direction does not have to.
What it changes for an agency
If you work agency side, you already know how to run a project. What you often do not have, on an event in a country you are not in, is one person holding the whole picture on the ground.
The practical difference is in how questions get answered. When a client asks on a Tuesday what happens if they add thirty people, the answer either takes ten minutes or it takes two days of asking around. That gap is not about competence, it is about whether somebody is keeping the project in one piece.
It also changes what you get at the end. A project tracked this way produces a real reconciliation almost by itself, because the numbers were kept aligned all the way through instead of being reassembled afterwards.
Built over time, not downloaded
I did not find this format anywhere. It started simple and got more detailed every time an event taught me that something was missing, which is the only way I know of building a working tool.
It also changes shape depending on what I am running. A single day convention and a programme moving across six cities do not need the same level of detail, and forcing the second one into the first one's structure is how you end up with a document nobody updates.
Most of what got added over the years came from working across one country long enough to notice that it is not uniform. A venue in a historic building and a purpose-built conference centre need different things tracked, because one has limits on rigging, load and access hours and the other does not. A supplier in Puglia and one in Milan quote the same service with different things included as standard. A summer date and an autumn one sit differently against a supply chain that largely stops for a fortnight in August.
None of that is in any template, because none of it is general. It is the accumulated result of running events in the same places repeatedly and writing down what surprised me.
Which is the real test of any project document, and the reason most of them fail: a plan that is not updated is worse than no plan, because people keep trusting it after it has stopped being true.
Running an event in Italy?
Write to me with the type of event, the dates and the numbers you already have. We will work out how I can support you and which service fits your case.
Write to meThe stages this document tracks are in how to organize a corporate event in Italy. The cost side of it is in the corporate event budget. Running the project end to end is the event management service.