CIVIL_SYSTEMS
Foundations

How to Build a Work Breakdown Structure

Reviewed September 2026 · Civil Systems LLC

A useful breakdown gets people estimating the same job.

Start with what you are delivering

“Prepare the drainage report” looks tidy on a task list. It is harder to estimate when one person means the calculations, another includes the figures, and a third expects a checked report ready to submit.

A work breakdown structure (WBS) divides the agreed project scope into smaller pieces, organized around deliverables. It helps the team see what belongs in the job and where the boundaries are. PMI describes this deliverable-oriented approach in its discussion of the WBS practice standard.

Start by naming the finished result and what makes it acceptable. For a drainage report, that might mean a checked report with supporting calculations and figures, ready for the agreed submission. Agency approval would be a different commitment; include it only if it belongs to the agreed scope.

Break the result into manageable pieces

Under the finished report, list the pieces needed to produce it. Then split any piece that is still too broad to estimate or assign clearly. The lowest level you choose to manage is a work package.

One report might have packages for the input record, analysis, figures, and checked submission. Another project may need a separate package for each drainage area. Use the structure that helps the people doing the work explain their estimates and recognize completion.

Interactive element · planned

Open up the deliverable.

A simplified breakdown for one drainage report, within a larger project.

Submission-ready drainage report
  • Input recordSource data and documented assumptions
  • AnalysisCalculations and recorded results
  • FiguresMaps, diagrams, and supporting exhibits
  • Checked submissionAssembled report, resolved comments, and issue record

Planned interaction: break a deliverable into work packages, then describe what “done” means for each. This is a static example; the packages are not clickable.

Write down the boundary of each package

A short description beside each package can prevent a long discussion later. A WBS dictionary is simply the accompanying detail that explains what each package covers.

For the figures package, a useful entry could read: “Prepare the catchment map and outfall figure from the agreed analysis. Include labels, legends, and figure revisions from the technical review. Complete when the reviewer confirms the figures match the final calculations.”

Assign an owner and record important inputs, assumptions, and exclusions. In this example, the figures package owns figure corrections; the checked-submission package owns coordinating the review and confirming comments are closed. Counting the same correction effort in both would inflate the estimate. Counting it in neither would leave a gap.

Check for missing work before adding detail

Read the breakdown against the agreed scope with the people who will deliver it. Does it include coordination, checking, correction, submission, and closeout where required? Are there two packages claiming the same work? Is something included that was never agreed?

The complete project WBS should cover the whole agreed job. The report diagram above is only one branch: a larger assignment may also include surveys, design drawings, project management, and other deliverables.

Stop splitting when a package is clear enough to assign, estimate, and track. A box for every email adds upkeep without necessarily improving the plan. If a package could spend several reporting periods “almost done,” it may need a clearer completion test or a smaller boundary.

Then build the activities and schedule

The breakdown tells you what the work includes. To schedule it, identify the activities needed to complete each package and the order they depend on.

For the figures package, those activities might be preparing the base map, adding analysis results, checking the figures, and resolving comments. Estimate the effort with the people doing them. Then account for availability and dependencies to establish duration: eight hours of work can occupy a week.

A WBS does not show that sequence by itself. Keep the connection between packages and activities visible so a changed deliverable can be traced into the estimate and schedule.

Use it when the request changes

If the client asks for an additional alternative in the report, find the affected packages. It may require more analysis, revised figures, and another review. The extra work becomes easier to explain when each affected piece has a defined boundary.

Before your next estimate, pick one deliverable and write its completion condition. Break it down with the person who will do the work, then ask who owns checking and corrections. That small conversation often exposes the difference between the task someone priced and the result everyone expects. For the next conversation with the client, see scope and change.

Keep exploring.

More practical notes on the decisions, constraints, and people behind project delivery.