2.1WBS: breaking the project down into tasks
The essentials in 30 seconds
- WBS = break down to master: from the project to big blocks down to work packages, fine enough to be estimated, assigned and tracked.
- The foundation of planning: with no WBS, impossible to estimate durations, sequence or budget.
- Reflex: the WBS describes what must be produced (the WHAT), not yet when — 100% rule: all scope, no omission nor addition.
Running mini-case — Bilal breaks his project down before scheduling
Bilal, young project manager in a service SME in Algiers, must redesign the showcase site and set up a client tracking tool in three months, with two developers and a part-time designer. Tempted to date tasks directly, he starts by breaking down: site, tool, training, go-live — then each block into packages one person can own. For the first time, he sees all the work before talking deadlines.
This same case runs through the course, the diagram, the script and the 48h challenge — and continues in 2.2, 2.3, 2.4, 2.5 and 2.6.
1. Break down to master
Faced with complexity, the best weapon is to break down. The WBS (Work Breakdown Structure) decomposes the project into ever-finer pieces: from big blocks down to work packages — tasks small enough to be estimated, assigned and tracked.
Bilal starts from his four big blocks (site, tool, training, go-live) and breaks them down to packages of a few days, each entrusted to one specific person.
2. The foundation of planning
It is the foundation of all planning: impossible to estimate durations, sequence or budget without first identifying the work.
Golden rule: the WBS describes what must be produced (deliverables), not yet when. The 100% rule requires covering the whole scope, with no omission nor addition — no forgotten work, no out-of-scope item slipped in quietly.
🔎 Concrete example — 🔎 Concrete example — The right granularity
Neither too big nor too fine.
Too big a package ("build the site") → impossible to estimate/track.
Too fine a package ("write the page title") → micro-management.
Good package: a few days to two weeks, entrusted to one person.Outcome: a project manageable piece by piece.
Reflex: check 100% scope coverage.
Section vocabulary
- WBS
- Work Breakdown Structure: hierarchical decomposition of the project into deliverables then tasks, down to work packages.
Simple example: Bilal breaks his redesign into site, tool, training, go-live, then into packages.
What it is not: a dated schedule or a budget.
Reflex: facing a project, ask "what are the big blocks, then the packages?"
- Work package
- The smallest WBS element: a task fine enough to be estimated, assigned to someone and tracked.
Simple example: "Integrate the site's 5 pages" entrusted to one developer for a week.
What it is not: "build the site", too big to estimate or track.
Reflex: one package = a few days to two weeks, one owner.
- Decomposition
- Progressively breaking the project into smaller, masterable pieces.
Simple example: Bilal goes from 4 blocks to twenty work packages.
What it is not: listing tasks in bulk with no hierarchical structure.
Reflex: start from deliverables to structure the breakdown.
- Deliverable
- Concrete outcome produced by a WBS branch; breakdown often starts from deliverables.
Simple example: The site put online, the training guide delivered to users.
What it is not: an internal task with no verifiable outcome.
Reflex: each WBS branch must produce something verifiable.
- 100% rule
- The WBS must cover 100% of scope work — no more (nothing out of scope), no less (nothing forgotten).
Simple example: Bilal checks training and go-live are in his WBS.
What it is not: adding out-of-scope ideas or forgetting training.
Reflex: reread the WBS against scope: all in, nothing extra?
In practice — In practice — Building a project's WBS
- Start from the overall project, then identify its major deliverables or phases (the WBS 1st level).
- Break each big block into sub-elements, then into work packages fine enough to be estimated.
- Check the 100% rule: is all scope covered, with nothing added out of scope nor forgotten?
- Make sure each package is small enough to entrust to one person and track (neither too big nor too detailed).
Ready-to-say script — framing the breakdown with the team (1 min)
"Before talking deadlines, let's list all the work: our big blocks, then few-day packages each. Each package gets an owner. We date nothing today — we just check we forget nothing and add nothing out of scope."
Say at the planning kickoff meeting: enforce WHAT before WHEN.
Copy-paste template — WBS checklist
PROJECT: _______________
BIG BLOCKS (deliverables/phases): 1. _______________ 2. _______________ 3. _______________
WORK PACKAGES (a few days to 2 weeks): _______________
OWNER PER PACKAGE: _______________
100% RULE (omission? out-of-scope?): _______________Small business / tight budget
A whiteboard or spreadsheet is enough: one column per big block, one row per package, one name per owner.
Algerian SME
Bilal posts the WBS at the office: everyone sees their package and the whole — the 100% rule is checked together, not alone.
Remote team
Share the WBS in a common document and reread it on video: remotely, writing replaces the office wall.
Small internal project
Even for three weeks of work: ten well-cut packages beat a vague "things to do" list.
✓ Best practices
- Start from deliverables to structure the breakdown.
- Aim for packages of a few days to two weeks, each with an owner.
- Check the 100% rule (no omission, nothing out of scope).
✗ Common pitfalls
- Confusing the WBS (the WHAT) with the schedule (the WHEN).
- Packages too big (unsteerable) or too fine (micro-management).
- Forgetting work or adding out-of-scope items.
Key takeaways
- The WBS breaks the project into ever-finer pieces.
- A work package is small enough to be estimated, assigned and tracked.
- The WBS describes the WHAT (deliverables/tasks), not yet the WHEN.
- 100% rule: cover all scope, with no omission nor addition.
48h Challenge — apply tomorrow
Take one real project and break it into big blocks then work packages (template above). Check the 100% rule with someone else. 20 minutes is enough.
- I can define the WBS and the 100% rule without hesitating.
- I can tell WHAT (WBS) from WHEN (schedule) apart.
- I've broken a real project into packages with owners.
Frequently asked questions
How far should the WBS be broken down?
Down to work packages you can confidently estimate, assign to an owner and track — often a few days to two weeks of work. Neither too big (impossible to steer) nor too detailed (unmanageable micro-management). A package you cannot estimate is still too big; a package you spend your time logging is too fine.
Is the WBS the same as the schedule?
No, and it is a frequent confusion. The WBS lists the work to do (the WHAT), hierarchically and with no notion of time. The schedule (Gantt section) then orders these tasks over time (the WHEN), with durations and dependencies. The WBS comes first: you only plan well what you first identified.
Bilal wants to date each task though the work isn't even listed. Where must he start?