Project Management Central

Please login or join to subscribe to this thread

Topics: PMI Standards
Use terms to accurately describe project deliverables
Network:86



I recently submitted the following content to the Practice Standard for Work Breakdown Structures review committee:

Proposed Changes

I believe it is time for PMI to replace the term Work Breakdown Structure with a term that is more reflective of what it currently represents. It is also an opportunity to relabel the Work Package and the WBS Dictionary.

Underlying Concept

It seems that work breakdown structure was conceived by the US Defence Department/NASA to get an understanding of all the component parts of large scale engineering constructions. Much of the underlying concepts assume that much of the project work is undertaken by sub-contractors. The management of these large scale projects also saw the introduction and use of C/SCSC, later renamed Earned Value Management.

The term Work Breakdown Structure is derived from the concept that the work is broken down to the lowest level that can be contracted out to a third party. This lowest level is called a work package. Up to PMBOK Edition 5 it was stated that the work package was the lowest level for cost and schedule estimates.

It is quite probable that the majority of projects using the WBS no longer involve big heavy engineering constructions with much of the work being done by contractors. Instead many of the products, services or results are produced by a wide variety of organisations with the work often being undertaken internally by the sponsoring organisation.

Industry Confusion

The term WBS has different meanings and the use causes widespread confusion as to what is required.

Due to the prominence of MS Project in the project world a large portion of project managers, even PMP qualified practitioners and senior university lecturers, tend to consider the term Work Breakdown Structure as including the activities associated with the deliverables. The use of the term ‘Work’ is often synonymous with the effort involved.

Tom Mochal, President of Ten Step, who was awarded the PMI 2005 Distinguished Contribution Award, suggests that “there are two types of WBS – an activity-based WBS and a deliverable-based WBS. In the PMBOK Guide, they use a deliverable-based WBS, and then define the activities in the process called Define Activities. In the MPMM/TenStep model, we use an activity-based WBS, which has deliverables and activities on the WBS”.

In a number of other project management frameworks the use of the word work is not included in the wording e.g. PRINCE2 and APM Product Breakdown Structure is the term used.

APICS

APICS (American Production and Inventory Control Society) has had a very robust framework for managing the setup, supply, execution and reporting of the manufacturing life cycle using interactive software modules under the heading of MRPII (Manufacturing Resource Planning) – later expanded to ERP (Enterprise Resource Planning).

APICS differentiates between process and discrete manufacturing. Process being continuous and discrete relates to a one-off item. Discrete manufacturing therefore could be described as projectised manufacturing.

I am perplexed that PMI has not looked to APICS to adopt many of the principles contained in its various Process Frameworks.

Of specific interest in this discussion is the term Bill of Materials used by APICS to describe the product breakdown structure.

"A listing of all the subassemblies, intermediates, parts, and raw materials that go into a parent assembly showing the quantity of each required to make an assembly. It is used in conjunction with the master production schedule to determine the items for which purchase requisitions and production orders must be released. A variety of display formats exist for bills of material, including the single-level bill of material, indented bill of material, modular (planning) bill of material, transient bill of material, matrix bill of material, and costed bill of material."

Bill of Deliverables

The APICS Bill of Material, which is globally recognised and understood, is similar in many respects to the WBS. However it could be argued that there may be some elements that are different, such as the restrictive nature of the type of item being produced and the lack of project management components. However it is the similarities that are important.

I suggest that PMI should be looking to APICS to help with an alternative label to use for the WBS. One such might be Bill of Deliverables. Such a label would recognise the need to capture the project deliverable breakdown but would also eliminate the confusion arising from the use of the word ‘work’.

Work Package and WBS Dictionary

It is difficult to grasp how a label such as WBS Dictionary came to be used in project management.

The content of the PMI WBS Dictionary could be equated to that of a shop floor package in manufacturing.

The shop floor package contains the instructions for the foreman to undertake a defined piece of work. To enable this set of instructions to be built up, it is necessary to know the quantity to be produced, the activities to be undertaken, the resources to be used etc. In projects the detailed information for the Team Leader to undertake the work could be included in the package.

Why not call this a Work Package? Can’t do that, because this term is already being used to denote the lowest level of the WBS for which cost and duration can be estimated and managed.

Although it is feasible to estimate at any stage and at any level of a project, PMBOK processes would suggest that the lowest at which estimating is done with any degree of accuracy is at the activity level.

Instead of having the two separate terms, Planning Package and Work Package, use the term Planning Component to denote the level of the WBS for which cost and duration can be estimated and managed.

It is time for PMI to align the labelling of the current terms WBS, the Work Package and the WBS Dictionary with labels that reflect their use and avoids confusion among project managers and other project stakeholders.
Sort By:
Network:53



Interesting idea, but here is my input as a SME and big user of the WBS on many scales. While that might be a practical PMI "framework" of how to better utilize a WBS from a practical perspective, if you start doing away with the term WBS, you will diverge from other well established bodies of knowledge. Project management by no means owns that term WBS outright and anyone with outside knowledge would be confused by what the new terms are that nobody else uses.

The terms actually come from (or have been long shared with) the field of Systems Engineering, which is really a discipline of developing and describing something with a high degree of complexity. If you were to compare the PMBoK with the SEBoK, you would notice a lot of similarity. Both have evolved more over the last several decades as technology grows and managing it becomes more difficult.

Defining a system is more than a product breakdown structure. That's what's known as a physical architecture. There are also functional architectures (what it does) and logical architectures (how it works) required to define it. The work breakdown structure is another view of the system which is how it is broken down into logical work packages based on the architectural decomposition. It defines the organizational taxonomy of whatever the thing is pretty much from then on unless more needs to be added to it, even though much of the work has already been completed.

I like the different perspectives of the WBS though. For those not deep in the product development world, it can be pretty obscure. Having experimented with it quite a bit as an organizational structure, it can definitely be used in more ways than people often think, and in the realm of digital transformation it gains all new dimensions.
...
1 reply by Peter O'Driscoll
Dec 06, 2018 5:51 PM
Peter O'Driscoll
...
Keith,

Thank you for your reasoned response to my topic.

You suggest that by changing the labeling of the term used to describe the ‘..deliverable-oriented hierarchical decomposition of the work to be executed by the project team…’ it will result a divergence from other well established bodies of knowledge.

I am not familiar with the SEBoK but on examining the Glossary of Terms there was no reference to the term Work Breakdown Structure. Instead you suggest ‘physical architecture’ is used, which I believe is very appropriate term. The ‘functional architectures’ (what it does) and ‘logical architectures’ (how it works) – ‘Collect Requirements’ - are determined before the physical architecture.

Other project management bodies e.g. PRINCE2 and the Association for Project Management (APM) go for product breakdown structure.
Network:81



Interesting one. I was just going through PMBOK and had a doubt regarding the need to have separate processes Viz (1) 5.4 create WBS and (2) 6.2 Define activities. To me (I'm a construction professional with more than 20 yrs of exp) and as done for projects using MS PROJECT, there is not much of a need to differentiate between the TWO steps in the PLANNING process group.
Hope my comments goes well with the above discussion
...
2 replies by Keith Novak and Peter O'Driscoll
Dec 06, 2018 10:24 AM
Keith Novak
...
Mohamed,
The distinction becomes important if you expect to do a similar project in the future. The WBS is how the information is organized, like the filing system in a library. The work statement is the information itself, like the books on the shelves. I can often change one without affecting the other.

To use construction as an example, if you are developing a series of hotels, the WBS would likely be very similar from one project to the next and would not have to be recreated each time but it might be modified, such as to add or remove sections for gift shops, swimming pools, etc. that are fairly similar from one project to the next.

After you have created the WBS for the first hotel, the next one becomes much easier. The WBS for hotel 1 becomes the baseline for hotel 2 and you can develop a work statement for each item that is changed. This is valuable from a PM perspective not only because it makes the front-end development more efficient, but it's much easier to catch errors. Having no work statement in your WBS section for potable water would be a red flag that something is missing.

Where I see the WBS becomes more valuable in my experience, is in the ability to leverage prior design for reuse, rather than developing projects from the ground up. By having a reusable organizational structure, I can very quickly determine what I can reuse from prior projects, vs. what I have to design from scratch by seeing where I already have books on the library shelf, and which books need to be updated.
Dec 06, 2018 6:02 PM
Peter O'Driscoll
...
Mohamed,

Because you use MS Project as your tool to (1) 5.4 create WBS and (2) 6.2 Define activities you miss the very important distinction that PMBOK is trying to make in determining what you want to produce first - Scope - before you determine how and when you will produce it.

One of reasons why I would like to see PMI move away from Work Breakdown Structure is to avoid the confusion with Microsoft's use of the term.
Network:53



Dec 06, 2018 1:27 AM
Replying to MOHAMED ANSARI M A
...
Interesting one. I was just going through PMBOK and had a doubt regarding the need to have separate processes Viz (1) 5.4 create WBS and (2) 6.2 Define activities. To me (I'm a construction professional with more than 20 yrs of exp) and as done for projects using MS PROJECT, there is not much of a need to differentiate between the TWO steps in the PLANNING process group.
Hope my comments goes well with the above discussion
Mohamed,
The distinction becomes important if you expect to do a similar project in the future. The WBS is how the information is organized, like the filing system in a library. The work statement is the information itself, like the books on the shelves. I can often change one without affecting the other.

To use construction as an example, if you are developing a series of hotels, the WBS would likely be very similar from one project to the next and would not have to be recreated each time but it might be modified, such as to add or remove sections for gift shops, swimming pools, etc. that are fairly similar from one project to the next.

After you have created the WBS for the first hotel, the next one becomes much easier. The WBS for hotel 1 becomes the baseline for hotel 2 and you can develop a work statement for each item that is changed. This is valuable from a PM perspective not only because it makes the front-end development more efficient, but it's much easier to catch errors. Having no work statement in your WBS section for potable water would be a red flag that something is missing.

Where I see the WBS becomes more valuable in my experience, is in the ability to leverage prior design for reuse, rather than developing projects from the ground up. By having a reusable organizational structure, I can very quickly determine what I can reuse from prior projects, vs. what I have to design from scratch by seeing where I already have books on the library shelf, and which books need to be updated.
Network:86



Dec 06, 2018 12:23 AM
Replying to Keith Novak
...
Interesting idea, but here is my input as a SME and big user of the WBS on many scales. While that might be a practical PMI "framework" of how to better utilize a WBS from a practical perspective, if you start doing away with the term WBS, you will diverge from other well established bodies of knowledge. Project management by no means owns that term WBS outright and anyone with outside knowledge would be confused by what the new terms are that nobody else uses.

The terms actually come from (or have been long shared with) the field of Systems Engineering, which is really a discipline of developing and describing something with a high degree of complexity. If you were to compare the PMBoK with the SEBoK, you would notice a lot of similarity. Both have evolved more over the last several decades as technology grows and managing it becomes more difficult.

Defining a system is more than a product breakdown structure. That's what's known as a physical architecture. There are also functional architectures (what it does) and logical architectures (how it works) required to define it. The work breakdown structure is another view of the system which is how it is broken down into logical work packages based on the architectural decomposition. It defines the organizational taxonomy of whatever the thing is pretty much from then on unless more needs to be added to it, even though much of the work has already been completed.

I like the different perspectives of the WBS though. For those not deep in the product development world, it can be pretty obscure. Having experimented with it quite a bit as an organizational structure, it can definitely be used in more ways than people often think, and in the realm of digital transformation it gains all new dimensions.
Keith,

Thank you for your reasoned response to my topic.

You suggest that by changing the labeling of the term used to describe the ‘..deliverable-oriented hierarchical decomposition of the work to be executed by the project team…’ it will result a divergence from other well established bodies of knowledge.

I am not familiar with the SEBoK but on examining the Glossary of Terms there was no reference to the term Work Breakdown Structure. Instead you suggest ‘physical architecture’ is used, which I believe is very appropriate term. The ‘functional architectures’ (what it does) and ‘logical architectures’ (how it works) – ‘Collect Requirements’ - are determined before the physical architecture.

Other project management bodies e.g. PRINCE2 and the Association for Project Management (APM) go for product breakdown structure.
...
1 reply by Keith Novak
Dec 06, 2018 9:39 PM
Keith Novak
...
I double checked the INCOSE SEBoK as well as the DODAF and they both do include the WBS. I've also benchmarked how they're used in multiple industries to create a few (it's been the focus of my job at times), and it's a quite widely used term.

As for the architectural views, it's not correct to say that the functional and logical architectures come before physical. It's an iterative process. Here's an example both of that, and how the term "work" can remain relevant long after there is a "product breakdown structure".

XYZ Automotive is going to come out with their 2019 model year car. It will be much like the 2018 model but adds traction control. In this case, they already have most of the physical architecture defined and are refining it. In adding the feature there would be an iterative process of defining functions such as "prevent wheel spin", along with the physical components and logical interactions that make that happen.

As they are developing the project plan, they would start with the original WBS, add to it if necessary, and align the work to WBS elements. When developing the SoW, it is much more than defining the physical architecture. The work includes a number of specialty functions such as loads and dynamics, electrical analysis, kinematics, stress analysis etc. that can be required at multiple stages throughout the project so that is really work breakdown, not just product breakdown.

After the work is done, the car itself no longer contains "stress analysis" but the framework still exists and when they want to come out with the 2020 version that includes a hybrid engine, they have a starting point to align the tasks required to the architecture. The re-usability of an intelligently designed WBS is one of the ways it retains value, after completion of the project where it was developed, even though when there are no changes occurring, it just looks like a part numbering system.
Network:86



Dec 06, 2018 1:27 AM
Replying to MOHAMED ANSARI M A
...
Interesting one. I was just going through PMBOK and had a doubt regarding the need to have separate processes Viz (1) 5.4 create WBS and (2) 6.2 Define activities. To me (I'm a construction professional with more than 20 yrs of exp) and as done for projects using MS PROJECT, there is not much of a need to differentiate between the TWO steps in the PLANNING process group.
Hope my comments goes well with the above discussion
Mohamed,

Because you use MS Project as your tool to (1) 5.4 create WBS and (2) 6.2 Define activities you miss the very important distinction that PMBOK is trying to make in determining what you want to produce first - Scope - before you determine how and when you will produce it.

One of reasons why I would like to see PMI move away from Work Breakdown Structure is to avoid the confusion with Microsoft's use of the term.
Network:81



My doubt was about possobility of combining the TWO processes into ONE (coz i didn't see any additional input that come in between the TWO for a particular project). Thank you gentlemen for all your comments and advice
Network:53



Dec 06, 2018 5:51 PM
Replying to Peter O'Driscoll
...
Keith,

Thank you for your reasoned response to my topic.

You suggest that by changing the labeling of the term used to describe the ‘..deliverable-oriented hierarchical decomposition of the work to be executed by the project team…’ it will result a divergence from other well established bodies of knowledge.

I am not familiar with the SEBoK but on examining the Glossary of Terms there was no reference to the term Work Breakdown Structure. Instead you suggest ‘physical architecture’ is used, which I believe is very appropriate term. The ‘functional architectures’ (what it does) and ‘logical architectures’ (how it works) – ‘Collect Requirements’ - are determined before the physical architecture.

Other project management bodies e.g. PRINCE2 and the Association for Project Management (APM) go for product breakdown structure.
I double checked the INCOSE SEBoK as well as the DODAF and they both do include the WBS. I've also benchmarked how they're used in multiple industries to create a few (it's been the focus of my job at times), and it's a quite widely used term.

As for the architectural views, it's not correct to say that the functional and logical architectures come before physical. It's an iterative process. Here's an example both of that, and how the term "work" can remain relevant long after there is a "product breakdown structure".

XYZ Automotive is going to come out with their 2019 model year car. It will be much like the 2018 model but adds traction control. In this case, they already have most of the physical architecture defined and are refining it. In adding the feature there would be an iterative process of defining functions such as "prevent wheel spin", along with the physical components and logical interactions that make that happen.

As they are developing the project plan, they would start with the original WBS, add to it if necessary, and align the work to WBS elements. When developing the SoW, it is much more than defining the physical architecture. The work includes a number of specialty functions such as loads and dynamics, electrical analysis, kinematics, stress analysis etc. that can be required at multiple stages throughout the project so that is really work breakdown, not just product breakdown.

After the work is done, the car itself no longer contains "stress analysis" but the framework still exists and when they want to come out with the 2020 version that includes a hybrid engine, they have a starting point to align the tasks required to the architecture. The re-usability of an intelligently designed WBS is one of the ways it retains value, after completion of the project where it was developed, even though when there are no changes occurring, it just looks like a part numbering system.

Please login or join to reply

Content ID:
ADVERTISEMENTS
ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events