How to build an event work breakdown structure
The plan is a long task list, and nobody can say whether it covers everything the event needs.
The short answer
A work breakdown structure splits the event into deliverables, then each deliverable into work packages small enough to assign to one owner and check as done. It answers what must exist for the event to work, before you ask who does it and when.
Break down by deliverable, not by month or by person. Dates and dependencies come later.
Start from deliverables
A deliverable is something that exists when finished, such as a confirmed programme, a signed venue contract or a working registration page. A task like Email speakers is activity, not a deliverable.
Start at the top with the event itself, then list six to nine major deliverables, for example programme, speakers, venue and logistics, registration and attendee communications, suppliers, finance and governance, and handover and review.
Go down to work packages
- Split each major deliverable into parts until a part has one owner, a clear finish and a reasonable size.
- Stop splitting when a package could be done and checked by one person or team, within a few weeks at most.
- Write each package as a result: Speaker agreements signed.
- Check completeness with the 100 percent rule: the children together equal the parent, nothing more and nothing less.
- Give every package an owner role and an acceptance condition, meaning how you will know it is done.
Leave work out loudly, not silently
If something is out of scope, such as sponsor sales or on-stage technical production handled by suppliers, write it in a short Not included list. Unwritten exclusions turn into surprises.
Keep unassigned packages visible with Owner: not yet assigned. The work breakdown builder shows these instead of hiding them.
What comes after
- Assign owners with a RACI matrix.
- Add durations and links in a dependency mapper, and see the critical path.
- Set dates backward from the event with the milestone back-planner.
- Check committee capacity in the workload planner.
Common mistakes
- Mixing levels, so Book venue sits beside Printing, with no parent.
- Listing activities instead of deliverables, which hides what finished means.
- Breaking down too far, producing 300 lines nobody maintains.
- Forgetting the work no supplier does: approvals, decision records, handover and post-event review.
Worked example · Fictional example
A fictional two-day forum, top three levels
Fictional organisation. The structure and package counts are illustrative, not a standard for any event.
The fictional Persatuan Fiktif Pengurus Fasiliti plans a two-day forum for about 300 attendees. The committee began with a list of 80 tasks and could not tell what was missing.
Reorganised into eight deliverables, the list showed that attendee communications and post-event review had no owner. Two work packages were added under each and given to the secretariat.
| Level 1 deliverable | Level 2 work package | Owner role | Done when |
|---|---|---|---|
| 1 Programme | 1.1 Theme and session structure agreed | Programme lead | Committee has approved the outline |
| 1 Programme | 1.2 Speaker agreements signed | Programme lead | All confirmed speakers have returned agreements |
| 2 Venue and logistics | 2.1 Venue contract signed | Chair and treasurer | Signed copy filed |
| 3 Registration | 3.1 Registration page live | Secretariat | Test registration completed |
| 4 Attendee communications | 4.1 Confirmation and joining information sent | Secretariat | Message sent and reviewed |
| 5 Finance and governance | 5.1 Budget approved and tracked | Treasurer | Approved by the body that signs it off |
| 6 Review and handover | 6.1 Post-event review held | Chair | Decisions and lessons logged |
Use this yourself
Event work breakdown template
Copy this table. Fill level 1 first, then split down to work packages. Keep unassigned rows visible.
- Event name and date:
- Scope: included / not included:
- Level 1 deliverables (six to nine):
- Level 2 work packages under each (result wording):
- Owner role for each package (or Not yet assigned):
- Acceptance condition for each package:
- 100 percent check: do the children together equal the parent?
- Next step: owners (RACI), durations and links, dates.
| WBS no. | Deliverable or work package | Owner role | Acceptance condition | Notes |
|---|---|---|---|---|
| 1 | (deliverable) | |||
| 1.1 | (work package) | |||
| 1.2 | (work package) | |||
| 2 | (deliverable) |
Handle it in-house, or bring in help?
Your team can usually handle this when
- The event is familiar and you can reuse last year's structure.
- One person can draft it and the committee can review it in an hour.
- The scope is stable.
Outside planning help earns its fee when
- It is a first event, a new format or a larger scale than before.
- Several organisations contribute and each has its own task list.
- You need a documented plan that finance or a board can approve.
Want the breakdown turned into a working plan?
An Event Blueprint can take your scope and produce a documented work breakdown with owner roles, acceptance conditions, timeline and supplier requirements, ready for your committee to approve. Bring what you have, even if it is an unsorted task list.
Questions organisers ask
How detailed should a work breakdown be?
Detailed enough that each work package has one owner and a clear finish. Splitting further usually adds upkeep without value.
Is a work breakdown the same as a schedule?
No. It lists what must exist. A schedule adds durations, order and dates. Do the breakdown first.
Should it include the work done by suppliers?
Include the deliverable you need from them and the packages your team must do to manage them. Their internal tasks are theirs.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.