Work Breakdown Structure Example: Software, Construction, WBS Dictionary

A work breakdown structure (WBS) is a hierarchy of everything your project has to deliver. The final product sits at the top, the major deliverables sit on the second level, and each deliverable breaks down into smaller pieces until you reach work packages your team can estimate and finish. Below you’ll find four work breakdown structure examples: a software project, a WBS dictionary, a construction project, and a real WBS from one of my own projects.

Key takeaways

• Name results with nouns. Every element of a WBS is a tangible result named with nouns and adjectives. Verbs belong in the schedule.
• Put deliverables on level 2 of a software WBS. Phases like Alpha and Beta split every feature across several branches and break the first time a client asks for a change.
• 100% of the work, nothing more. The children add up to their parent. Project management, approvals and sign-offs count as work too.
• The WBS dictionary makes it usable. One row per element, with a description, a Jira epic and a status. Fill it in as you go, not all on day one.

Let’s be honest: the work breakdown structure is a tricky tool. It takes some knowledge, some experience, and a bit of creativity.

But it’s also the tool that decides whether you know what your project includes. Without one, scope arrives one surprise at a time, and you end up managing chaos, not projects. If you want to be a great project manager, you need to build a WBS and use it.

I’ll start with the examples, because that’s what you came for. Then I’ll show you the mistake I see on most software WBSs, and how to build your own, step by step.

Work Breakdown Structure Example for a Software Project

Here’s a WBS for Photo Portal 2.0, a web and mobile app. Click the image to open the full-size version.

The same WBS as an outline:

• 1 Project Management: 1.1 Project Scope Statement, 1.2 Work Breakdown Structure, 1.3 Quality Management Plan, 1.4 Test Strategy (1.4.1 Automation Suite, 1.4.2 User Acceptance Test Suite), 1.5 Draft Project Management Plan, 1.6 Approved Project Management Plan
• 2 Requirements: 2.1 Stakeholder Requirements, 2.2 Requirements Traceability Matrix, 2.3 Software Architecture Document, 2.4 UI Designs (2.4.1 Approved Web Design, 2.4.2 Approved Mobile Design)
• 3 Infrastructure: 3.1 Infrastructure Specification, 3.2 Infrastructure Cost Predictions, 3.3 USA Data Center, 3.4 Europe Data Center
• 4 Back End: 4.1 Media Database, 4.2 Client Management System, 4.3 Authentication Provider, 4.4 Image Optimizer
• 5 Web Application: 5.1 Home Page, 5.2 Login Page, 5.3 User’s Library, 5.4 Admin Portal
• 6 Mobile App: not decomposed yet
• 7 Integration: 7.1 Web App Beta Version, 7.2 Mobile App Beta Version, 7.3 Release Approvals, 7.4 Regression Testing, 7.5 Release Candidate

Each red number on the diagram marks a decision behind it.

1. The product sits at the top

The top of a WBS is always the final product, service, or result. It’s the vision of the full project scope. When you build every deliverable below it and put them together, you get Photo Portal 2.0.

2. Major deliverables sit on the second level

Level 2 holds the major deliverables, numbered 1 to 7. You could put project phases here instead (Initiation, Requirements, Design, Development, Testing). On a software project, I don’t. I’ll explain why in a separate section below, because it’s the mistake I see most often.

3. The Integration deliverable

Back End, Infrastructure and Mobile App look like normal deliverables. Integration, on the far right, is different. It holds the work of turning separate pieces into something you can hand to a client: a Beta build with the must-have features and no critical defects, regression testing, release approvals.

Project Management works the same way. Plans and approvals are deliverables too. Put them in the WBS, or that work disappears from your estimates.

4. Nouns, not verbs

There are no verbs in the titles. Only nouns and adjectives. Every element describes a tangible result. “Approved Web Design” is a result you can check. “Design the website” is an activity, and activities belong in your schedule.

I left a few titles weaker than others on purpose. See if you can spot them.

5. Uneven decomposition is normal

Some deliverables go down three levels. Some stop at two. Mobile App (number 6) isn’t decomposed at all.

On real projects, that’s standard. Few clients can afford to define every requirement upfront. Maybe you don’t have the details yet, or the expertise to break it down. The deliverable still stays in the WBS as a placeholder, estimated at a high level, with its assumptions and risks. You decompose it into work packages when the time comes.

6. The 100% rule

You can’t see this one on the picture, but you need to build it in: the children add up to 100% of their parent. That applies to work, cost and duration. When you deliver all the children, you get the parent with no extra work. When you finish all seven deliverables, you get the product. Here, Integration is the last one.

The flip side comes from experience. Writing a Project Management Plan is one piece of work. Getting it approved is another. That’s why 1.5 and 1.6 are separate elements, and the same goes for many other deliverables.

The hardest part of that 100% is the work nobody mentions at kickoff: security reviews, release approvals, handover docs. My free AI Prompt Pack has a prompt for exactly that. The Hidden Deliverable Detective takes your industry, project type, size and handoff requirements, then lists the governance, compliance, transition and technical deliverables you haven’t planned for yet, with a rough effort estimate for each. That work lands in your estimates now instead of in your overtime later.

Why I Don’t Put Phases on Level 2 of a Software WBS

Alpha, Beta and Release Candidate are stages of software development. They describe the state of the product. Alpha, for example, is the build developers have finished and tested themselves, before QA starts testing. In project terms, it’s an interim deliverable.

So it looks logical to put Alpha, Beta and RC on level 2 and decompose each one. Here’s the catch: the work on every feature then lands in all three branches. Development in Alpha, testing and bug fixing in Beta, final testing in RC. One feature, three places to track it.

Then the change requests come. You deliver Alpha, and the client asks for a new feature. Do you deliver Alpha again? Where does the new feature go?

That’s why I keep life cycle stages out of level 2 and put them under Integration, like 7.1 to 7.5 above. The one exception is a fixed-price contract, where the client pays per phase.

It’s also why you won’t find a work breakdown structure template for software that you can reuse. Without phases at the top, what’s left are deliverables, and those are unique to every project. Use the examples on the internet, mine included, to learn the rules. Don’t copy them.

WBS Dictionary Example

A WBS dictionary is a table that describes each element of the work breakdown structure: what the deliverable is, when it counts as done, and where its details live. The WBS shows the structure. The dictionary explains every box in it.

Part of the dictionary for the Photo Portal WBS above:

WBS index	Title	Description	Jira epic	Status
2	Requirements Documentation	All requirements are fully documented and maintained in the project’s Confluence for the whole project.	NP-3	In Progress
2.2	Requirements Traceability Matrix	The final version is approved by the project sponsor and follows the established template as much as practical.	NP-4	In Progress
2.3	Software Architecture Document	Approved by the CTO. Explains the design principles, may include diagrams, and stays up to date for the product’s lifetime.	NP-4	Done
3	Infrastructure	All required infrastructure. Done once it’s fully implemented in the staging environment and has passed security and performance audits.	NP-37	In Progress

Look at the Infrastructure row. “Done” means staging plus two audits. Without that line, someone will call it done the day the servers are up. One line in the dictionary saves you that argument.

The columns aren’t standardized. Add whatever helps your team produce the deliverable: a Jira epic, links to requirements, an owner, acceptance criteria.

A full dictionary takes a lot of effort, so I use the rolling wave approach. I describe the near-term deliverables in detail and leave short notes on the rest. I fill those in as the scope gets clearer.

Work Breakdown Structure Example for a Construction Project

Full disclosure: I’m an IT project manager. I know very little about construction.

But I understand project management. A few hours of research on common construction phases and life cycles was enough to build this fictional WBS for a new plant.

Level 2 has seven elements: 1 Plant System Design, 2 Construction, 3 Legal and Regulatory, 4 Labor Agreement, 5 Land Acquisition, 6 Testing, and 7 Start Up.

Phases on the top level

Construction project managers often put phases on the top level, so you’ll see phase-based WBSs a lot in this industry. Whether you organize a WBS by deliverables, by phases, or by systems comes from your industry’s practice. There’s no algorithm for that choice.

Different kinds of work

The major deliverables need different expertise. Design is mostly engineering. Construction is construction. Legal and Regulatory, Labor Agreement and Land Acquisition are legal and procurement work. Testing and Start Up need a mix of everything.

Formal acceptance takes effort

Look at 6.2 Acceptance Testing: a plan, the testing itself, and 6.2.3 Formal Sign-off as a separate element. Getting a sign-off can take several rounds of acceptance testing. It’s the 100% rule again.

What’s missing

This WBS isn’t complete. There’s no project management deliverable, for one. If you work in construction, learn the phases, life cycles and major deliverables of your niche. One company usually runs similar projects, so you don’t need to learn the whole industry.

A Real WBS Example From One of My First Projects

The two examples above are clean on purpose. This one is real, from my early days as a project manager. I’m not proud of it. I’m showing it because it worked, and an imperfect WBS beats none.

The project was a small iOS app release. One developer, a hard deadline (the app had to ship in time for the iOS 9 release), and a client name I’ve removed.

What to notice:

• The scope statement and the WBS live in one document. On top: assumptions (one developer, workarounds for Apple’s bugs where possible), constraints (the iOS 9 date, a team member’s fixed vacation), and exclusions (no iOS 9 new features, no UI changes, nothing planned for 3.1). The Project Scope Statement, the WBS and the WBS list came out of one application.
• Every WBS element has a Jira key. The WBS list is a dictionary in all but name: code, Jira ticket, title, notes. Nobody had to keep two lists in sync.
• Level 2 is a life cycle: Feature Complete, Release Candidate, Project Management. That breaks my own rule from above. On a release this small, it worked. On anything bigger, those stages belong under Project Management or Integration.
• Some elements are bugs, not deliverables. “BUG: Application crashes after tap on the Search field” names a problem, not a result. Today I’d group the fixes under one deliverable, like “iOS 9 Compatibility Fixes”.

And it took very little effort. You don’t need everything a textbook prescribes. You need a scope baseline that does its job: the team knows what’s in, the client knows what’s out.

Types of Work Breakdown Structure

People mean two different things by “types of WBS”: how you organize it, and how you show it.

By organization:

• Deliverable-based WBS. Level 2 holds the major deliverables, like the software example. Best for software and most IT projects.
• Phase-based WBS. Level 2 holds the life cycle phases, like the construction example. Best for industries with a stable, repeatable life cycle, or for very small releases.

By representation:

1. WBS chart

The tree diagram. I always have one. It’s the fastest way to show the team and stakeholders what the project includes and where we are.

2. Hierarchical list

The outline you get in every project management tool, and the one you’ll use for planning and tracking.

3. Tabular WBS

Levels as columns. Handy in a spreadsheet or a document for a client.

Key WBS Concepts

• Product scope vs project scope. Product scope is the features and functions of the result. Project scope is all the work needed to deliver it: the product plus research, quality assurance, team management, handover and so on. The top of your WBS represents the project scope.
• Deliverable. A tangible result you need to finish the project: a piece of the product stakeholders can try, or a document like the Project Management Plan.
• Decomposition. Breaking the scope into smaller, manageable pieces: deliverables, then work packages, then activities. A WBS always has at least two levels. Large projects can have a WBS per phase, and programs and portfolios follow the same rules.
• Work package. The lowest level of each branch. It’s still a tangible, verifiable result, and it’s what you break into schedule activities. My two rules: no more than 80 hours of work, and small enough to finish within one reporting period. Then you report finished work packages instead of “70% done”.
• WBS code. The number in front of each element (1, 1.4, 1.4.2). It shows the element’s place in the hierarchy, and you’ll use it to link time, cost and tickets to the WBS.

How to Create a Work Breakdown Structure

This is the process I’ve used with my teams through 15 years of IT projects.

1. Collect the deliverables you already know

Read the Project Charter and the scope statement, review emails and meeting notes, and check plans from similar past projects. Your goal is to collect every deliverable stakeholders mentioned during initiation.

2. Brainstorm with the team

Bring in the right team members and any subject matter experts you can get. A PM who ran a similar project helps too. The goal is the first two levels: major deliverables, plus the interim and internal ones people forget.

We put everything on a whiteboard. I don’t type anything into software during this meeting, because it slows the ideas down. At the end, I take a photo.

3. Structure the deliverables

Sometimes in a separate meeting, sometimes with team leads only, we finalize level 2. We give each element its final name, decide which are the major deliverables, and group the rest under them. Now it goes into the software.

4. Assign one owner per deliverable

Each deliverable gets one responsible person, usually a team member. A RACI matrix built on deliverables works well here.

5. Let team leads decompose deliverables into work packages

Team leads work with their people on the next levels. I stay out of the details. I facilitate, keep the experts focused, and stop debates that go in circles, because there will be some.

Don’t expect your team to know WBS rules as well as you do. Teach them nouns over verbs and the 100% rule before they start.

6. Review the WBS

Your company’s process may require a formal validation. Even if it doesn’t, review the final draft with the team and a fellow PM.

7. Present it to the customer and get a sign-off

Yes, you need some kind of sign-off. Otherwise the customer can say YOU forgot something. And they will, at the end of the project, as usual.

So build their buy-in through the whole process. They should share responsibility for the scope with you.

In this video, I go deeper into the rules, the WBS dictionary, and how to use a WBS once it’s built:

Work Breakdown Structure Template: Why the File Is the Easy Part

If you came here for a template, I get it. You want something to fill in today.

But you’ve already seen what a template would give you: a tree, a few numbered boxes, a table with an index and a description. You can draw that in any tool in ten minutes.

The hard part is what goes in the boxes. Which deliverables does your project have? Which ones did nobody mention? A template can’t answer that, because every software project’s deliverables are unique. A WBS copied from the internet gives you someone else’s scope.

I learned that the hard way. When I got my PMP, I tried to bring textbook processes to a company that had none. Nobody followed them, and I was back to managing chaos. What worked was just enough process to stay in control, light enough that the team actually follows it. A WBS your team built on a whiteboard does that. A perfect template nobody opens doesn’t.

And today, AI is very good at the hard part, as long as you give it your project’s context. Ask ChatGPT for “a WBS for a mobile app” with no context, and you get a generic tree that fits nobody’s project.

So I put together a free AI Prompt Pack for project managers: 27 copy-paste prompts for real IT project work. Three of them fit a WBS:

• Project Context File Builder. AI pulls what it can from your notes, transcripts and charter, then asks about the gaps: goal, deliverables, scope boundaries, stakeholders, team, timeline, risks, budget. You get one file to attach to every other prompt.
• Hidden Deliverable Detective. It brainstorms at least 10 deliverables in each of six categories (governance, compliance, transition, stakeholder communication, technical foundation, and the ones nobody asks for), prioritizes them, and explains what happens if you skip each one.
• Transcripts to Epics. Give it your project file and the requirements meeting transcripts, and it lists the epics for each deliverable, flagging the gaps you need to clarify with the client. That’s your bridge from WBS to Jira.

Get the free AI Prompt Pack and run the Hidden Deliverable Detective before your next WBS session. You’ll walk in with the deliverables that usually show up in month three, and you won’t hear “Wait, who’s doing the security audit?” a week before release.

How Project Managers Use a WBS

A WBS you build and put on a shelf is wasted time. As part of the scope baseline, it feeds cost estimates, the schedule, risk identification and everything after. I use it in six ways.

• Integration. Every activity relates to one work package, and every logged hour goes against a WBS element. Decide upfront what you’ll track and how you’ll query it. A spreadsheet works. So does your PM tool.
• Activity definition. Break each work package into activities and keep the link to the parent. The activities add up to the work package, so your estimates add up too.
• Communication. Keep the names stakeholders used in the Project Charter on level 2, and use the same names in the scope statement and the WBS. Then “we finished 4.3 Authentication Provider” means something to everyone. Technical names can live on the lower levels.
• Resource planning. The WBS shows which skills each work package needs. That’s when you spot the shared or rare specialists you have to book early, and build your RACI matrix.
• Risk responses. Risk responses are work, and the WBS holds 100% of the work. Add response activities to the right work packages, or risk management slips through.
• Scope control. When a new activity shows up and you can’t link it to a work package, that’s scope creep. When an activity takes longer than planned, that’s an estimation problem. When stakeholders reject a deliverable, it’s either a defect or a change request, and a change request means a WBS update.

Work Breakdown Structure Software

Don’t buy a tool just for the WBS. Every decent project management application shows a hierarchical list, and the WBS should live in the same place as your schedule and tracking.

• Mac: Merlin Project
• Windows: MS Project
• Web: Wrike

If your team lives in Jira, you don’t need another tool. Keep the WBS chart and dictionary in Confluence or a spreadsheet, and give each element a Jira epic, like in the dictionary example above.

Work Breakdown Structure FAQ

What does a work breakdown structure look like?

Usually like an org chart: the final product in a box at the top, the major deliverables in a row below it, and smaller deliverables and work packages hanging under each one. Every element has a WBS code such as 2.4.1. The same structure can also be shown as an indented list or a table.

Which project diagram shows the scope broken down into phases, deliverables and work packages?

The work breakdown structure. It decomposes the total scope level by level, from the product to phases or major deliverables, and down to work packages. A Gantt chart shows when the work happens; the WBS shows what the work is.

What is a WBS dictionary?

A WBS dictionary is a document that describes every element of the work breakdown structure. Each row has the WBS code, the title, a description of the deliverable and its definition of done, plus whatever helps the team: an owner, a Jira epic, requirements, a status. Together with the WBS and the scope statement, it forms the scope baseline.

What is the difference between a WBS and a WBS dictionary?

The WBS shows the structure: which deliverables exist and how they break down. The WBS dictionary explains each element: what it is, when it’s done, and who owns it. You need the WBS first; the dictionary grows with it.

What is a WBS in software engineering?

It’s the same tool applied to a software project: the product at the top, then deliverables such as requirements, infrastructure, back end, front end, mobile app and integration. In agile teams, the work packages often map to epics in Jira. I recommend organizing it by deliverables rather than by Alpha, Beta and RC phases.

What is a work package in a WBS?

A work package is the lowest element of each WBS branch. It’s still a tangible result, small enough to estimate, assign and track. I keep work packages under 80 hours of work and within one reporting period.

What is the difference between a product breakdown structure and a WBS?

A product breakdown structure breaks down only the product: its components and features. A WBS breaks down all the project work, which also includes project management, requirements, testing, approvals and handover. In the software example above, deliverables 4 to 6 are close to a product breakdown; deliverables 1, 2 and 7 are what the WBS adds.

Conclusion

A good work breakdown structure lists everything your project has to deliver, built with the team, named in the client’s words, and used every day to plan, report and say no to scope creep.

Start with the deliverables, not the phases. Keep the 100% rule. Add the dictionary as you go. Get it right, and your project runs on a system, not on overtime. That’s how you stop managing chaos and start managing projects.

Next, see how to decompose a project into tasks and how to write a scope management plan. You’ll find the rest of my articles on this topic on the Scope Management page.

Before your next WBS session, grab the free AI Prompt Pack and run the Hidden Deliverable Detective on your project first, so the deliverables nobody mentioned reach your WBS before they reach your schedule.