Work breakdown and scheduling
Event schedule baseline: freeze the plan so you can track slippage
The schedule keeps changing, and nobody can say how far the plan has moved from what the committee first approved.
Opens WhatsApp with a draft you can edit before sending. Nothing is sent automatically.
The short answer
A schedule baseline is a saved copy of the approved dates. Once it exists, the live schedule can change, and the gap between the two shows how much has slipped and where.
A baseline is replaced only by a deliberate decision, with a reason, an approver and a date. Otherwise it becomes just another version of the schedule.
What goes into the baseline
- The milestone dates and task dates the committee approved.
- The durations and dependencies that produced them, including the critical path.
- The assumptions behind them, such as supplier lead times or approval meeting dates.
- The version number, the date it was saved and who approved it.
How to set it
- Finish the schedule, including the critical path and any buffers.
- Ask the decision owner to approve it, and record their name and the date.
- Save a copy that cannot be edited and call it Baseline 1.
- Keep working on a separate live copy and compare it with the baseline at every milestone review.
Reading variance
For each milestone, record the baseline date, the current forecast and the difference in working days. A positive number means it is late.
Look at what changed rather than only how much. A slip on the critical path moves the end date; a slip on a task with float may not.
When to reset the baseline
- The date, scope or format has changed by a formal decision.
- A major supplier or venue has changed.
- The slippage is so large that comparing against the old dates no longer helps decisions.
- The committee has asked for a fresh start. Keep the old baselines so the history can be seen.
Pitfalls
- Overwriting the baseline each time dates change, so slippage is never visible.
- Changing the baseline quietly to make the status look green.
- Setting the baseline before the schedule has been reviewed by the people who will do the work.
- Not recording why a baseline was reset. Use the decision log.
Worked example · Fictional example
Four weeks after approval
Fictional organisation and figures. Dates and durations are hypothetical.
A fictional trade association approved a 58-working-day plan as Baseline 1. Four weeks later the venue contract is forecast six working days late, because a committee meeting moved.
The venue task is not on the critical path, so the end date stays as it was, and the variance report shows the float reduced from 21 to 15 days. The secretariat flags that more slippage on that chain would start to matter. Later, when the committee changes the programme from one day to two, the secretariat issues Baseline 2 and keeps Baseline 1 on file.
| Milestone | Baseline | Forecast | Variance (working days) | On critical path? | Note |
|---|---|---|---|---|---|
| Venue contract signed | Day 22 | Day 28 | +6 | No | Float reduced from 21 to 15 |
| Speakers confirmed | Day 33 | Day 33 | 0 | Yes | On track |
| Final run sheet | Day 58 | Day 58 | 0 | Yes | No change to the end date |
Use this yourself
Baseline record and variance table
Keep this as the first page of the schedule file. Update the variance table at every milestone review.
- Baseline number, date saved and approver
- Event date and critical path at time of baseline
- Key assumptions (lead times, approval dates)
- Variance per milestone: baseline, forecast, difference
- Reason and approver for any reset
- Where the earlier baselines are stored
| Milestone | Baseline date | Forecast date | Variance | Critical? | Note or reason |
|---|---|---|---|---|---|
Handle it in-house, or bring in help?
Your team can usually handle this when
- One person keeps the schedule and the committee reviews it regularly.
- The plan is small and changes are infrequent.
- The team agrees on what counts as a reset.
Outside planning help earns its fee when
- Several people edit the schedule and dates keep changing without a record.
- The board or funder wants to see variance against the approved plan.
- A reset is being asked for and nobody can say what changed.
Need the baseline kept and reported?
An Event Blueprint saves the approved schedule as the baseline and sets out how variance is reported to your committee. A project lead would run the milestone reviews, record each reset in the decision log and keep the earlier baselines on file.
Questions organisers ask
Is a baseline the same as a final schedule?
No. The baseline is the approved version at a point in time. The live schedule continues to change, and the baseline lets you see how.
How often should I compare to the baseline?
At each milestone review and whenever a major date moves. A rolling look-ahead deals with the near term in between.
Can I reset the baseline after one small delay?
Usually not. Small variances are what the baseline is there to show. Reset only for formal changes to date, scope or format.
Where do I store the history?
Keep each baseline as a dated, read-only file, and link it from the decision log entry that approved it.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.