AtlasFree guide
Project schedule and work breakdown structure
A schedule made of five big bars gets rejected. A schedule built from a proper work breakdown structure can be challenged, resourced and tracked.
7 minute read · no sign-up needed
Why schedules get sent back
The most common review comment on a first schedule is that it has no task-level detail. "Build phase — 8 weeks" tells a reviewer nothing: it cannot be resourced, its dependencies are invisible, and nobody can tell in week three whether it is late.
The fix is a work breakdown structure: break the deliverables down until each piece of work has a clear owner, a clear finish, and an estimate you could defend.
What a work breakdown structure is
A WBS decomposes the project into deliverables, then into the work packages needed to produce them. It describes outputs, not activity for its own sake.
- Level 1 — the project.
- Level 2 — major deliverables or phases.
- Level 3 — work packages: a piece of work one owner can finish and hand over.
- Stop when you can estimate the work package and name who does it. Going further produces a to-do list, not a plan.
Turning the breakdown into a schedule
Once you have work packages, sequence them. For each one, record the owner, the duration, and what must finish before it can start.
Then look for the chain of dependent work that determines the end date. That chain is where slippage costs you the project, and it is what you report on.
The detail test before you submit
Before sending a schedule for review, check each line: does it have one owner, a duration you could justify, and at least one named predecessor or a reason it can start independently? If a line fails that test, it is a phase heading, not a task.
Worked example — breakdown of one deliverable
| Level | Item | Owner | Duration | Depends on |
|---|---|---|---|---|
| 2 | Data migration | James Okoro | 6 weeks | Charter approved |
| 3 | Agree field mapping with clinical lead | Rachel Adeyemi | 5 days | Charter approved |
| 3 | Build extract from legacy records | Supplier | 10 days | Field mapping agreed |
| 3 | Run test migration on 2019 records | James Okoro | 5 days | Extract built |
| 3 | Reconcile mismatches and re-test | James Okoro | 8 days | Test migration complete |
| 3 | Clinical sign-off on migrated sample | Rachel Adeyemi | 3 days | Reconciliation complete |
Free project schedule template
One row per work package. Fill the owner and predecessor columns before you fill the dates — the dates fall out of the sequence, not the other way around.
WBS reference
2.3, 2.4 — so a reviewer can follow the breakdown
Deliverable
Which level-2 item this work belongs to
Work package
A piece of work one owner can finish and hand over
Owner
One named person
Duration
In working days, with the basis of the estimate
Predecessor
What must finish first
Start / finish
Derived from the sequence
Milestone
Mark the few lines a sponsor will ask about
Status
Not started, in progress, complete, blocked
Common questions
What is a work breakdown structure?
A breakdown of a project into its deliverables and then into work packages — pieces of work small enough that one owner can finish and hand each one over.
How detailed should a project schedule be?
Detailed enough that every line has one owner, a duration you could justify, and a stated predecessor. If a line cannot meet that test, it is a phase heading rather than a task.
Do I need a WBS before a schedule?
In practice yes. A schedule written without a breakdown tends to be a handful of long bars that cannot be resourced or tracked, which is why reviewers send it back.
Build a schedule that gets through a review
In the Atlas simulation you plan a hospital records rollout, submit your schedule, and a reviewer challenges it the way a real programme office would — including asking for a proper breakdown when the detail is thin.
More free guides