Coordinate Schedules and Shared Resources Across Event Sites

To coordinate an event that runs across several locations, connect the separate site plans through four things: a named lead for every site, one master table of milestones that shows which tasks depend on another site, a ledger that tracks every shared resource from release to arrival, and an agreed process for approving and announcing changes. Each site can still run its own local schedule. The coordinator's job is to manage the points where one site's timing affects another.

This approach fits any amateur tournament or community event where two or more locations share participants, volunteers, equipment or deadlines. Examples include a tournament played across several fields or gyms, or a festival with activity stations in different parks. If your sites share nothing and never hand anything off, you only need separate local plans and a shared contact list.

Inputs to gather before you build the plan

• A list of every location, each with a short site ID such as A, B and C
• A named site lead and a deputy for each location
• Each site's draft local schedule, including setup, play or activity times and teardown
• Every item, vehicle or volunteer group that will be used at more than one site
• Your assumptions about travel time between sites and the setup time needed after each item arrives
• The communication method every lead agrees to use for urgent coordination on the day

Step 1: Give each site a coordination pack

Each location should have its own pack containing the site ID, the lead, the deputy, the local schedule and a contact sheet. The deputy matters because a lead who is refereeing a match, handling an injury or moving equipment cannot always answer a call. Everyone at the site should know who speaks for that location when the lead is unavailable.

Step 2: Build one master milestone table

Site leads own their local schedules. The coordinator owns a single master table that lists the milestones other sites care about. Give every milestone an ID so updates can refer to it unambiguously. The table below is an illustrative example, not a template from any particular event.

Milestone ID	Site	Planned time	Responsible lead	Predecessor	Shared resource	Status
A-03	A	12:00	Site A lead	A-02 (morning session ends)	Display kit	Proposed
B-05	B	12:30	Site B lead	A-03 (display kit released)	Display kit	Conflict
C-02	C	13:00	Site C lead	None	None	Confirmed

The predecessor column shows dependencies. If a milestone's predecessor sits at another site, it cannot be confirmed until that site agrees. The status column should use a small, fixed set of values, such as proposed, confirmed and conflict, so anyone can scan the table and see where problems remain.

Step 3: Separate local milestones from cross-site milestones

Mark each milestone as local or cross-site. A local milestone, such as a field's opening match, can be moved by the site lead without asking anyone, as long as no other site is affected. A cross-site milestone needs confirmation from another location, either because it depends on a resource coming from there or because another site is waiting on it. This split keeps the coordinator focused on the dependencies that can cause a chain of delays, and lets site leads make ordinary adjustments without waiting for approval.

Step 4: Track shared resources in a ledger

For every item or group that moves between sites, record where it is now, who has custody of it, which task releases it, the proposed transfer window, the lead who will receive it and when it is next needed. Keep your travel and turnaround assumptions in a separate column from confirmed arrangements, so nobody mistakes an estimate for a commitment.

Resource	Current site	Custodian	Release task	Transfer window	Receiving lead	Next required use	Travel and setup assumption	Status
Display kit	A	Site A lead	A-03	12:00 to 12:25	Site B lead	B-05 at 12:30	25 min travel, 15 min setup	Unallocated

Follow one simple rule: a resource stays unallocated until its proposed uses no longer overlap and its transfer has been confirmed by both the releasing and receiving leads.

Step 5: Check transfer timing with a simple calculation

For each transfer, add the travel time and setup time to the release time. The result is the earliest moment the resource is ready at the receiving site. If that is later than the receiving site's planned start, the plan has a conflict.

Ready time = release time + transfer time + setup time

Hypothetical example: Site A proposes releasing a display kit at 12:00. The draft assumes 25 minutes to move it and 15 minutes to set it up, so the kit would be ready at Site B at 12:40. Site B has an activity scheduled for 12:30 that needs the kit, so the draft does not work. Before confirming, the coordinator has to change one of three things: the schedule, for example by moving Site B's activity to 12:40 or later or releasing the kit earlier at Site A; the resource allocation, for example by sourcing a second kit for Site B; or the transfer assumptions, for example by having a volunteer stage the kit so that setup takes less time. Change an assumption only if the people doing the work agree it is realistic.

Step 6: Agree on how changes are made

Most multi-site problems start when one site makes a reasonable local change without realizing it affects another site. Agree on the following process with all leads before the event, and use it for every cross-site change.

• 1. The site lead reports the changed task, the revised time and any milestones or resources that depend on it.
• 2. The coordinator checks the master table and resource ledger for effects on other sites.
• 3. The coordinator records the decision, including whether the change was accepted, adjusted or rejected.
• 4. The coordinator issues a numbered update, such as Update 4, so leads can tell whether they are working from the latest version.
• 5. Each affected lead acknowledges the update. The change is not final until those acknowledgments are in.
• 6. For urgent issues on the day, leads contact the named coordinator or their deputy through the agreed method rather than messaging other sites directly.

Step 7: Check the plan for gaps and conflicts

Before you share the final version, run through these checks:

• Every site has a named lead, a deputy and a contact sheet.
• Every cross-site milestone lists its predecessor and has been confirmed by the other site.
• No shared resource is booked at two sites during overlapping times, including travel and setup time.
• Every transfer has a release task, a custodian and a receiving lead.
• Every ready time calculated in Step 5 falls at or before the start of the activity that needs the resource.
• All statuses are confirmed. Any remaining proposed or conflict entries have an owner and a deadline for resolution.
• Every lead knows the current update number and the urgent contact method.

Keep organizer choices separate from outside requirements

Time buffers, update numbering and status labels are your own planning decisions, and you can adjust them to suit your event. Venue access hours, permit conditions, league or governing-body rules and local regulations are not your decisions. Confirm those with the venue, the sanctioning organization or the relevant local authority for each site, and enter them in the master table as fixed constraints that other plans must work around.