Project Management

How do you breakdown your work?

From the Easy in theory, difficult in practice Blog
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Project management lessons from the old ball game

What lessons has my dog taught me?

Applying project management to an election run (part three)

Applying project management to an election run (part two)

Applying project management to an election run (part one)

The PMBOK® Guide, Seventh Edition defines a Work Breakdown Structure (WBS) as a "hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables".

While this definition provides a good understanding of what a WBS is, it doesn't provide guidance on how to organize the structure of a WBS. This is helpful as it provides flexibility for teams to determine what is the most appropriate means of doing so for the context of their project.

Although there is an infinite variety of projects, I've found three approaches used by most teams who develop WBS's:

  • Deliverable-oriented - each of the top-level components of the WBS represents a key deliverable, and the subsequent levels focus on the decomposition of those deliverables to an appropriate level of detail
  • Phase-oriented - each of the top-level components of the WBS represents a phase or stage in the life cycle of the project, and the subsequent levels focus on the decomposition of the outputs of each of those phases or stages
  • Responsibility-oriented - each of the top-level components of the WBS represents a contributing stakeholder to the project's delivery, and the subsequent levels focus on the decomposition of the outputs produced by each of those stakeholders

A deliverable-oriented approach helps to focus the team on everything required to complete each deliverable without worrying at that stage about who does it or when it would be done. This can work well for projects where the full scope of a project can be decomposed early on, but can be challenging when a rolling wave approach is taken unless there is a clear identification of planning packages which need to be elaborated at a later date.

A phase-oriented approach works well with a rolling wave approach as the team only needs to focus on what will be completed in the upcoming phase. However, there is the risk that the team might miss key scope elements for specific deliverables as they won't be focusing on decomposing a single deliverable at a time.

A responsibility-oriented approach works well when there are multiple stakeholders and there is the need to have a clear segregation of responsibility for planning and execution between them. It suffers from the same risk as the phase-oriented approach, but more severe as there is the potential for deliverable sub-components to be assumed by each stakeholder to be the responsibility of another.

I ran a poll in PMI's LinkedIn Project, Program and Portfolio discussion group as well as the community to gauge the distribution of usage of these three approaches. Out of the combined 141 responses, 57% were using a deliverable-oriented breakdown, 28% used a phase-oriented approach and 9% used a responsibility-oriented one. The remaining 6% indicated they used another approach but when I reviewed the comments those participants had submitted, it seemed that they were just using a combination of these methods rather than something entirely new.

While the WBS is commonly-used tool with projects following a predictive life cycle, this doesn't mean that those following an adaptive one can't benefit from it. If we consider a user story map, it is just a WBS constrained to two to four levels and developed in a progressively elaborated manner. With a story map, the structure might be persona-oriented or theme/capability-oriented.

Regardless of how your team chooses to decompose the scope of work on their projects, a WBS or a variant thereof should be considered as a valuable tool in their toolboxes.

Posted on: May 15, 2022 07:00 AM | Permalink

Comments (7)

Please login or join to subscribe to this item
I would enjoy reading your take on each of the WBS decomposition approaches mentioned, Kiron.

Dear Kiron
The topic that you brought to our reflection and debate was very interesting.

Thank you for sharing the topic, for your opinions and for sharing the poll results.

Thank you for sharing this data.

Thanks Stephane - I might do a deeper dive in future articles.

Thanks Luis & Michael!

Thank you for your insights, Kiron.
I would like to learn more about your (deeper) perspective on integrating the WBS into an agile environment, for instance, Work Breakdown Structures and Product Backlogs, Sprint Backlogs.

Thanks Maria! As I mentioned in the article, a user story map is somewhat similar to a WBS and could entirely replace it on a project whose scope is 100% delivered in an agile manner. For hybrid projects, a WBS might be used for the overall project, and then certain planning packages might be elaborated using user story maps if those work streams are being delivered in an agile manner.


Thank you Kiron for sharing your experience.

Please Login/Register to leave a comment.


"The illegal we do immediately. The unconstitutional takes a little longer."

- Henry Kissinger