fully integrated. In particular, the WBS enables a project team to organize the work into small outcomes that are manageable, making the assignment of responsibility for each of them easy. Because the outcomes are relatively independent, their interfacing with and dependence on other outcomes is reduced to a minimum. Still, they are integratable as you move up the WBS so the team can get a view of the total solution. This extraordi- nary capability of the WBS to help organize the project work is an enabler of what is an even higher value of the well-constructed WBS; it serves as the framework for integra- tion of project planning and control functions. Some call it the single most important element in project management.21
At the heart of the significance of the WBS is its ability to serve as a project planning and control framework, enabling the achievement of the following fundamental project management actions:
■ Assign the responsibility for the project work.
■ Schedule the project work.
■ Estimate the cost or resources to complete the project work.
■ Develop the response to risks associated with the project work, and perform other planning functions such as quality planning.
■ Manage changes to project scope.
■ Control the project work effort to accomplish project goals.
Finally, the WBS provides a strong visual impact. As a practicing project manager recently commented, “the WBS brings order to disorder in a visual way.” At a glance, the WBS turns the disorder of the verbal and obscure scope statements into the order of a clearly structured hierarchy of work.
THE PRODUCT BREAKDOWN STRUCTURE
For those project managers involved in product development, planning activities involve the combination of product-based planning and project-based planning.22 This type of planning is based on the premise that the product solution is developed first, andthenthe project activities, tasks, deliverables, and resources required to create and deliver the product are planned.
The product breakdown structure (PBS) is a critical tool for product-based planning and should be an essential part of any product development project manager’s PM Tool- box. Essentially, the PBS disaggregates a final product into its constituent components.
Like the project WBS, the PBS is a visual aid that represents the relationship between a product and its components. However, the project WBS and the PBS are used for dif- ferent purposes. The main difference between the two is that the PBS focuses on the product, whereas the WBS focuses on the work required to create the product.
Constructing a Product Breakdown Structure
When creating a PBS, it is common to utilize the knowledge of the team that will be designing and developing the product. This usually involves a group of cross-functional
product specialists. A structured brainstorming session, complete with a whiteboard, sticky notes, pens, and brainpower, is all you need to construct a PBS.
Start with the End in Mind
It is helpful to begin the PBS construction process by first diagramming the product that will eventually be created and developed. We recommend doing this by diagram- ming thewhole solutionthat fulfills the customer’s expectations.23For example, if we purchase a laptop computer, we wouldn’t consider it acceptable if we received a box of circuit boards, a second box that contained the enclosure, another box containing the peripheral devices such as memory and network adapters, and finally an envelope containing a CD with the computer software applications and operating system. Rather, unless we’re a computer hobbyist or a system integrator, weexpectto receive an inte- grated laptop that we can unpack, plug in, and begin using immediately. The point we’re making is that the whole solution may include not only the core product, but also a num- ber of enabling elements of the product that are needed in order to fulfill the customer’s expectation.
It is helpful to think of the whole solution consisting of two parts: (1) the core compo- nents of a product and (2) the enabling components of a product. The core components are the tangible elements that when integrated, constitute the physical product devel- oped. In systems language, these are the subsystems of the integrated product. The enabling components are the additional elements needed to ensure the product meets customers’ expectations. Both the core and enabling components of a product need to be included in the planning of a project.
Let’s look at an example to illustrate. Imagine that you are in charge of leading the project commissioned to create the next-generation smartphone for a phone manufac- turer. Your whole product solution diagram may look something like the one illustrated in Figure 5.6.
The product solution begins with the core components that consist of the physical elements that make up the phone such as the digital circuitry, the embedded software, the radio device, and the enclosure packaging (keep in mind this is a simplistic view for discussion sake).
The product solution also includes other important elements needed such as a soft- ware application development platform, interface to the wireless communication infras- tructure, manufacturing of the product, quality assurance, and customer support for the users of the product. These are the enabling components of the product that are needed to ensure complete customer and user satisfaction when the phone is delivered.
By diagramming the product and its components you are beginning to structure your project. In effect, you are creating the project architecture, where the termarchi- tecturerefers to the conceptual structure and organization of a system.24The process of creating a PBS now has an excellent starting point.
Choose the PBS Structure
Once you understand the core components of the product you intend to develop, you are ready to construct your PBS. The first step in this process is to select the type of struc- ture you wish to use.
THE PRODUCT BREAKDOWN STRUCTURE 139
Whole Solution Core Components
Circuitry Software
Radio
Enclosure
Manufacturing
Customer Support Infrastructure
Enabling Components App Platform
Quality Power Supply
Figure 5.6: Example Whole Product Solution Diagram
Like the project WBS, multiple structure types are available for the PBS: the hierarchi- cal tree design, the table of contents design, and the mind-map design to name three.
The hierarchical tree and table of contents designs are identical to those described for the project WBS. If you create a diagram of the whole product solution as recommended in the previous section, the mind-map design is a good complementary PBS design to choose. Figure 5.7 illustrates an example of the mind map PBS structure for the cell phone product discussed previously.
Decompose the Product
With the PBS structure decided upon, the next step is to begin decomposing the prod- uct into its components and subcomponents. At the top level (or in the middle of the mind-map structure) is the integrated product that will emerge from the product devel- opment process. In the example used earlier, the cell phone is the top-level product in the PBS.
Next, decompose the top level, or integrated product, into its primary components.
As illustrated in Figure 5.6, you may have a combination of core components and enabling components if you take a whole solution approach. You will want to include both component types in your PBS. Continue decomposing each component into its subcomponents until a logical point of decomposition is reached (Figure 5.7). This is normally the level where the subcomponents can be described as a set of project deliverables.
Validate the PBS
Working your way up from the lowest level of the PBS, validate that the subcomponents at each level will integrate to create the subcomponent or component at the
140
Cell Phone
10.3 Wireless Charger
9 Software 9.1 BIOS
9.2 GUI 9.3 OS
8 Radio 8.1 IC
8.2 Antenna 8.3 ADAC
7 Pwr Supply 7.1 Volt. Reg.
7.2 Transformer 7.3 Rectifier
6 Enclosure 6.1 Casing
6.2 LCD 6.3 Adapters
5 Quality
5.1 Test Planning 5.2 QualityReqt’s 5.3 Line Inspection 4 Customer
Support
4.1 Support Planning 4.2 Hiring 4.3 Procedures 3 Manufacturing
3.1 Assembly 3.2 Test 3.3 Process Dev.
2 Infrastructure
2.1 Packet Core 2.2 Regulations 2.3 Gateways 1.3 Database
Figure 5.7: Mind-Map PBS Design Example
THE PRODUCT BREAKDOWN STRUCTURE 141
next-highest level. Continue this process until the top-level product is validated. If gaps are discovered during the validation process, go back to the decomposition step to correct for the gap.
Using the PBS
As stated previously, the PBS is primarily used for product development projects where product planning and project planning are often occurring in a concurrent manner. The PBS is used to bring these two planning efforts together by providing a visual repre- sentation of the product and its components, as well as the relationship between the components, in order to facilitate the project planning process.
The PBS is used to describewhatthe project work effort is meant to create. This should be established before full-scale project planning begins, where project planning focuses onhowthe product will be developed. Obviously,whatshould come beforehow.
We found it interesting to witness a recent debate on a professional networking site concerning the value of using a WBS versus a PBS.25We had no idea this was the basis of such a hotly contested philosophical war between factions. Not only did we find the debate interesting, we found it a bit disturbing. As is usually the case in such mental exercises, the key point of interest was lost. The discussion should not have been about the virtues of using one tool versus the other, but rather about how the two tools can be effectively used in tandem.
Since planning on a product development project includes both product-based planning and project-based planning, once a PBS is created that decomposes a product into its components to the level of deliverables, the components can then become the elements contained within the WBS. Decomposition of the work necessary to create each product component can now take place using the WBS. Used in this manner, the PBS and WBS become a set of integrated tools, which demonstrates both the decomposition of the product as well as the decomposition of the work necessary to create the product.
Benefits
Since the planning process on a product development project involves concurrent plan- ning of product and project, the opportunity is great for these two efforts to become disconnected and even in conflict with one another. This of course can be a disastrous situation for the project manager as well as the project sponsor. If used, the PBS is an effective tool that can help to keep this from occurring. It focuses the planning effort on both what will be developed as well as how it will be developed. Especially if used in conjunction with the project WBS.
The PBS is a very visual tool that helps the project manager visualize the various components of the product and project. This visual representation aids in establish- ing structure and order to very complex projects. By engaging the sense of sight in the project structuring process, we are gaining another tool to establish order out of complexity.
An intangible, but important benefit gained from the use of the PBS is an increase in team cohesion. How is this? The PBS is normally created early in the project planning pro- cess, a time when a project team is beginning to form. Since development of the PBS is a collaborative effort between the cross-functional product specialists, much is learned about the various specialties, and a realization that the product development project will only be successful through a collaborative effort normally sets in. Nothing drives team cohesion faster than having to collectively solve problems and create a solution—in this case, the PBS.
References
1. Stroh, P. J.Business Strategy: Plan, Execute, Win!(Hoboken, NJ: John Wiley & Sons, 2014).
2. Alleman, G. B. Performance-Based Project Management: Increasing the Probability of Project Success. New York, NY: AMACOM, 2014).
3. Handifield, R. B. “Effects of Concurrent Engineering on Make-to-Order Products.”
IEEE Transactions on Engineering Management41 (4): 384–393, 2004.
4. Reinertsen, D. G.The Principles of Product Development Flow: Second Generation Lean Product Development(Redondo Beach, CA: Celeritas, 2009).
5. McDounough, E. F. I., and G. Barczak. “Speeding Up New Product Development: The Effects of Leadership Style and Source of Technology.”Journal of Product Innovation Management8 (3): 203–211, 1991.
6. Handfield, R. B., Gary L. Ragatz, Kenneth J. Petersen, and Robert M. Monczka. 2009.
“Involving Suppliers in New Product Development.”California Management Review 42 (1): 59–82.
7. Cleland, D. I.Project Management: Strategic Design and Implementation(New York, NY: McGraw-Hill, 2006).
8. Thompson, A. T., and A. J. Strickland.Crafting and Implementing Strategy, 19th ed.
(New York, NY: McGraw-Hill, 2013).
9. Reinertsen, 2009.
10. Berkun, Scott.Making Things Happen: Mastering Project Management(Sebastopol, CA: O’Reilly Media, 2008).
11. Kahn, K. B.The PDMA Handbook of New Product Development, 3rd ed. (Hoboken, NJ:
John Wiley & Sons, 2012).
12. Cooper, R. G.Winning at New Products: Creating Value Through Innovation, 4th ed.
(New York, NY: Basic Books, 2011).
13. Web site: www.purchasing-procurement center.com. Accessed October 15, 2014.
14. Project Management Institute.A Guide to Program Management Body of Knowledge, 5th ed. (Newtown Square, PA: Project Management Institute, 2014).
15. Ibid.
16. Hammer, M., and J. Champy.Reengineering the Corporation(New York, NY: Harper Business, 2006).
REFERENCES 143 17. Kerzner, H. R.Project Management: A Systems Approach to Planning, Scheduling, and
Controlling(Hoboken: NJ: John Wiley & Sons, 2013).
18. Schneider, A. “Project Management in International Teams: Instruments for Improving Cooperation.” International Journal of Project Management 13 (4):
247–251, 2005.
19. Department of Defense.MIL HDBK-881A; Department of Defense-Work Breakdown Structure(Washington, DC: Department of Defense, 2005).
20. Department of Energy.DOE G 120.1-5, Performance Measurement Systems Guidelines (Washington, DC: Department of Energy, 1996).
21. Kerzner, 2013.
22. TSO.Managing Successful Projects with PRINCE2(London, England: TSO, 2012).
23. Martinelli, Russ, James Waddell, and Tim Rahschulte. Program Management for Improved Business Results, 2nd ed. (Hoboken, NJ: John Wiley & Sons, 2014).
24. Ibid.
25. Website: https://www.linkedin.com/groups/What-is-Work-Breakdown-Structure- 35313.S.5879948537357152257?trk=groups_search_item_list-0-b-ttl&goback=
%2Egmr_35313%2Egna_35313. Viewed on October 8, 2014