The Work Breakdown Structure (WBS) is a structure in project management that hierarchically divides the entire scope of the project into smaller, more manageable parts. The 7th edition of PMI's Project Management Body of Knowledge (PMBOK Guide) defines WBS as “a hierarchical breakdown of the total work scope that the project team will perform to achieve project objectives and create the required deliverables.” This structure defines the total scope of the project by showing its deliverables and work components in a “family tree” format; as you move down from the top, each level contains a more detailed definition of the work component at the level above it. Any work not defined in the WBS is not considered part of the project scope without an official change—in other words, the project consists of the sum of all elements in the WBS, and any element not included in the WBS is not part of the project scope. In this regard, the WBS is prepared in accordance with the principle known as the 100% rule of project scope; all work and deliverables of the project must be represented in the structure. It is a management tool that directly contributes to the time, cost, resource, and risk planning processes of project management.

The WBS primarily focuses on results/outputs. At higher levels, it typically includes main deliverables or major components, while at lower levels, it defines the subcomponents of these deliverables. This deliverable-focused approach ensures the complete definition and control of the project scope. Each item in the WBS typically represents a deliverable or a concrete business outcome and is expressed in noun form; in contrast, activities and actions (expressed in verb form) are not typically listed as part of the WBS. For example, a WBS only lists the tasks to be performed, but does not show the timing sequence or dependencies between these tasks – such sequential relationships are shown in the project diagram (network diagram). Thus, the WBS defines what will be done in the project, not how or when it will be done. In this respect, the WBS is a fundamental tool that clarifies the scope of the project and provides input for other planning processes.

History

The concept of work breakdown structure emerged in the 1960s in large defense and space projects. In particular, the first official definitions regarding the hierarchical structuring of project tasks and deliverables were included in the PERT/Cost System Design Guide published by the U.S. Department of Defense (DoD) and NASA in June 1962. The term “Work Breakdown Structure” began to be widely used in the late 1960s and entered the discipline of project management.

PMI recognized the importance of the WBS concept early on and included it in the first PMBOK guide published in 1987. While the initial definitions focused more on the tasks (activities) to be performed, the concept was redefined in subsequent years to focus on deliverables. For example, in 2004 (PMBOK 3rd Edition), PMI defined WBS as “the hierarchical breakdown of work to be performed by the project team to achieve project objectives and produce the required outputs,” thereby clarifying the emphasis on delivery. This evolution highlighted the need to break down work based on results (products/services) in order to fully and completely define the scope of the project.

PMI published the first edition of the “Work Breakdown Structures” Application Standard in 2001 with the aim of compiling collective knowledge on HRM and disseminating best practices. This was PMI's first specific application standard and provided guidance on “how to do it step by step” when creating a WBS. Based on feedback, the content was enriched, and the second edition of the HRM Application Standard was published in 2006, with examples from different sectors, checklists, and criteria for creating high-quality WBS added. PMI's standard encouraged the consistent use of the HRM concept in project management based on generally accepted practices. Today, PMI Standards and PMBOK Guides continue to treat WBS as an indispensable tool in project management.

Purpose and Scope

The primary purpose of the work breakdown structure is to divide the project into smaller parts to make it manageable. The metaphorical expression, “How do you eat an elephant? One bite at a time,” summarizes the purpose of WBS: A large and complex project can only be effectively managed when its sub-components are defined and addressed separately. The PMBOK Guide defines the WBS primarily as a tool to assist the project manager in managing the project. By creating the WBS, the scope of the project is clarified, out-of-scope elements are identified, and the project manager gains control mechanisms. The WBS serves as a concrete representation of the project's scope definition, fostering a shared understanding among stakeholders and facilitating everyone's comprehension of the project's objectives and deliverables.

The scope of the WBS encompasses all project deliverables and work. The top-level typically represents the project's final deliverable or objective (e.g., “Project Outcome” or the project's name). Below this, the main components and deliverables required to produce the project outcome are listed. All internal and external deliverables should be included in the WBS: for example, internal deliverables such as the project management plan, reports, or supporting documentation are included in the WBS, as well as the final product/service. This ensures that the WBS covers not only the outputs to be presented to the customer but everything produced within the scope of the project. Detailed descriptions for each item in the WBS are typically maintained in a document called the WBS Dictionary. The WBS Dictionary is a document that provides detailed information (definition, scope, responsible person, activity list, cost and duration estimates, etc.) about each component in the WBS and serves as a complementary element to the WBS.

The work breakdown structure is at the heart of project scope management. Once the project scope document has been finalized, the WBS is created, approved, and becomes part of the scope baseline. The scope baseline consists of the approved scope definition, the WBS diagram, and the relevant WBS dictionary, and serves as the basis for comparing actual results during the project execution process. This makes the WBS a critical tool in managing change requests and controlling scope deviations, as any change request must be addressed by adding to or removing from the existing WBS, requiring formal change control.

In summary, the purpose of the WBS is to define the “work” of the project and limit its scope. The project team and stakeholders develop a common understanding of “what will be delivered” through the WBS. Using this structure, the project manager can plan, monitor, and control the project's components separately, making the project as a whole more manageable.

Structure and Application Methods

The WBS is structured in hierarchical levels. Each level represents a smaller part of the item at the level above it. Typically, the top level (Level 0) represents the entire project or the final output; the next level down (Level 1) is divided into the main deliverables that make up the final output; and lower levels are broken down into the subcomponents of these deliverables. A work package typically defines the lowest-level WBS component and represents a small enough unit of work to be planned and managed separately in project management. Work packages form the basis for defining activities and allocating resources in the project schedule, enabling time and cost estimates and monitoring for each work package. In the WBS hierarchy, the contribution of each lower-level element to the total work scope can be tracked through higher levels; the work of higher-level elements is defined as the sum of their lower-level elements (thus, all work can be summarized at higher levels).

There is no single “correct” approach to creating a WBS—different structures can be used depending on the project type and the manager's preferences. PMI standards state that the WBS is a flexible tool and that different breakdown methods can be applied depending on the project's needs. The most common approach is to organize the WBS according to deliverables (deliverable-oriented): In this method, Level-1 is divided into the project's main deliverables or product components; at lower levels, the sub-products that will make up these deliverables are listed. An alternative approach is to organize the WBS according to processes or life cycle phases: In this case, Level 1 includes the main phases of the project life cycle (e.g., Design, Development, Testing, Implementation), and the outputs of each phase are defined at lower levels. In practice, many projects adopt a hybrid approach: For example, Level 1 may include major phases or sub-projects, with concrete deliverables listed below them. This flexibility allows the project manager to divide the project into the most appropriate sections and adapt to applications in different industries. Indeed, in many industries, HR examples of project phases (e.g., “Design,” “Testing”) may be located at the upper levels of the WBS, and these concepts are included in the WBS as part of the accepted practice in that industry.

The HR creation process is typically carried out through top-down planning. Once the project scope and main deliverables are defined, team members and experts are involved in the process to identify the sub-components of these deliverables. Each WBS element has a unique identifier code (number), allowing thousands of sub-elements to be tracked systematically, even in complex projects. Some fundamental principles to consider when developing a WBS are highlighted in the literature: Uniqueness (each sub-item should have only one parent item, with no duplicate tasks), integrity (the scope of a higher-level task should equal the total scope of its sub-components), responsibility assignment (a single responsible person or team should be defined for each WBS item), and mutual exclusivity (there should be no overlapping tasks between items) are some of these rules. Additionally, the WBS structure must be documented; the scope and definition of each level of work must be clearly stated in writing (supported by a WBS dictionary) and shared with project stakeholders. This enables the WBS to serve as a communication tool and ensures that everyone on the project team is working with the same definitions.

The WBS should not be confused with other project documents that have a similar appearance. The work breakdown structure shows the work/deliverables to be performed; in contrast, an organizational chart shows the hierarchy among the people who will perform the work in the project, while a product tree structure (product breakdown structure) or bill of materials (BOM) shows the components of the resulting product. Although the WBS includes the components of the final product, the primary focus is on the work itself: the activities required to produce those components are a separate planning output. This distinction allows steps such as activity definition and network diagram creation to be kept separate after the WBS is created; the project manager first clarifies “what” will be done with the WBS, then addresses “how” it will be done and its sequence in separate documents.

Its Place in Project Management and Related Processes

WBS is a fundamental starting point and unifying element in project management processes. In PMI's approach, within the scope management knowledge area, creating the WBS is a critical step after the project scope is defined; once the WBS is created and approved, the scope baseline is established, and other planning processes are conducted based on this foundation. The outputs of the WBS are directly utilized in areas such as time, cost, resource, and risk management:

• Time (Calendar/Schedule) Planning: The work packages defined in the WBS provide input for creating a detailed time plan. Each work package is addressed, the necessary activities are identified, and relationships between activities are established to create the project schedule. Thanks to the WBS, no important activity is overlooked, as the entire scope is broken down into parts. Additionally, tools such as project network diagrams and Gantt charts are developed based on the work packages in the WBS. The lowest-level elements in the WBS can also be used as key deliverables or control accounts where tasks in the schedule are aggregated.

• Cost and Budget Management: When planning the project budget, separate cost estimates can be made for each component in the WBS. Using the hierarchical codes of the work breakdown structure, the budget is aggregated from the sub-elements upwards, allowing the cost of each subsystem to be tracked. Some organizations wishing to make inter-organizational comparisons have opted to compare cost data using a consistent WBS structure in similar projects. However, since this approach may not be suitable for every project, the more common practice is to use the WBS for internal project control and Earned Value Management. When preparing project performance reports, planned and actual values for each WBS element can be compared, and deviations can be aggregated at higher levels to measure the overall project status. For this purpose, control accounts are typically created at specific WBS levels, and responsible managers track performance through these accounts.

• Resource and Responsibility Assignment: The WBS can be used in conjunction with the organizational breakdown structure (OBS) to create a responsibility assignment matrix (RAM). The RAM is a table that shows which resource or person is responsible for each work package in the project. For example, a commonly used RACI matrix shows the deliverables or work packages in HR in rows and team members in columns, defining who is responsible (Responsible), accountable (Accountable), consulted (Consulted), and informed (Informed). In this way, the WBS forms the basis for the task distribution of the project team and ensures accountability at any work package level. Additionally, when planning resources, the necessary human resources, materials, or equipment requirements can be determined for each WBS component (for this purpose, a hierarchical list called the Resource Breakdown Structure (RBS) can also be prepared in alignment with the WBS).

• Risk Management: The WBS provides a very useful reference in the process of identifying project risks. Each component of the project (work package) is considered separately to discuss what risks may be involved, thus ensuring that no scope elements are overlooked in the risk identification process. In addition, in some projects, a Risk Breakdown Structure (RBS) is created to list risk sources in a hierarchical tree, and the RBS is typically linked to the WBS (for example, potential risk categories are identified for each WBS component). This systematic approach ensures that risk planning is carried out in an integrated manner with the project scope.

• Procurement and Contract Management: In large projects, the work breakdown structure also helps determine which parts of the project will be procured externally. Specific sub-components in the WBS can be treated as independent contract packages. For example, in a construction project, if “Electrical Installation” is a sub-WBS component, and this work item is to be outsourced, that WBS element is converted into a tender package. Offers and contracts from suppliers can be organized with reference to WBS codes. This ensures that the scope of work is clear in contract management and that contractors' responsibilities are defined based on the WBS.

In addition to the above, WBS also has indirect contributions in areas such as communication management and quality management. In communication management, WBS helps to understand who is working on what, making it easier to communicate the right information to the right stakeholders. On the quality side, the acceptance criteria and standards defined for each WBS component can be specified in the WBS dictionary and used in quality controls.

In summary, the WBS serves as the backbone of project planning. It provides a common reference point for all planning and control processes within the project. Structuring the scope in this way clearly shows the project manager and team where they stand and what they are responsible for delivering, and lays the groundwork for all other project management processes to be carried out in a more consistent and integrated manner.

Benefits

The main benefits of the work breakdown structure in project management can be summarized as follows:

• Clarification and Completeness of Scope: WBS reveals the scope of the project in its entirety. This gives all parties a clear understanding of what the project includes and does not include. Tasks not included in the WBS are excluded from the project, preventing unnecessary work and scope creep. This 100% scope principle leaves no room for surprises at the end of the project.

• Ease of Planning and Control: Since the project is broken down into smaller parts, estimation and planning are more accurate. Separate time and cost estimates can be made for each work package, enabling the total project duration and budget to be determined more accurately. The WBS provides a solid foundation for scheduling, cost, resource planning, and risk analysis. With this structure in place, the project manager can monitor the project's progress in parts and identify delays or budget overruns early on. Performance measurement techniques such as earned value analysis can be easily applied based on WBS elements.

• Communication and Understandability: WBS is like a visual map of the project. Especially when displayed as a tree diagram, it visually presents the whole project and the relationships between its parts to the entire team. This allows team members and stakeholders to understand the project holistically. A team member can see where their work fits into the whole project from the WBS, while management can better track the value that will be created when all parts are completed. As a result, the WBS improves communication between stakeholders and reduces misunderstandings.

• Assigning and Tracking Responsibilities: Assigning a responsible party to each WBS work package increases accountability. Project team members understand their tasks more clearly because they know they are responsible for the WBS items assigned to them. Additionally, in large projects involving multiple teams, the WBS prevents conflicts and facilitates coordination by assigning specific tasks to specific teams. Thanks to HRM, when a problem arises in any part of the project, it is easy to see which team or person is responsible.

• Risk and Priority Management: When identifying project risks, the systematic structure of the WBS ensures that no important issues are overlooked. A comprehensive risk list can be created by asking the question, “What kinds of risks could there be in this part?” for each WBS component. In addition, the WBS helps the project manager focus their attention on critical components. For example, the components with the highest cost or duration in the WBS may be areas that require special monitoring and risk planning by management. In this way, the WBS guides risk assessment and priority setting.

• Efficiency and Control: Preparing the WBS encourages the team to participate in the project planning process. Team members involved in planning are more willing to comply with the plan (participation increases motivation).

• Thus, the WBS positively affects efficiency by increasing ownership within the team. Additionally, well-defined work packages allow the project manager to delegate tasks gradually, assign clearly defined packages to subcontractors, and track the progress of each package separately. This provides tighter control and transparency. Progress records maintained using WBS codes simplify reporting and clearly show all stakeholders which parts of the project have been completed and which are ongoing.

A survey conducted by PMI revealed that the vast majority of project managers are satisfied with the use of WBS. 87% of participants stated that they use WBS as a planning tool for at least half of their projects, while more than 60% stated that they use it in almost every project. The main purposes of use were identified as activity definition, resource planning, scope definition, cost estimation, and risk planning. Additionally, 91% of participants expressed satisfaction with the WBS's ability to meet these objectives. These findings demonstrate that WBS is widely accepted in current project management practice and that its benefits are confirmed in application.

Limitations

While the work breakdown structure is a powerful tool, it also has some limitations and challenges:

• Does Not Include Time and Sequencing Information: The WBS structurally sequences tasks but does not show the timeline or dependencies between activities. Therefore, information such as the order in which tasks will be performed and how long they will take must be planned separately in a project schedule and network diagram. It is not possible to determine the project duration or critical path by looking at the WBS alone. This distinction requires consistent integration between the WBS and time planning.

• Risk of Excessive or Insufficient Detail: Finding the appropriate level of detail when creating a WBS is important. An overly detailed WBS can complicate management and create unnecessary bureaucracy by including thousands of small work items. On the other hand, a too-general WBS also fails to achieve its purpose; grouping important tasks under a single heading reduces planning and control capabilities. The project manager should determine the optimal level of breakdown based on the project's size and complexity. Generally, it is good practice to assign a task to a single responsible party at the work package level and keep it at a size that can be completed within a reasonable timeframe and budget. However, achieving this balance may require experience and should be reassessed for each project.

• Change Management and Flexibility: If changes occur in the scope during the project, the WBS must also be updated. If change control is neglected, the WBS may become an invalid document that does not reflect the actual project status. Especially in agile management approaches, the scope of the project may evolve over iterations; in such cases, creating a detailed WBS at the outset may be difficult or unnecessary. The 7th edition of the PMI standard also states that project teams can use different tools such as WBS, product backlog, or task board to break down work. Therefore, in environments with variable requirements, dynamic tools such as backlogs may be preferred over WBS. This situation demonstrates that the WBS concept is more useful in predictable projects with relatively fixed scopes; in rapidly changing projects, the WBS may need to be revised frequently, which requires additional effort.

• Challenges in Creative and R&D Projects: In some projects (e.g., R&D, new product development, or creative design projects), it may be difficult to clearly define all outputs at the beginning of the project. Creating a WBS requires a certain level of foresight and knowledge about the project. If the project’s progression is exploratory in nature, the WBS created at the outset may remain too general or require significant revisions as the project progresses. This uncertainty does not limit the benefits of the WBS but necessitates that the project team treat the WBS as a living document and update it as needed.

• Standardization Issue: Using a single WBS template for all projects across an organization may not always be possible or desirable. For example, in some industries (such as the defense industry), all projects are required to adhere to a specific standard WBS format (such as the US Department of Defense's MIL-STD-881 standard). While this may be beneficial for cross-project comparisons, it can limit the flexibility of individual project managers to structure their projects in the most appropriate way. Since each project has unique needs, the WBS structure should be adaptable to the specific project. Otherwise, the project manager may be forced to include certain elements in the WBS solely due to standard requirements or apply an unnatural hierarchy. This risks turning the WBS into a formality rather than a tool that serves to manage the project.

Aware of the above limitations, experienced project managers strive to use the WBS as a goal-oriented and flexible tool. For example, in agile environments, a high-level WBS that shows the big picture can be prepared, and detailed task breakdowns can be left to sprint planning. Or, in uncertain projects, the WBS can be kept to include only the currently known deliverables and updated iteratively. The fundamental rule is to ensure that the WBS remains a tool that facilitates project management, not an end in itself.

Example 1  

Sections B.3.1–B.3.3 of Appendix B of the MIL-STD-881C standard define the basic principles for how WBS elements should be structured. Commonly used WBS elements (e.g., systems engineering, program management, integration, testing, training, data management) should be placed at the levels they support. While it is generally recommended that the WBS be detailed to the third level, this structure can be extended to lower levels (levels 4 and 5) for elements with high cost, risk, or technical complexity. The “100% rule” should be followed when developing the WBS; this means that each lower level must cover the entire work of the higher level.

^{B.3 Work Breakdown Structure Levels (MIL-STD-881C)}

In some cases, items such as software can be represented at a higher level when they cannot be directly associated with the system component they support. It is also noted that early identification of intelligence activities contributes to risk and cost management. WBS numbering is done for reporting purposes, and systematic consistency is targeted. WBS items under the “Other” heading should only be used when necessary and should be subject to an official approval process after being defined. When plural representations such as “(1...n)” are used, each item should be numbered separately at the lower level and clearly defined.

^{The Connection Between Contractor WBS and Contractor Management Systems (MIL-STD-881C)}

This section defines the fundamentals of intelligence requirements, software systems, software management, and integrated planning processes as outlined in MIL-STD-881C. It notes that intelligence activities (security, threat, mission data) are typically addressed in the later stages of the procurement process, but that early identification is important for cost, schedule, and performance management. Two main categories are defined for software systems: software embedded in a weapon system and automated information systems (AIS). AIS are systems where the final product itself is software and typically does not involve a manufacturing process; therefore, different WBS structures are used in the development and deployment processes. Software that runs on hardware should be placed under the hardware components to which it belongs and, when necessary, detailed at lower levels. Since software development processes carry high risk and cost, the program manager may need to request visibility into these processes. However, this visibility should be provided without overly detailing the WBS structure. The traceability of software activities is ensured through the relationship between the contractor management system and the WBS structure. The Integrated Master Plan (IMP), on the other hand, structures the project process based on events, defining the deliverables required for the completion of each event and the criteria associated with them; it is independent of the timeline and is a high-level document used to track progress in the systems engineering process.  

Example 2

As an example scenario, consider the work breakdown structure of a simple residential construction project. In this project, the final delivery is “Completed House” (Level-0).

Under this top-level item, the main components that make up the house can be defined as Level-1 items:

• Level-1: Foundation and Frame Construction – Pouring the concrete foundation and constructing the load-bearing structure of the house.
• Level-1: Roof and Waterproofing – Installing the roof, laying tiles, and ensuring waterproofing throughout the structure.
• Level-1: Exterior Facade – Building the exterior walls, plastering, and applying exterior facade cladding.
• Level-1: Interior Work – All work inside the building (wall partitions, plumbing, interior decoration, etc.).

Now, let's break down the “Interior Work” heading into its sub-components at the Level-2 level:

• Level-2 (Interior): Electrical Plumbing – Installation of all electrical wiring, lighting, and outlet systems in the building.
• Level-2 (Interior): Sanitary Plumbing – Installation of clean water and wastewater piping systems, and installation of bathroom and kitchen sanitary plumbing.
• Level-2 (Interior): Interior Decoration – Interior finishing work such as wall painting, floor tiling, door and window installation, and kitchen cabinet installation.

Each Level-2 item can be further broken down into more detailed sub-tasks (Level-3, etc.) as needed. For example, Electrical Installation can be broken down into sub-tasks such as “cabling infrastructure installation,” “circuit breaker panel installation,” and “fixture installation.” However, the work package level is typically planned as the lowest level to be addressed from a project management perspective. In this example, Level-2 items are accepted as work packages.

This HR example shows all the tasks and deliverables of a residential construction project in a hierarchical manner. The project manager can create separate plans for each sub-item. For example, the Electrical Installation work package can be assigned to an electrical engineer, and its schedule and budget can be determined, while a plumbing team can be assigned to the Plumbing package. During progress tracking, the status of each package (started, in progress, completed) is reported, enabling monitoring of the project's overall progress. If, during the project, an additional task (e.g., smart home system installation) is to be added to the Interior Decoration scope, this can only be done by adding a new sub-item to the WBS and updating the scope. This will trigger a change control process—meaning that official change approval will be required to perform work outside the WBS.

As seen, the work breakdown structure enables the project team to “break down the big picture into parts.” Especially in complex and multidisciplinary projects, without the WBS, information such as which team is doing what and which parts have been completed can easily lead to chaos. The WBS simplifies many challenging aspects of project management by presenting this information in a structured framework. As a result, the Work Breakdown Structure has gained widespread acceptance as an indispensable building block for defining, planning, and controlling scope in project management—a fundamental management tool that contributes to project success when applied correctly.