Revision as of 00:25, 1 March 2021

Abstract

Work breakdown structure, as the wording suggests, refers to the tool utilised to break larger work into smaller tasks. This is a common productivity technique related to project management, seeking to make the work and complexity af the task more manageable and approachable. It is defined by The Project Management Institute (PMI) Project Management Book of Knowledge (PMBOK) as a “deliverable oriented hierarchical decomposition of the work to be executed by the project team.”. The work breakdown structure is seen as one of the most vital tools to utilise the work breakdown technique as well as project management document. It integrates both scope, cost and schedule baseline for the project, ensuring that these are in line with the project plan.^[1] The work breakdowns structure was originally used in project management, but is also becoming increasingly popular to utilise in program, portfolio and enterprise management. The workbreak down can be structured based on different project characteristics such as deliverables, phases and responsibilities, and common for these are that the final product is decomposed hierarchically but all together represents 100% of the work to be carried out.

Big Idea

The Work Breakdown Structure (WBS) describes an effective technique used in decomposing a project (or even a program, portfolio or enterprise) down into hierarchical deliverable elements. Each of these elements should correspond to a specific outcome necessary to be accomplished in order for the project to be complete. By virtue of schematically presenting all the project objectives and their relation between one another in appropriate format and level of detail, a WBS is in particular great in providing a clear overview of the project scope. Furthermore, a well-designed and properly maintained WBS displaying the tasks and dependencies to the project associates or workers carrying out the work, makes it a valuable tool applicable to projects of any size and complexity.^[2]

Use of the Work Breakdown structure

The work breakdown structure serves to cater many project management disciplines. Initially, it serves as a planning tool to help the project team plan, define and organize scope with deliverables. The Work breakdown own structure is usually also used as the primary source of schedule and cost estimate activities. Moreover, it is used as a description of all the work related to a project and a tool for monitoring and controlling these, which serves as its biggest contribution to project managers.

The level of decomposition varies in between projects, but it usually depends on the degree of control needed to properly manage the work that has to be achieved.

100% Rule

A critical rule associated with all levels of a work breakdown structure, regardless of its type, is the 100% Rule. The aim of this rule is to achieve the effective creation of the WBS and to assess its disintegration. It is essential in order to ensure that the WBS includes all the required work, and only the required work, to complete the project successfully. The 100% Rule is a principle which states that the WBS should include 100% of the project’s scope and 100% of the deliverables included in it.

The rule applies not only to the project scope, but to all levels of decomposition in the WBS and says that the next decomposition of a WBS element (“child” level) must represent 100 percent of the work applicable to the next higher (“parent”) element. .^[2] This means that all deliverables that form a descending level must equal to 100% of the work needed to complete the outcome stated in the previous level. The lowest levels should all together sum up the higher levels ensuring that nothing is left out and no extra work should be performed.^[2]

Application

The key benefit of the WBS is that it provides a clear framework on what has to be delivered.^[1] The WBS assists project managers, team members and other stakeholders in the development of a clear outline of the product or project outcomes.^[2]

Creating a Work breakdown structure

Identify Key Deliverables The key idea behind a WBS is greatly related to the overall approach of decomposing extremely complex tasks and projects into less complicated smaller fragments and agreed deliverables.

The project deliverables are the decomposed work packages into schedule activities that provide a basis for estimating, scheduling, executing, monitoring, and controlling the project work. ^[1] Each deliverables in the WBS has to correspond to a specific outcome that must be accomplished to complete the project. However, it is important to note that all deliverables should be in the form of outcomes, not actions. These can be temporary means or tools needed to fulfil a project or final element produced in order to successfully complete the project. Opposed to actions and the procedures followed to obtain these that are harder to anticipate, outcomes are final products or results that can be predicted precisely. ^[2] For example, an IT contractor might develop prototypes and budget estimates as so-called interim deliverables for the customer to evaluate, however these are not the deliverables that would be a part of the final solution and serve as a satisfying project-delivery. The final deliverables would be relevant platforms and applications performing the tasks desired by the user.

Include project team and -stakeholders In order for the WBS to become as relevant and tangible for the project team as possible, it is crucial to base the WBS on input from the team members. Creating the WBS with very little input from the other members of the team, may lead to the team being reluctant in buying in or supporting the WBS. Though it might be time consuming, engaging the team will be beneficial and pay off in the long run. Furthermore, it will rely on more people’s experience making it more thorough.^[3]

When developing or evaluating a WBS, the presence of following core characteristics are used to determine a quality WBS ^[3]

• Is a deliverable-oriented grouping of project elements, which contains 100% of the work defined by the scope
• Clarifies the work and communicates project scope to all stakeholders through provision of a graphical, textual, or tabular breakdown of the project scope
• Uses a coding scheme to clarify its hierarchical level
• Has at least two levels with at least one level of decomposition
• Captures all internal, external, and interim deliverables to be completed, including project management.
• Contains elements that are defined using nouns and adjectives — not verbs
• Is created by those who will be performing the work with technical input from subject matter experts (SMEs) and other project stakeholders.
• Continuously and Iteratively evolves along with the progressive elaboration of project scope and updated in accordance with project change control.

In general it is possible to distingue between three types of work breakdown structures:

Deliverable-based work break down structure

Deliverable-based structure for WBS. Source: Visual Paradigm.^[4]

Deliverable-based work breakdown structures is the most common approach, and often the preferred way to initiate the phase of defining how to achieve succes in a project or program.

When creating a deliverable based WBS several criteria can be used for developing the plan in order to meet specific requirements from the project. For example, a craftsman who is building a house might decide to break down the project into elements reflecting rooms in the house, levels above the ground, building elements such as concrete or wood, etc. The deliverables for this should then clearly be stated as: “cast concrete for foundation”, “windows in place” or “roof rafters erected”.

Phase-based work break down structure

Phase-based structure for WBS. Source: Visual Paradigm.^[4]

Phase based work break down structure is opposed to the deliverable based work breakdown structure not necessarily bound to specific deliverables to be in place in order to complete the subtask. The phase-based work break down structure is linked to the predetermined phases of the project. This provides the team with a clear timeline and tool for prioritising what tasks to work on. ^[4]

Responsibility based structure

The responsibility based WBS distributes the work packages between the teams who are responsible for them to be carried out. This will help the teams gain a clear idea of who will be working on which tasks, as well as the individual teams will know what they will have to achieve in order to see the project through.

Responsibility based structure for WBS. Source: Visual Paradigm.^[4]

The levels of a work break down structure

A work breakdown structure is usually developed in a structured way imitating the shape of an inverted tree. It is organized based on objectives, looking like an organizational chart, that can help the project team and lead in visualizing the entire project with its main components. The hierarchy of the work in the project is broke down vertically, moving from the goal of the project in the top to the tasks and their subtasks on the bottom. When estimating the project schedule and deadlines, the decomposition framework provides a good level of confidence, as it shows all the work to be accomplished – or the 100% of the work in the project.

Level 1 Breaking the structure into levels the first level can be said to hold the project’s ultimate goal. This level comprises the full scope of the work which will be necessary to produce and deliver a product or project. It includes all direct and indirect work. It is always a single WBS element. It can be composed of a name and a WBS identifier, to help differentiate it from other WBSs in a program or portfolio of projects. The numbering of level 1 affects the numbering down through the tree accordingly.

Level 2 The second level contains the project objectives or the outcomes of the project delivery. The second level is the first level of decomposition and is a high-level breakdown of the scope into key areas. In producing a product this will hold the basic components of the product including the project management and integration of parts. Include an annotated Example of a WBS This WBS example is based on an organization building and delivering a product to a customer’s specifications. The levels hold together the 100% of the entire workload present in the project.

Level 3 The third level decomposes the key areas of level 2 into its essential parts. This contains the project deliverables and starts to target specific and tangible outputs of the project of production phase. In creating a product this would include all the output parts need to be made in order to make the product.

Level 4 Based on the projects scope and level of complexity, it can for some projects be relevant to include a fourth level. The fourth level describes the activities and contains the specific tasks to be carried out. Depending on the project complexness this level might be holding a lot of tasks which, in the same manner each represents 100% of each exclusive area from level 3. An example of this can be product tests related to the quality control deliverable.

Keeping the WBS continuously relevant

During the initiating and planning phases, the primary role of the WBS is often to collecting and documenting information regarding the project. This serves as a mutual point of clarification for the team members. It describes, often in great detail, the project scope and their boundaries as well as the deliverables and outcomes of the project. During Executing and Monitoring and Controlling phases, the WBS takes a more active role as opposed to the passive role in the planning phases. Here it takes on the role of project decision support and is used a source of reference for control and measurement of the project progress. This is where the WBS comes to life as a valuable tool for the project manager, as well as a guideline and common ground for all team members working on the project.^[3].

Continuously ensuring to update the WBS in accordance with the project change control process, ensures that the WBS is still in line with the project scope. Assessing the impact of scope changes are enhanced through the use of a WBS and increases the project manager’s ability to adjusting the WBS if project scope is changed. This will ensure that future changes are based on an updated, agreed-upon project baseline, making the WBS remain relevant.

Limitations

According to the PMBOK some of the common things that can go wrong during the project, regardless of the project managers planning and execution of work. However, some of these failures can be linked to the development of the WBS or lack hereof. Experienced project managers know that there are many things that can go wrong in projects regardless of how successful the project managers are in the planning and execution of their work, and failures and schedule delays amongst others are often related to a poorly developed WBS.^[3] Things as unclear work assignments, goals, objectives, or deliverables is said to be linked to poorly structured WBS but could also expose the limitations of using work break down structures. As said to be holding 100% of the work whilst clearly stating the scope and objectives of each task, the complexness of each task or deliverable can’t always be predicted beforehand. The development of an WBS aiming to hold all necessary information about the scope and the outcomes of the project might be a task which is too complex in itself and too time consuming in order to be manageable. In this way the WBS has clear limitations and might not be holding all the information needed to oversee the project.^[3]

Furthermore, relying on a WBS being a complete plan of all work to be done, whilst this is the purpose of it, might lead to problems, if the project manager is not critical about the fact, that the WBS might not hold all the information on the detailing and requirements of the task to be carried out. Frequently updating and reflecting upon the present WBS should be practiced in order to keep the WBS relevant and reliable. ^[3] Another side effect of not continuously updating the WBS might on the contrary be that the project manager or project team members are be too reluctant on relying on the WBS. Keeping information and tracking tasks and deliverables by themselves will undermine the idea and outcome of the WBS.

The PMBOK defines the following as frequently arising negative outcomes of not updating and keeping the WBS relevant.^[3] - Incomplete project definition leading to ongoing project extensions - Unclear work assignments, goals, objectives, or deliverables - Scope creep or unmanageable, frequently changing scope - Budget overrun - Missed deadlines on scheduled deliverables, or timeline slippage - Unusable new product or feature - Failure to deliver on some elements of project scope.

References:

Annotated bibliography

Project Management Institute. “A Guide to the Project Management Body of Knowledge (PMBOK® Guide)”- Fifth Edition, 2013. The PMBOK Guide is the most referenced source in respect to literature regarding project management. This holds valuable information about properly managing projects as well as analysing key concepts crucial to project manangement. Furthermore it gives a thorough overview and information on project scope definition processes through the use of Work Breakdown Structures. Additionally Work Breakdown structure construction tools and methods are presented and thoroughly explained.

Project Management Institute. “Practice Standard for Work Breakdown Structures”- Second Edition, 2011. This book deep dives into the features of and requirements to the WBS, heightening the quality and work efficiency, when implemented in actual projects. Based on three key components being the process of constructing the original WBS format, the further development procedure and the process of its effective implementation, this book helps the reader understand the WBS in a real-life perspective.

Eric S. Norman, Shelly A. Brotherton, Robert T. Fried. “Work Breakdown Structures: The Foundation for Project Management Excellence”- John Wiley & Sons, 2008. Deeply analysing the process of developing and implementing Work Breakdown Structures in a project rather than product setting, this book help the project, program or portfolio manager in comprehending how Work breakdown structures work.

References

1. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named R1
2. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named R2
3. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named name
4. ↑ Cite error: Invalid <ref> tag; no text was provided for refs named R7

Cite error: <ref> tag defined in <references> has no name attribute.
Cite error: <ref> tag defined in <references> has no name attribute.
Cite error: <ref> tag defined in <references> has no name attribute.
Cite error: <ref> tag defined in <references> has no name attribute.
Cite error: <ref> tag defined in <references> has no name attribute.
Cite error: <ref> tag defined in <references> has no name attribute.