I am currently busy with an assignment for a course and wondered what the community thought of creating a WBS based on the 4 PMBOK processes as its 2nd level in the WBS ( namely Planning, Execution, M&C, and Closing) with Level 1 consisting of the name of the project. Based on each of the processes it would be made up of either project management deliverables or within the execution mostly the actual work that is carried out in a deliverable or work package...I see many WBS without these processes mentioned and wondered what others thought about structuring the WBS along the processes? Or is it best to keep Project Management at the level 2 and break down the project management deliverable based on the level 2 structure as in don't distinguish based on processes but include Project management as a deliverable as part of the level 2 WBS? Saving Changes...
We are revising our corporate WBS template based on our 5 project phases (i.e. Identification, Options Analysis, Definition, Implementation, and Close-out). All second level WBS elements with the project name being the first. Those elements are further sub-divided into 5 WBS Elements which are common across all project phases. These can be further divided as required. Saving Changes...
That depends on whether you are developing a WBS for the whole project, or for the PM team deliverables. A WBS can be defined many ways, but the structure can make it more or less difficult to manage the work and keep it all integrated.
Typically a WBS is predominantly broken down by a decomposition of the product or service being delivered, rather than the project phases. When you break down a product level work statement by phase first, each functional team has their total SOW scattered among several different branches of the tree, making it confusing, and difficult to align to the OBS. I can see it growing several times larger than a product based structure. When it is broken down based on the product or service structure, it's easy to define the phase specific work within the product-centric organization and it's all still a continuous thread of information for the people performing the work.
For the PM team and other administrative groups however, their admin/integration type work is predominantly broken down by project phase, so in those integration team branches which start at Lv. 2 or below, breaking it out by phase is quite convenient.
...
1 reply by Steve Ratkaj
Apr 09, 2019 3:33 PM
Steve Ratkaj
...
Our WBS is based on the whole project including all deliverables (both internal PMO deliverables, and contract/ contractor deliverables. I understand that NASA, DoD use a WBS based predominantly on a "product" WBS with PM elements added. I agree that the structure of the WBS can "make" or "break" how work can be managed. We are actually facing this difficulty as some wish to tie "costs" to WBS elements that really are not "deliverables" or work packages in the truest sense. This is where things can go off the rails in regards to respecting what a WBS is in the first place. Creating a WBS based on phases fits our needs as much of the project work related to the first three of our project phases has a lot to do with creating the necessary approval documents to get to the next phase.
If you take the example of a construction project, do you recommend to then have Project Management Deliverables branched from Level 2 Project Management and for example the actual work performed broken down per deliverable Eg. Level 2 might consist of 1.0 Project Management, 2.0 Site Preparation, 3.0 Structure, 4.0 Roof, 5.0 Interior, 6.0 Exterior as an Example of what could be at Level 2? Then break each of these down into work packages and tasks? My main focus of the question is to not lose sight of the Project management Deliverables that are required within projects Saving Changes...
That depends on whether you are developing a WBS for the whole project, or for the PM team deliverables. A WBS can be defined many ways, but the structure can make it more or less difficult to manage the work and keep it all integrated.
Typically a WBS is predominantly broken down by a decomposition of the product or service being delivered, rather than the project phases. When you break down a product level work statement by phase first, each functional team has their total SOW scattered among several different branches of the tree, making it confusing, and difficult to align to the OBS. I can see it growing several times larger than a product based structure. When it is broken down based on the product or service structure, it's easy to define the phase specific work within the product-centric organization and it's all still a continuous thread of information for the people performing the work.
For the PM team and other administrative groups however, their admin/integration type work is predominantly broken down by project phase, so in those integration team branches which start at Lv. 2 or below, breaking it out by phase is quite convenient.
Our WBS is based on the whole project including all deliverables (both internal PMO deliverables, and contract/ contractor deliverables. I understand that NASA, DoD use a WBS based predominantly on a "product" WBS with PM elements added. I agree that the structure of the WBS can "make" or "break" how work can be managed. We are actually facing this difficulty as some wish to tie "costs" to WBS elements that really are not "deliverables" or work packages in the truest sense. This is where things can go off the rails in regards to respecting what a WBS is in the first place. Creating a WBS based on phases fits our needs as much of the project work related to the first three of our project phases has a lot to do with creating the necessary approval documents to get to the next phase. Saving Changes...
There is no right or wrong answer to structuring of a WBS so long as it meets the expected outcome, namely that of fully defining the scope of the project and providing a basis for estimation, activity definition and monitoring & control.
If deliverable-based decomposition doesn't resonate with the team and other key stakeholders as much as phase/lifecycle-based decomposition does, then go that route.
Melissa, Yes that's how I've seen it done most successfully. We recently revisited the WBS for several major programs to determine best practices for a new one, and still arrived at that functional based structure. Lv 1 is the product, Lv 2 is Structures, Systems, Interiors, Propulsion, and Integration where PM resides.
The PM deliverables fall into 2 man buckets: project level and system level. Those that are owned by the Integration function, like holding major project gate reviews align under the Integration branch. Functions have to support those too however and there is work involved, so within each level of the WBS there is an integration branch such as: 2.0 Structures Integration, 2.1 Structures Frames, 2.2 Structures Floors, etc. The integration always aligns to the X.0 items. Saving Changes...
Steve,
We've encountered the same difficulty trying to align different types of data to the WBS. Unfortunately, as I'm sure you've also found, different types of work tend to favor different WBS organizations and aligning different breakdown structures requires a decoder ring of sorts, which adds cost and complexity.
We still found that organizing based on a classical systems engineering product structure type decomposition works best for our heavily engineering and manufacturing based needs, and the complications appear at the details of how you manage things like cost when trying to integrate the data sources. Sometimes we just run out of numbers where certain branches end up wider than 10 items in our vision.
It would be very interesting to see how yours works, however like ours, I'm sure it's proprietary.
...
1 reply by Steve Ratkaj
Apr 10, 2019 7:56 AM
Steve Ratkaj
...
Keith;
Yes, I can see how a product or a systems engineering based WBS works for your organization which is a heavily manufacturing based company. As Kiron and Nguyen have mentioned, there is no right or wrong, as long as the WBS includes all work related to the project. The other issue we are facing is adapting our ERP system which is SAP based to work with project WBSs' that have traditionally been done in MS Project.
Saving Changes...
Khai Ng.IT PMO | IT Project Manager| TTGROUPHanoi, Viet Nam
A WBS can be product-oritented, process-oriented, or mix. Your choice depends on the position you are standing or the type of project. For example, when starting with an initiative, you should use process-oriented approach to build WBS and then when you understand more about solution or product, you should use product-oriented or mixing approach. As Kiron mentioned "there is no right or wrong answer". As we know that planning is not one time work, it is an iterative work. Additionally, we usually use PMBOK process groups to construct a WBS with deliverables at Level 3 for project management team (project managers) to guide them when working with new projects. Saving Changes...
Steve,
We've encountered the same difficulty trying to align different types of data to the WBS. Unfortunately, as I'm sure you've also found, different types of work tend to favor different WBS organizations and aligning different breakdown structures requires a decoder ring of sorts, which adds cost and complexity.
We still found that organizing based on a classical systems engineering product structure type decomposition works best for our heavily engineering and manufacturing based needs, and the complications appear at the details of how you manage things like cost when trying to integrate the data sources. Sometimes we just run out of numbers where certain branches end up wider than 10 items in our vision.
It would be very interesting to see how yours works, however like ours, I'm sure it's proprietary.
Keith;
Yes, I can see how a product or a systems engineering based WBS works for your organization which is a heavily manufacturing based company. As Kiron and Nguyen have mentioned, there is no right or wrong, as long as the WBS includes all work related to the project. The other issue we are facing is adapting our ERP system which is SAP based to work with project WBSs' that have traditionally been done in MS Project. Saving Changes...
