Risk identification and contingency
Event key-person dependency register
One colleague holds the registration spreadsheet, the venue relationship and the speaker contacts, and they are about to go on leave.
Opens WhatsApp with a draft you can edit before sending. Nothing is sent automatically.
The short answer
A key-person dependency register lists the people whose absence would stop or slow the event, what only they know, hold or can approve, who covers for them and what has been handed over. Build it for the roles that matter, not for everyone on the team.
The purpose is to move knowledge out of one head into a shared place before it is needed. It is not a judgement of the person.
What counts as a key person
A key person is anyone for whom the honest answer to 'what happens if they are unavailable for a week' is 'something stops'. They may be senior or junior. Often it is the coordinator who built the spreadsheet or the volunteer who knows the venue contact.
Dependencies are also about authority: the only person who can approve spend, release a speaker confirmation or sign for a supplier.
Four kinds of dependency to look for
- Knowledge: how the system works, why a decision was made, supplier and venue history.
- Access: files, accounts, platforms, keys or passes held by one person. Record who has access, not the credentials.
- Authority: sign-off or approval held by a single person.
- Relationships: a supplier, speaker or venue contact who deals only with one person.
Build the register
- List the workstreams, such as registration, programme, finance, venue and suppliers, and the person who leads each.
- For each person, write what would stop or slow if they were unavailable for a week.
- Name a backup who has been introduced to the contacts and has shown they can do the task.
- Record the handover items, such as a shared folder, a written procedure and an introduction to key contacts.
- Review the register at fixed dates, and again whenever someone leaves or the scope changes.
A table to start from
| Role | What only they know, hold or approve | Impact if unavailable | Backup | Handover item and date |
|---|---|---|---|---|
| Registration lead | Delegate list, payment reconciliation, platform administrator account | No check-in or reconciliation | Secretariat officer | Shared export and a one-page procedure, by a set date |
| Venue liaison | Floor plan changes, venue contact, site-visit notes | Supplier questions go unanswered | Project lead | Notes and introduction email, by a set date |
| Treasurer | Sole approver of payments and reserve release | Supplier payments and substitutions stall | Deputy treasurer named in writing | Delegated approval, in writing, with a limit |
| Speaker coordinator | Speaker contacts and travel details | Speaker issues cannot be resolved | Programme assistant | Contact sheet shared securely |
Cover the gap without creating a new one
A backup who has never done the task is not a backup. Ask them to carry out one routine task, such as a check-in test, before the event. Where the backup also depends on the same system, note it in the register.
If a key person is also the supplier contact, link the entry to the supplier failure fallback. If their absence affects speakers, check the speaker absence contingency. Use the responsibility matrix builder to find tasks with no named owner, and the run of show to name who calls each cue.
Worked example · Fictional example
A coordinator about to take leave
Fictional organisation and figures, for illustration only.
A fictional education association is organising a two-day conference for about 300 delegates. The programme coordinator holds the speaker contact sheet, the abstract review spreadsheet and the relationship with the hotel's events manager, and will be on leave for ten days in the final month.
The secretariat head builds the register, names a programme assistant as backup, schedules a one-hour handover, moves the spreadsheet and contact sheet to a shared folder with controlled access and arranges an introduction email to the hotel's events manager. The treasurer also records a written delegation of approval up to a stated limit.
Use this yourself
Key-person dependency register
Copy one row per key person or role. Review at fixed dates and whenever someone leaves.
| Person or role | What only they know, hold or approve | Impact if unavailable for a week | Backup named | Handover item | Handover done (date) | Review date |
|---|---|---|---|---|---|---|
Handle it in-house, or bring in help?
Your team can usually handle this when
- A small team in which everyone's role is visible to the others.
- Procedures and files are already in a shared place.
- Backups have been used in earlier events.
Outside planning help earns its fee when
- A single person carries registration, programme and supplier relationships.
- The event spans several departments or committees and nobody has a full view.
- A key person is leaving, or the handover from the last event never happened.
Need dependencies mapped and handed over?
A planning diagnostic can review your workstreams, show where a single person holds knowledge, access or approval, and give you a prioritised action plan with named backups and dates. It supports your team's handover; it does not replace the people who hold the relationships.
Questions organisers ask
Is this the same as a responsibility matrix?
No. A responsibility matrix shows who is responsible and accountable for each task. A dependency register shows what the event loses if a particular person is unavailable, and who covers. Use both.
Do we record passwords in the register?
No. Record who has access and where the credentials are stored under your organisation's rules. Keep the register itself free of secrets.
How many people should be on the register?
Only those whose absence would stop or slow the event. For most professional events this is three to six people.
What if the key person does not want to share their knowledge?
Frame the register as protecting the event and the person, for example during their leave. The committee chair or event owner should ask for the handover and agree the date.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.