Recurring calendars and multi-event programmes
How to analyse failures that keep recurring
Registration queues, late speaker slides, a rushed pack-down: the same problems come back each year, and each year the committee says it will be fixed.
Opens WhatsApp with a draft you can edit before sending. Nothing is sent automatically.
The short answer
Keep one log of problems across editions. For each repeat, ask why it happened at three levels: what happened, the decision or gap behind it, and the system that allowed it. Fix the lowest level you can control and give the fix an owner and a date.
A recurring problem is usually a missing decision or handover, not a one-off mistake. Once causes are clear, event annual improvement roadmap turns them into next year's priorities.
Start with a log that spans editions
- One row per problem per event: what happened, when it was noticed, who was affected and what was done on the day.
- Add the year, so you can see which problems appear in more than one edition.
- Record the source: post-event survey, supplier comment, staff note or committee feedback.
- Mark each as new, repeated or worsened. Repeated problems are the ones to analyse first.
Ask why at three levels
| Level | Question | Example |
|---|---|---|
| What happened | What did people see or experience? | Registration queue reached the corridor for 40 minutes. |
| Decision or gap | What decision, or missing one, led to it? | Only two desks were staffed because arrival times were never forecast. |
| System | What process allowed that decision to be missed? | No one owns the on-site plan until three weeks out, and handover from last year contained no arrival data. |
Steps for the analysis session
- Pick the three problems that repeated most or cost most. Do not try to fix everything.
- For each, gather the people who were there and the documents, such as the run sheet and the supplier brief.
- Work through the three questions and write the cause at the system level.
- Choose a fix that changes the system, such as a checklist step, a decision date or a handover item, rather than relying on someone trying harder.
- Name an owner and a date, then add the fix to the next edition's plan and check it was done before the event.
Traps in failure analysis
- Blaming a person or a supplier instead of looking at what the brief or handover left out.
- Writing fixes that say be more careful or communicate better. A fix should name a step or a document.
- Analysing every issue, so the real repeat gets lost among minor ones.
- Finding the cause but never checking at the next event that the fix was in place.
Worked example · Fictional example
A registration queue seen three years running
Fictional organisation and figures, for illustration only.
Persatuan Fiktif Pengurus Sumber Manusia saw long registration queues at its annual forum for three editions. Each year the secretariat added a desk, but the problem returned.
The log showed the real cause: the on-site plan was written three weeks before the event and nobody had arrival-time data. The fix was a decision date eight weeks out for the registration layout, and a handover item recording actual arrival times from the previous year.
| Year | What happened | Cause found | Fix and owner |
|---|---|---|---|
| Year 1 | Queue, 40 minutes at peak | Too few desks | Add desk. Secretariat |
| Year 2 | Queue again with extra desk | Arrival peak not forecast | Record arrival times. On-site lead |
| Year 3 | Shorter queue, late name-badge printing | No decision date for layout | Layout decided 8 weeks out. Programme owner |
Use this yourself
Recurring failure analysis template
Complete one per repeated problem. Keep the log from earlier editions so that repeats are visible.
- Problem in one sentence, and the editions where it appeared:
- What people saw or experienced, with who was affected:
- What was done on the day, and by whom:
- Decision or gap behind it:
- System that allowed it (process, handover, ownership):
- Evidence checked (run sheet, survey, supplier feedback):
- Fix that changes the system, not just the effort:
- Owner, due date and how we will check it before the next event:
- Result at the next edition (to be completed afterwards):
Handle it in-house, or bring in help?
Your team can usually handle this when
- Repeats are few and the committee agrees on what happened.
- Someone has records from previous editions.
- The fix is a small change to a checklist or a decision date.
Outside planning help earns its fee when
- Issues repeat across editions and nobody holds the history.
- Several committees or suppliers share responsibility and each blames another.
- A neutral person is needed to run the analysis and follow the fixes through.
Want repeats analysed and followed up?
A recurring programme manager can keep the cross-edition log, run the analysis sessions with your team and suppliers, and track each fix to completion before the next event. Programme decisions and any changes to suppliers stay with your committee. The result is a short list of fixes with owners that carries from one edition to the next.
Questions organisers ask
How many editions do I need before calling something recurring?
Two is enough to ask the question. A problem that appears in two editions has probably a system cause rather than bad luck.
Who should lead the analysis?
Someone who was not responsible for the area, so people can speak freely. This can be another committee member or an outside facilitator.
What if the cause is a supplier?
Check first whether your brief, timeline or handover left something out. If the supplier is the cause, bring evidence to the annual supplier review.
How do we know a fix has worked?
Define in advance what will be seen at the next event, for example queue length or the time the badge file is finalised, and check it afterwards.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.