PMBOK Step by Step, Part 3: What Exactly Are We Building? Scope and the Work Breakdown Structure

Ask five people to describe "the clinic" and you will get five clinics. The physician sees a calm space with two exam rooms and a plant. The practice manager sees a check-in desk that does not make patients stand in line. The landlord sees a tenant who does not drill at 7 a.m. The contractor sees a set of drawings with three things missing. The neighbor across the street sees a parking problem. They are all describing the same project, and nobody is lying. Each one is simply using a different picture of what we are building.

That gap between pictures is where schedules slip and budgets bend. So Part 3 of PMBOK step by step is about the question underneath every plan: what exactly are we building? In Part 1 the owners of the Riverside Family Clinic chose a phased build-out and signed a charter with a budget of $280,000 and an opening nine months after approval. In Part 2 they found fourteen stakeholders, including a dental office across the street that turned out to be a friend. Today we turn those people's wishes into a clear scope and break it into pieces small enough to manage. In the middle, there is a builder that writes a scope statement for any project of yours.

A reminder before we start: the clinic is invented. Riverside Family Clinic is a composite, not a real client, and every number is illustrative. Nothing here is legal, financial or medical advice. Building, licensing and health rules vary by place, so the team would check them directly with the permit office and the state authorities.

Two kinds of scope, and why they get mixed up

The PMBOK Guide separates two ideas that people blur constantly.

• Product scope is the features and functions of the thing you are delivering. For the clinic, it is the space itself: two exam rooms, a procedure room, a reception and waiting area, the equipment and the systems.
• Project scope is the work needed to deliver it: the lease, the design, the permits, the construction, the hiring, the launch. The work to build a clinic is much larger than the clinic itself.

Why the difference matters: most scope arguments are about product scope ("can we have a fourth exam room?"), and most scope failures are about project scope ("nobody remembered the billing enrollment, and the clinic opened but could not get paid"). A good plan covers both, and the second kind is the one that sneaks up on you.

Step 1: collect the requirements

A requirement is a condition or capability that someone needs the result to have. You do not invent requirements at your desk. You collect them from the people in your stakeholder register, which is why Part 2 came first.

Use a few simple methods:

• Interviews. Fifteen minutes each with the people who matter, with a question that sounds almost too simple: "What must be true for you to call this a success?"
• Observation. Watch the work. The practice manager might say, "Check-in takes a minute," and thirty minutes of watching a similar clinic will tell you what actually takes a minute and what takes ten.
• Workshops. A short session with the sponsor, the manager and the medical director with a floor plan and a pile of sticky notes. People argue earlier and cheaper at a table than on a construction site.
• Examples and walk-throughs. Visit a similar clinic, with permission. Every visit produces at least one requirement nobody would have thought of at a desk.

Write each requirement as a short sentence with three attributes: who asked for it (the source), how much it matters (a simple must, should or could) and how you will check it (the test). Here are a few illustrative ones for Riverside.

• Check-in takes less than five minutes for a returning patient. Source: practice manager. Priority: must. Check: time ten trial check-ins before opening.
• The procedure room has a sink and lockable storage. Source: medical director. Priority: must. Check: inspection against the approved drawings and the director's walk-through.
• No noisy work after 6 p.m. on weekdays. Source: landlord. Priority: must. Check: written schedule agreed with the contractor.
• Weekend parking arrangement with the dental office. Source: neighbor (found in Part 2). Priority: should. Check: signed note before opening.

Two cautions. First, requirements pile up, and they conflict. The physician wants it beautiful, the lender wants it cheap and the permit office wants it compliant. Write all of them down, then ask the sponsor to settle the conflicts, and record what was decided. The decision log is made for this. Second, a requirement you cannot check is a wish. If you cannot say how a stranger would tell whether it is met, rewrite it until you can.

Step 2: write the scope statement

With requirements in hand, you write the project scope statement, a short document that describes the project in a way every stakeholder can read in five minutes. It has six parts. The sample lines are the Riverside Phase 1 example, still illustrative.

1. Description. What are we doing, in two or three sentences? Open a primary-care clinic of two exam rooms, one procedure room and a reception in the leased ground-floor suite, ready to see patients nine months after approval.
2. Deliverables. The tangible things the project produces. The signed lease, approved drawings, permits, the finished suite, installed equipment and systems, a trained first team and an opening day.
3. Acceptance criteria. How will the sponsor decide each deliverable is done? The suite is accepted when the final inspection is passed, the punch list is closed, equipment is installed per the layout and the ten trial check-ins meet the five-minute target.
4. Exclusions. What is explicitly not included? The second phase of rooms, additional services, and marketing beyond the launch. This line is worth five times its length.
5. Assumptions. What are we treating as true that might not be? The landlord confirms the key date in writing. The permit office reviews drawings within its normal window. Every assumption is a small risk, so copy them into your risk register, and see project risk management in plain English for how to rank them.
6. Constraints. What limits the project? A $280,000 budget, a nine-month target and the landlord's building hours.

The exclusions are where the future argument lives. If the statement does not say that the second phase is out, somebody will assume it is in, probably around month five, at the same moment the budget gets tight. Writing the out-of-scope list is as important as writing the in-scope list. For the whole conversation about saying yes, no and not yet, read how to stop scope creep, and for how the scope statement connects with the charter, see the project charter guide.

Step 3: break the work down

The scope statement says what is in. The work breakdown structure, or WBS, shows everything it contains. Think of it as taking the whole project and cutting it into smaller and smaller pieces until each piece is something a person can estimate, own and finish.

Four ideas make a WBS useful.

• It is built from deliverables, not activities. Use nouns, not verbs: "Approved drawings," not "Draw things." Deliverables are things you can point at, which makes it easy to tell whether they exist. Activities come later, when you plan the schedule.
• The 100 percent rule. The pieces under any item must add up to all of that item's scope, and nothing more. If the work is not in the WBS, it is not in the project. If it is in the project, it must be in the WBS. This rule is what keeps surprises out.
• It has levels. The project at the top, the major deliverables at the second level, their components below, and at the bottom the work packages: small enough to estimate and assign.
• Work packages have a sensible size. A common rule of thumb says a work package should take somewhere between eight and eighty hours of effort, or about a week or two of someone's time. It varies by project, and some teams prefer "no longer than the reporting period." The point is that you can say whether it is on track from one week to the next.

There are two ways to build one, and both work. Top down: write the project at the top, split it into its major deliverables, split each of those and stop when each piece passes the test below. Bottom up: every person writes every piece of work they can think of on a card, then you group the cards under headings. Top down is faster when you know the territory, and bottom up finds forgotten work. A mix is best. An index card for each piece, and a table big enough to move them around, beats any software in the first hour.

Here is the Riverside WBS at the first three levels, again illustrative.

- 1. Riverside Clinic, Phase 1 - 1.1 Project management: charter, plan, weekly reports, meetings, closeout. - 1.2 Lease and design: signed lease, space plan, construction drawings, equipment layout. - 1.3 Permits and approvals: building permit, health authority review, licensing, signage permit, utility connections. - 1.4 Build-out: demolition and framing, plumbing, electrical and mechanical work, finishes, two exam rooms, the procedure room, reception and waiting area. - 1.5 Equipment and technology: medical equipment, furniture, network and phones, records and billing systems. - 1.6 People and operations: hiring, training, policies and procedures, supplies, vendor accounts, insurer and billing enrollment. - 1.7 Launch: soft opening, opening day and the first thirty days of support.

Look at item 1.6. "Insurer and billing enrollment" is there because Part 2's register reminded the team that insurers decide how soon the clinic gets paid. A team that built the WBS from a blank page, without the stakeholder register, would likely forget it. And look at 1.3, which now has a line for utilities, another stakeholder who rarely makes it onto a schedule. The WBS is where the work of Part 2 starts paying rent.

The test for any piece: can I estimate it, can I give it to one person and will I know when it is done? If the answer to any of the three is no, split it further or define it better. "Build-out" fails the test. "Procedure room plumbing rough-in" passes.

Step 4: the WBS dictionary

A box that says "Procedure room" means one thing to the medical director and another to the contractor. The WBS dictionary is a short entry for each work package, written so that nobody has to guess.

An entry for Riverside's procedure room handover might read:

• Work package: 1.4.5 Procedure room handover.
• Description: Finished room with sink, lockable storage, flooring and lighting as shown on the approved drawings.
• Owner: the general contractor, with the medical director verifying.
• Acceptance: final inspection passed, punch list closed, director's walk-through signed.
• Depends on: plumbing and electrical rough-in approved.
• Estimate: to be added in Part 4.

Short, boring and extremely useful. When a dispute arises in month six about whether "procedure room" included the storage, the dictionary has an answer, and the answer is dated. If you are managing contracts, the same discipline protects you in construction contracts and change disputes: the clearer the definition, the smaller the argument.

Verify, validate and control

Once the work starts, scope has two more jobs, and the PMBOK Guide gives each a name.

• Verify the deliverable: the team checks that it meets the requirements, using the tests you wrote. Did the final inspection pass? Do the ten trial check-ins hit five minutes?
• Validate (accept) the deliverable: the sponsor or customer formally agrees that it is what they wanted. Accepting early and in writing is much cheaper than discovering a mismatch at opening.
• Control scope: manage changes against the baseline. Every change request goes through the same short path: describe it, estimate its effect on schedule, cost and risk, and let the sponsor decide.

Here is how the clinic's first scope test goes. In month four, the physician says, "While the walls are open, could we add a fourth exam room? Patients will love it." A good project manager does not say yes, and does not say no. They say, "Let me find out what it would take." The change request, with illustrative numbers, shows eleven more weeks and $62,000 more, a price nobody had pictured when the idea was floated at the wall. The sponsor, now seeing it on paper, chooses to put it in the Phase 2 list. The room was not rejected, it was scheduled. This is the "not yet" that keeps good ideas alive without eating the budget. Change orders in construction shows how to handle this when the change comes from the owner or the contractor.

Together, the approved scope statement, the WBS and the WBS dictionary form the scope baseline: the agreed yardstick against which every change is measured. It does not freeze the project. It makes change visible.

Common mistakes

• Starting with the schedule. A schedule without a WBS is a list of things somebody remembered.
• WBS items that are verbs. "Order equipment" is an activity. "Equipment delivered and installed" is a deliverable.
• No exclusions. The out-of-scope list is the cheapest insurance in the project.
• Breaking it down too far. A WBS with three hundred lines for a ten-person project is a hobby. Stop when each piece passes the test.
• Breaking it down too little. "Build-out" is not a work package.
• Forgetting the project management and launch work. Meetings, reports, training and opening day take real time, and they belong in the WBS.
• Writing requirements nobody can check. "A welcoming atmosphere" is a wish. "Patients wait less than ten minutes at peak" is a test.
• Treating the scope statement as a one-time document. Review it at each milestone. If scope changes, change the baseline on purpose, with a decision on the log.

How this fits the PMBOK map

In the process view of the PMBOK Guide, scope work belongs to planning: plan scope management, collect requirements, define scope and create the WBS. Validating and controlling scope belong to monitoring and controlling. In the newer principles-and-domains view, scope work lives mostly in the planning and delivery domains, and it is a thread you pick up repeatedly, not a box you tick once. The tools here, the requirements list, the scope statement, the WBS and its dictionary, serve both views. The Guide is a map and not a rulebook, and for a small project, one page of scope and a one-page WBS is plenty. The project management plan guide shows where the scope baseline sits in the whole plan, and the Gantt chart guide shows how the WBS becomes a schedule, which is exactly where Part 4 goes.

The scope statement builder

Use the builder below to write a one-page scope statement for any project. The sample is the clinic's Phase 1. Replace each field with your own project, and read the page on the right. The tool warns you when something that usually starts a dispute is missing: no exclusions, no acceptance criteria, no assumptions or no approver. Copy the result into your plan. Nothing you type leaves your browser.

Interactive tool

The scope statement builder

Loading the tool…

What to do this week

Pick a real project. List ten requirements with their sources by talking to three people, and write a check for each one. Draft the scope statement with the builder above and read it aloud to the sponsor, line by line, especially the exclusions. Then take a stack of index cards and build a WBS top down, one level at a time, until every piece passes the three-question test. Count the cards. The number that surprises you is the gap between what you thought the project was and what it actually is.

Next Wednesday, in Part 4, we ask the two questions every sponsor asks at once: how long and how much? We will estimate the work packages, build the schedule and cost baselines and see how the numbers connect to the critical path. If you want every part at your pace, the publishing calendar shows the dates, and the monthly newsletter lists each month's new parts. If you would like help turning a vague project into a clear scope, that is part of what I do with Project Focus and my project management consulting services, and you can tell me about it on the contact page.

What was the item that nobody wrote down on your last project and everybody assumed was included? Tell me in the comments.

More tools. The project charter template, the RACI chart and the change request log are free in the toolkit. For a real-life example of a project that opened on time, see how a clinic opens on time.

PMBOK and PMP are registered marks of the Project Management Institute, Inc. This series is independent and is not affiliated with, or endorsed by, PMI. The Riverside Family Clinic is an invented example, and all figures and names are illustrative.

Frequently asked questions

What is the difference between product scope and project scope?

Product scope is the features and functions of what you deliver, such as the rooms and equipment of a clinic. Project scope is all the work needed to deliver it, such as the lease, design, permits, construction, hiring and launch. Most arguments are about product scope, and most surprises come from project scope.

What is a work breakdown structure?

A work breakdown structure, or WBS, is a hierarchy that splits the total scope of a project into deliverables and then into small work packages that can be estimated, assigned and verified. It is built from deliverables rather than activities, and its pieces must add up to all of the project's scope and nothing more, a principle known as the 100 percent rule.

How detailed should a WBS be?

Detailed enough that each work package can be estimated, given to one person and clearly finished, and no more. A common rule of thumb is a package of roughly eight to eighty hours of effort, though teams adapt it. If a piece fails the test of being estimable, ownable and verifiable, split it or define it better.

What belongs in the out-of-scope list?

Anything a stakeholder might reasonably assume is included but is not: a second phase, extra services, upgrades, marketing beyond launch or maintenance after handover. Writing exclusions down early prevents most scope arguments, and ideas that are out of scope can be placed on a "not yet" list for a later phase.

Join the conversation

Did this help? A quick reaction tells me what to write next.

Useful Made me smile Go deeper on this

Be the first to react.

Comments

Loading comments…

Leave a comment

Name (optional) What was the item that nobody wrote down on your last project and everybody assumed was included? Post comment

No email and no sign-up. Every comment is reviewed before it appears. Please keep it respectful and leave links out.