A Festival Run Sheet Works Best as a Sequence of Decisions

A festival run sheet is most useful when it records decisions in the order they need to be made, not merely the order events happen. Start by defining the experience you want people to have; then settle the scope, timing and dependencies that make that experience possible.

Start with the intended experience

Before listing performances, workshops or opening times, describe what a visitor should be able to do and feel. Keep the description practical: perhaps people should be able to arrive without a queue building across a public path, spend time with local makers, and leave knowing where to find the next activity.

This statement is a decision filter, not promotional copy. If a proposed activity needs a resource that would undermine the central experience—such as a loud demonstration beside a quiet listening session—record the conflict before putting either activity into the schedule.

Use language that different teams can act on. “Create a welcoming festival” is difficult to check; “make the entrance easy to recognise and provide a clear point for questions” gives the welcome team, site team and communications lead something specific to consider.

Choose a planning situation

Different festivals need different starting points. Use the situation that best describes yours, rather than copying a run sheet built for a different scale or purpose.

• If the purpose is still vague: pause detailed scheduling. Gather the organisers who can shape the event and agree on the intended visitor experience first. Otherwise, the run sheet may fill with attractive ideas that compete for time, people or space.
• If the purpose is clear but the team is small: keep the programme narrow and make each responsibility explicit. A compact event with named owners for arrival, performer liaison and closing is easier to coordinate than a sprawling plan dependent on everyone noticing what needs doing.
• If several partners are involved: make shared decisions visible before assigning detailed timings. Partners may have their own approval processes, equipment or staffing arrangements; note who must agree to each commitment and when that agreement is needed.
• If the event is returning to a familiar site: use previous notes to identify known constraints, but treat current access, permissions and availability as decisions to confirm. Familiarity can save discussion, but it does not make last year’s assumptions current.
• If the programme includes activities with uncertain duration: schedule them with room for transitions and recovery rather than placing another essential activity immediately behind them. This suits participatory events, where arrivals, questions or clearing materials can take longer than a fixed performance slot.

When the situation is mixed, use the more cautious choice for commitments that affect other people’s work.

Set a realistic scope

Scope is the set of activities and services the festival team is agreeing to deliver. It includes more than what appears on the public programme: arrival arrangements, access information, performer needs, stewarding, breaks, site changes and the work required to close the event all consume attention.

For each proposed activity, ask what it contributes to the intended experience and what it requires from the team. A popular idea may still be a poor fit if it depends on staff, equipment or approvals that are not available. Record the decision to defer or remove it, so it does not quietly return as an unowned task.

Say you are planning a neighbourhood festival whose purpose is to help visitors meet local groups. You are considering a late-afternoon craft session that needs tables, a facilitator and time to clear materials. If those resources are available and the session supports the purpose, include it and assign its dependencies; if not, leave it out rather than squeezing it into the schedule without support.

Scope decisions should also distinguish essentials from options. Mark what must happen for the event to meet its purpose, what can be simplified if capacity tightens, and what should be dropped first. This gives the team a reasoned way to adjust without treating every item as equally fixed.

Map dependencies

A dependency is a decision, resource or action that must be settled before another task can proceed. For example, a workshop timing may depend on a facilitator’s availability; the public description may depend on confirming the session format; and the welcome team may need the final arrival information before briefing participants.

Write dependencies beside the decision they affect, and name the person or group responsible for resolving them. “Confirm access arrangement — site lead to check with venue” is more useful than a general note such as “access to confirm”. Keep the wording short enough to scan, but specific enough to show what remains open.

Separate decisions that are genuinely pending from tasks that can already begin. The communications lead may be able to prepare a draft while a time remains unconfirmed, but should not publish that time until the programme owner has approved it. This keeps useful work moving without disguising uncertainty as a final commitment.

Build the decision order

Arrange the run sheet so each decision has a sensible predecessor. A useful sequence often looks like this:

1. Agree the visitor experience the festival is meant to support.
2. Choose the activities that serve that experience and set the limits of the programme.
3. Check the people, spaces, permissions and materials each chosen activity depends on.
4. Assign owners to unresolved decisions and give each a point by which it must be settled.
5. Set timings around confirmed commitments, transitions and the work needed before and after public activity.
6. Share the current version with the people whose tasks depend on it, and make changes visible.

This is a planning order, not a claim that every item can be completed in a straight line. A venue constraint may force a scope decision to be revisited; record the change and check which later decisions it affects.

Keep the run sheet readable

A run sheet should help people identify the next action, its owner and any condition that could prevent it. Use consistent labels such as “decided”, “pending” and “not proceeding”, and avoid burying unresolved questions in long notes.

Distinguish public timings from internal preparation. Visitors may need to know when doors open, while the team needs to know when the welcome point is staffed and who has checked its materials. Put both in the working document if useful, but label them so one audience does not mistake the other’s information for theirs.

When a decision changes, update the affected entries rather than adding a contradictory note elsewhere. A shared document can help, but a printed copy may still be useful for people working away from screens. Make clear which version is current and who can approve changes.

Questions organisers ask?

Make the next decision clear

Before sharing a festival run sheet, look at each open item and ask whether someone can tell what must happen next. If the answer is no, add an owner, a dependency or a clear decision to defer the item.

A strong festival run sheet is not the fullest possible timetable; it is a record of choices that lets the team act without guessing. Keep the intended experience visible near the top, and the sequence of decisions will help the festival stay coherent as practical details take shape.