Work Breakdown Structure

Abstract

A work breakdown structure (WBS) is basically a plan delineating the lines of responsibility in bringing a project to its completion. A WBS (pronounced "webs") is an organizational tool used by project managers (PMs) and/or departmental supervisors that allows a company's team to outline specifically how a particular project is to get done by breaking down (or de-composing) that project into increasingly more specialized tasks using three critical metrics: time, workforce commitment, and costs.

Overview

A company, whatever its size, is essentially a complex of interrelated and yet independent projects being conducted by small units of the workforce that are under the direction of a PM. Those smaller units, whether they number a few or dozens, are designed to produce a clear result in a given time within a particular budget. The key is the PM position. "Project management is the application of tools and techniques to predefined activities to meet project requirements. Think of project management as a diagnostic toolbox overlaying instructional design tasks—you use these techniques to step back from what you're developing…and monitor your progress from start to finish" (Karumathl, 2016).

In many ways, a WBS seems to be simple common sense. If a marketing company, for example, is hired to create a new advertising campaign for a client; if a construction company is to begin building a new condominium; if a software developer is hired to create a user-friendly app; if a major aviation corporation is contracted to build a series of light aircrafts for non-commercial flying; if a small wedding planning service is hired to direct a large wedding ceremony and reception; really if any company is hired to execute any project, it only makes sense that the company first plan exactly how that project will be executed over time and delivered at cost and on a schedule appropriate to the client's needs and, of course, doable given the company's resources. However, since the era of company resource management theory emerged as a significant element of company strategy in the late 1980s, businesses and services have begun to take a critical look at these early stages of any project. The conventional wisdom at the time was simple: If a project were derailed, it would most likely happen in the later stages when conditions beyond the specific control of the team and its PMs came into play. Projects, it was assumed, failed at the end.

During the 1990s, however, management resource theory began to invest far more time into the first stages of a project; indeed, the conventional wisdom was upended: Projects, whatever their dimensions, were lost at the beginning, when planning and organization needed to be in place to give the team and any personnel directly involved in the project's execution a clear sense of exactly how the project would be achieved. It was a radical concept. Projects failed because PMs failed to isolate and define critical milestone markers, phases to direct completion and to give managers appropriate and timely feedback; projects failed because any sense of direction to the project was top-down, that is, the PMs alone was responsible for on-site decisions, making real communication and the sense of teamwork virtually impossible. Scheduling was most often too optimistic; costs were badly underestimated; and without a plan in place before the project began, the team inevitably spent time, effort, and resources clarifying the direction of the project.

Of course, long before the advent of WBS, management teams sought to outline a particular project. The premise behind generations of such planning, however, was flawed. Project planning focused on verbs, which as it turned out were flabby and imprecise. Build this; set that; find this; unearth that—the idea was to make the project structuring appear proactive, to give the appearance of a dynamic and engaged workforce. The problem, however, is clear. Say a wedding planner sets as stage one: Arrange a ceremony site. "Arrange" is a verb—it raises more questions than it answers, and sets up the wedding planner for inevitable confusion, crossed lines of effort, and frustrations as schedules become less and less manageable.

The premise behind the emerging field of project management argued that a successful project schedule, what came to called a WBS, needed to rely on nouns rather than verbs—that is, on specific outcomes and deliverable tasks—and that each phase or element of a project needed to be broken down (or "de-composed) until that phase was doable within a specific time frame. In other words, the project was to be conceived as a series of deliverable products rather than a sequence of acts. It was radical reconfiguration of network conceptions of how projects can get done.

The WBS quickly became an essential element of project management in virtually any field, a model that was at once accessible and clear. Indeed, the WBS was initially conceived as a visual, literally a picture (e.g., boxes with lines of connection and direction) created on large sheets of poster paper or on a dry erase board. Using this model, a series of stacked project levels or sections resembled nothing so much as a traditional genealogical tree. Presented in this way managers can visually comprehend projects in granular detail (Taylor, 2006).

The WBS was seen as a way to integrate costs and time outlay and workforce commitment into a single comprehensive frame that focused on outcomes. A simple chart that provided a kind of basic architectural plan for what had to be done, not so much the how or the who or even the why, this approach provided managers a way to avoid getting bogged down in long lists of specific tasks. As such it was immediately embraced as a helpful tool for PMs that also enabled them to factor in risks from the beginning of the project and, thereby, enhanced the likelihood that a project would not be derailed by the unforeseen and be completed on time.

Applications

Although a WBS concerns the actual execution of a specific project, the construction of the plan begins before the PM even meets with the workforce assigned to the project. The designated PM meets with the primary stakeholders—most often the client or customer who is financing the project. The PM engages the primary stakeholders in careful conversation to ensure the PM understands the client's vision and the client's expectations. Indeed, one of the cornerstones of effective WBS planning is communication. Unlike older models in which PMs existed in a kind of vacuum and simply handed down expectations for project progress, under the WBS model the PM listens first to the stakeholders and then goes to the team itself and in a session that can extend for hours or days the PM helps bring the team together, soliciting perspectives and ideas about how best to manage the project to its completion. In short, the WBS recognizes that a team is primarily a group of like-minded, if not like-talented people. The project depends on effective management of everyone engaged in carrying it to completion (Adriano, 2017).

Although there is now a full line of software applications that can assist the PM in designing a WBS, the PM may prefer to create the flowchart using basic materials of conventional office management, such as a flipchart, dry erase board, or PowerPoint slides. What is critical is the movement into a visual presentation of the project's schema. Visualization is essential to WBS. The team sees the project's process. Whatever the dimension of the project, the clear and clean lines of the structured organizational chart help keep the team from bogging down in details—indeed, the WBS provides the "big picture" and keeps the team focused on the direction of the project.

Most often the WBS itself is hierarchically presented in three clear levels of complexity. At the top of the flow chart is the primary goal—the house to be built, the ad campaign to be completed, the software app to launch, the wedding to be staged, the factory to be refurbished. At the second level, however, are not actions but rather nouns, called deliverables, that breakdown the goal into constituent elements or components.

If a house, for example, is to be constructed, the deliverables might include the foundation, the walls, the roof, and the utilities, elements that together create the basic house. They are nouns—not verbs. At the next level, the PM further breaks down (or de-composes) the deliverables into what are termed "work packages." These each specify the basic resources needed to complete the deliverables, most often centered on how many workers will be needed, how much time they will need, and how much outlay the company will be responsible to cover.

As this flow chart is being created before the project actually begins, the WBS provides the PM with a metric for evaluating the ongoing success of the project once the process begins, how the team is doing, and whether the end goal can be met. Indeed, it is the responsibility of the PM to ensure that as the project gets underway any adjustments or alterations to the broad vision of the original WBS is amended to the flow chart. Thus, the PM structures a deliberately loose WBS, informed by the input from stakeholders and the team, allowing for unforeseen circumstances and factoring in whatever risks the project might face (Lechler et al., 2012).

At this point the PM has a complete vision of the project's execution—every element of the structured plan, every level, contributes to the projected goal. Termed the 100% Rule, this reassures the PM that once the WBS is in place, nothing pertaining to the execution of the project has been ignored, the entire scope of the project has been covered. At the work package level, the PM can introduce into the flow chart specific tasks, which aids in task assignment and scheduling (GAO Reports, 2009). The rule of the thumb that governs the work package level is called 8–80, that is, the tasks at this sublevel should take no less than eight hours and no more than eighty hours for the team to complete. If the original plan calls for work packages longer than this, the PM typically de-composes the tasks further until the WBS can offer these manageable tasks.

The PM introduces the team to the WBS, walks the team through its organizational logic, and thereby gets the team focused on the primary goal. The WBS becomes a way to create a shared vision, for the team to feel part of the project's success and to feel vested in addressing efficiently any issues that will arise during the project. In the long run, the WBS provides the team with a distinct and measurable competitive advantage (Zechev & Olaru, 2016).

Issues

By focusing on outcomes rather than tasks, by putting the emphasis on what a project is to do rather than fretting over how, a WBS provides a PM with a handy (and flexible) tool for planning a successful project. Because the PM creates the WBS with the cooperation of the team itself, the network runs more efficiently and more effectively and, in turn, creates a sustainable system for recognizing and rewarding talent. In essentially creating a more democratic project workforce, the WBS has overturned the traditional sense of the PM as an imperial director and has reconstituted that critical supervisory role into a more community-driven, team-shaped position.

The WBS system, however, has its critics. At the center of the WBS system is the personality of the PM. The entire system relies on the perceptive vision of the supervisor and, in turn, the ability to translate that vision to the team. That requires a particular kind of energy and a breadth of knowledge and skills, including the ability to manage nuts and bolts as well as people (Anderson, 2010). Critics worry that the more team-driven WBS system can lead to network anarchy, as networks rely on the authority and autonomy of the PM. In addition, critics cite that the WBS can create profound stress, especially if the WBS is perceived as a contract or a promise rather than a tool. If the work packages are not sufficiently de-composed into clearly defined tasks, or if the PM is overly optimistic about the rate at which tasks can be completed, then the WBS system can quickly become a problem unto itself.

The WBS concept is rapidly becoming perceived as mandatory. Stakeholders such as investors and boards of directors, that is, those not directly involved in the project's execution, rely on the visual network of outcomes to ensure a clear and accessible layer of accountability. In addition, the WBS creates a communal feel to a project and allows everyone involved in the process to be part of its strategic planning. The hierarchal framework creates a sense of direction and makes even the most potentially intimidating project appear doable and manageable. By offering the big picture, the WBS helps create a focus on the endpoint of a project and ensures that every component of a project is working toward that end.

Unlike tasks, outcomes provide broad goals that every member of the team can see as vital. And because the WBS is a flexible tool, indeed invites ongoing reassessment as the project moves forward, the WBS minimizes the chance of frustration and/or panic in the team mentality. Indeed, the WBS is itself at its fundamental level a way for PM's to handle factors that could not have been anticipated when the project began (Forkner, 2017). There is only expectation, amendment, and movement forward. Because now project management is a shared vision rather than something brought down by a directing PM, the entire project becomes an opportunity for a team member to bond and cooperate and in turn feel an integral part of the network.

Terms & Concepts

The 8/80 Rule: The time allotment guidelines for a successful WBS that says a work package should take no less than eight hours and no more than 80 hours to complete as a way to guarantee manageability.

The 100% Rule: The task-selection guidelines for a successful WBS; the rule states that, up and down the breakdown, no task is left out that relates to the completion of the project.

Deliverable: The concrete objective that is the goal of a particular level of a WBS.

Hierarchical: The conceptual model that ranks levels of responsibility and/or tasks to create a system of authority and responsibility to help maintain work flow.

Integrate: To combine element that are not necessarily viewed as elements of the same whole.

Primary Level: The actual project/goal toward which the entire WBS is structured.

Project Manager: The supervisor given responsibility to direct a team to the completion of a specific goal/outcome.

Work Package: The level below deliverable in a WBS hierarchy that breaks that goal into time, cost, and workforce requirements and assigns particular responsibilities to the team or part of the team.

Bibliography

Adriano, M. (2017). The impact of team member satisfaction on project management success. Proceedings of the European Conference on Management, Leadership & Governance. Retrieved on November 15, 2017 from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=122433121&site=ehost-live

Anderson, B. (2010). "Project leadership and the art of managing relationships." Talent Development, 64(3), 58–63. Retrieved November 15, 2017 from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=48407697&site=ehost-live

Forkner, C. (2017, July 14). "How project managers provide stability in an unstable business world." Forbes.

Karumathil, A. (2016). Think like a project manager to design your learning solutions. Talent Development, 70(8), 76–77. Retrieved on November 15, 2017 from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=117089504&site=ehost-live

Lechler, T. G., Edington, B. H., & Gao, T. (2012). Challenging classic project management: Turning project uncertainties into business opportunities. Project Management Journal, 43(6), 59–69. Retrieved on November 15, 2017 from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=84306312&site=ehost-live

Taylor, J. (2006). "The work break down structure." In Survival guide for project managers, 79–90. Retrieved November 15, 2017 from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=32754060&site=ehost-live

Zecheru, V., & Olaru, B. (2017). Work breakdown structures in project management. Review of International Comparative Management, 17(1). Retrieved on November 15, 2017 from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=117405988&site=ehost-live

Suggested Reading

Bucktik, L. (2013). Secrets to mastering the work breakdown structure. 2nd ed. Newtown Square, PA: Project Management Institute Press.

Daneshgari, P., & Moore, H. (2016). Bottom-up risk management. PM Network, 30(6), 29–30. Retrieved January 1, 2018 from EBSCO Online Database Education Source. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=115868935&site=ehost-live

Kogon, K. (2015). Project management for the unofficial project manager. Dallas, TX: BenBella.

Practice standards for work breakdown structures. (2013). Newtown Square, PA: Project Management Institute Press.

Rebentisch, E. (2017). Unlock the power. PM Network, 31(9), 24–25. Retrieved January 1, 2018 from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=124886207&site=ehost-live

Stosic, B., Mihic, M., Milutinovic, R., & Isljamovic, S. (2017). Risk identification in product innovation projects: New perspectives and lessons learned. Technology Analysis & Strategic Management, 29(2), 133–148. Retrieved January 1, 2018 from EBSCO Online Database Business Source Ultimate. http://search.ebscohost.com/login.aspx?direct=true&db=bsu&AN=120452716&site=ehost-live