Please login or join to subscribe to this thread
In our case this is a component inside the knowledge management system we have. In the case of WBS, what we have systematized is the WBS dictionary which is something boarder than WBS itself. In the case of PBS, I understood you are talking about Product Breakdown Structure, then it is tied to our BIM system.
This presumes a predictive, waterfall type delivery approach. If you are using a rolling wave approach or a true adaptive approach, only the highest level of both a WBS and PBS might be nailed down early in the life of the project/product release.
Sorry I had to lookup PBS - does it mean that you apply PRINCE methodology? If yes, then PRINCE answers this question.
WBS indicates that you are following somewhat waterfall-ish methodology that is common in project management, so your processes are not implementing any Agile methodologies.
But have you ever looked into Agile process of creating - persona customer journey product roadmap? It is really fascinating process of matching exactly what the customer wants to the end product which equals to business value.
PBS in PMBoK is a technique for product analysis.
In Prince2 there is no WBS, scope structure is provided by the means of the PBS.
In construction you would find a PBS typically in a BIM, or as to PMBoK terminology in the configuration management system. This is also used for scope change control.
As a PBS can be progressivly elaborated, it can be used in predictive and adaptive context.
A WBS contains elements that are not related to the product, e.g. work required for project management, quality assurance, any deliverables that are not part of the product, like a crane used to build a house or a test driver for software.
Some industries (automotive), some packages (SAP) come with standard WBSes, some companies build their own standard, in any case the standard has to be adapted to the specific project. A standard would typically be found on the knowledge management system, more specifically in PMBoK terms the OPA.
A process how to create and maintain a WBS is part of a scope management plan, which also can be standardized.
Appreciate that your reply corrects my answer.
You appear to be looking for the Systems Engineering approach (not systems as in IT but as in the complex interaction of things). The history goes back at least to Henry Ford and became much more formalized in the US Space Program.
The PBS is what SEs (or what PMI calls BAs) call a Physical Architecture. That is a logical breakdown of the product into areas like structure, powerplant, controls, payload, etc. If you were to design a family of rockets for example, that structure would be very repeatable. It is often broken out based on the skill-sets of the designers, and the logical boundaries of what make individual systems performing the same functions (Functional/Logical Architecture in the SE world).
The WBS maps to the PBS. It is how the work is organized. That can also be very regular. If you were to design a whole rocket, you would use most if not all of the WBS. If you designed a new variant that only updated the controls, you would still have a full PBS but only need to populate part of the WBS. Seeing what is *not* populated in the WBS is an indicator if you have everything. "We are updating the payload capacity but didn't touch the structure? Are we sure we have everything?"
Over decades of using defined WBS for programs, one thing that becomes very apparent is the same WBS doesn't work for everyone. The design view is what fits neatly into the drawing system. The build view is how the product goes through production. The support view acknowledges that repairs don't assume the engine is out of the car like it was in the factory when it was assembled. Translating those views can be difficult and expensive, particularly when using all digital systems that need to do it autonomously.
What I have seen on newer programs is that the PBS is still very similar to prior programs. For the WBS, we look for the best alignment to the PBS considering the lifecycle of the program. It might be more costly for Engineering to break their designs up into smaller pieces, but that can translate into far less effort during the build process or post-production support.
thanks for sharing how PBS and WBS relate in systems engineering, interesting.
Please login or join to reply