Building a Project Plan: Milestones, Work Breakdown Structure, and Task Sequencing
Turning an approved charter into a list of concrete work, in the right order, with checkpoints along the way.
Intermediate
TopNotchNote
Notes that matter
from "approved" to "actionable"
A signed project charter tells you what the project is and why it exists. It does not tell anyone what to actually do on Monday morning. The project plan is the bridge between the two — it breaks the approved scope into concrete pieces of work, puts them in an order that respects what depends on what, and marks the checkpoints that let everyone tell whether the project is on track.
Three tools do most of that work: a Work Breakdown Structure (WBS) to decompose the scope, milestones to mark progress, and task sequencing to order the work.
the work breakdown structure (wbs)
A WBS decomposes the total scope of the project into progressively smaller pieces, until each bottom-level piece — called a work package — is small enough to estimate, assign to one owner, and track to completion. It is a hierarchy of deliverables, not a to-do list of individual actions: "Design onboarding email" is a work package; "Open Figma" is not.
The 100% rule governs how a WBS is built: the work at any level must add up to exactly 100% of the work at the level above it — no more, no less. Skip a piece of scope and it silently falls off the plan; add something the charter didn't authorize and you've quietly grown the project without anyone approving it.
Each work package is usually documented in a short WBS dictionary entry: what "done" looks like, who owns it, and any acceptance criteria — the detail that keeps the WBS itself from needing a paragraph of explanation next to every box.
milestones: checkpoints, not tasks
A milestone is a significant point in the project — a decision made, a phase completed, an approval granted. Unlike a work package, a milestone has zero duration: it doesn't take three days to reach "design approved," it either has or hasn't happened yet.
Good milestones are unambiguous and externally checkable — "backend API complete" is a milestone only once there's a clear definition of what "complete" means (tests passing, deployed to staging, whatever the team agreed). A vague milestone like "make good progress on backend" can never actually be hit.
sequencing: putting tasks in order
Once the work packages exist, they need an order. Most of them depend on something else finishing first, and getting that wrong is one of the most common causes of a schedule quietly falling apart. The precedence diagramming method (PDM) describes four kinds of dependency between two tasks, A and B:
| Dependency | Meaning | Example |
|---|---|---|
| Finish-to-Start (FS) | B can't start until A finishes | Can't test the API until it's built |
| Start-to-Start (SS) | B can't start until A starts | QA test-writing can start once dev work starts |
| Finish-to-Finish (FF) | B can't finish until A finishes | Docs can't be finalized until the feature is finalized |
| Start-to-Finish (SF) | B can't finish until A starts | Rare — e.g. the old system stays up until the new one starts serving traffic |
Finish-to-Start covers the large majority of real-world dependencies; the other three are worth knowing but come up far less often. Sequencing is also where a plan reveals its critical path — covered on its own page — the chain of dependent tasks that determines the earliest the whole project can finish.
a short example
A team building a new push-notification feature for a mobile app breaks the scope into work packages: design the notification content and triggers, build the backend delivery service, implement the iOS client, implement the Android client, and run end-to-end QA. Backend delivery must finish before either client can be tested against it (FS), while the two client builds can happen in parallel once design is approved (SS on the design milestone). QA can't finish until both clients finish (FF). The milestones are simple and checkable: "design approved," "backend deployed to staging," "both clients pass QA," "released to 100% of users."
practical notes
A WBS that's too shallow hides risk — a single "build the feature" box tells you nothing about which piece is actually behind. One that's too deep turns into busywork, tracking tasks so small that updating the plan costs more than doing the work.
Missed dependencies, not missed estimates, are the more common cause of a schedule slipping unexpectedly — a task that looked independent turns out to need something that isn't ready yet. Reviewing the sequencing with the people actually doing the work, not just the PM's assumptions, catches most of these before they become real delays.