WBS (Work Breakdown Structures) - A Step By Step Guide

From apppm
(Difference between revisions)
Jump to: navigation, search
Line 68: Line 68:
 
3. Finish-to-Finish - If two tasks have a finish-to-finish dependency, the successor task can not be finished, before the predecessor task is done.<ref name="ref2" /><br />
 
3. Finish-to-Finish - If two tasks have a finish-to-finish dependency, the successor task can not be finished, before the predecessor task is done.<ref name="ref2" /><br />
 
4. Start-to-Finish - If two tasks have a start-to-finish dependency, the successor task is not allowed to finish, before the predecessor task starts.<ref name="ref2" /><br />
 
4. Start-to-Finish - If two tasks have a start-to-finish dependency, the successor task is not allowed to finish, before the predecessor task starts.<ref name="ref2" /><br />
 +
 +
 +
critical path
 +
 +
 +
schedule
 +
  
  

Revision as of 17:09, 8 May 2023

Contents

Introduction

Definitions

Best Practices

Deliverable Oriented

The WBS (Work Breakdown Structure) is focused on the end result or what needs to be delivered. A deliverable is something that must be made to finish a project and it can be a product, result, or service. The WBS is aligned with deliverables, meaning it is focused on what needs to be delivered.[1]

Hierarchical Decomposition of the Work

Another key concept of WBS is the hierarchical decomposition of work which breaks down the project into smaller parts so that it's easier to manage. This process is called "decomposition". The WBS makes it clear what the project involves by dividing it into smaller parts that are easier to understand. The number of levels used in the WBS should be enough to make sure the project can be managed well.[1]

The 100% Rule

The 100% Rule is an important part of the WBS (Work Breakdown Structure). This rule says that the WBS must include all the work for the project, including project management, and must add up to 100%. This means that the WBS should only include the work that is part of the project and should not include any extra work. The 100% Rule applies to all levels of the WBS and the work for each level should equal 100%. [1]

A Step-by-Step Guide

The following guide is meant to help project managers to go from zero to 1 in developing a work breakdown structure for their own project. It is also meant to be mainly for beginners to get started with the concept and provides easy-to-follow instructions for each step. Developing a work breakdown structure is an important part of project planning and the official name of structuring the work of a project in an outline and going from phases on the highest level to tasks on the lowest level.[2]

1. Project Work Plan

The first step in developing work breakdown structures is to create a project work plan. At the beginning of the project work plan, it is recommended to brainstorm and answer the following questions:[2]

  • What is the primary goal?[2]
  • Which intermediate deliverables need to be met to achieve the primary goal?[2]
  • How will the project be organized in regard to remote teams or collaborating groups?[2]
  • Which detailed tasks are needed for the intermediate deliverables to be achieved?[2]
  • What is the needed order of the tasks or is a specific sequence required?[2]
  • How much time do specific tasks take and what determines the effort?[2]
  • Which skills are required to fulfill a task?[2]
  • Who will do which task and when?[2]

Furthermore, the project definition document can be used as a starting point for the project work plan. All the things the project needs to deliver should be investigated and a way of tracking the progress chosen. The chosen template needs to be reassessed if it fits the specifications of the project. Additionally, the summary schedule needs to be checked for completeness, and the budget for accuracy. To create a plan, the project manager has to know what the project is supposed to deliver. This information can be found in the definition document made during the idea phase.[2]

Work Plan Templates
Work plan templates can be effective shortcuts to getting started with the work plan. Many projects, especially in the same field, have a lot of similarities, it can be useful and timesaving to use a template. However, since these templates include hundreds of predefined tasks, it is important to go through them thoroughly and exclude the unfitting ones, and add potential missing tasks.[2]
If there are no suitable templates available or it is the first work plan of its kind, it needs to be created from scratch. The following paragraphs will focus on this case.[2]

Activity Definitions
If the Work Plan needs to be developed from scratch, the project manager should start by defining the main activities. Defining activities means figuring out and writing down the specific tasks needed to create deliverables and tasks listed in the definition document. Ideally, the project manager will work with the project team during this step, however, sometimes the team is not chosen until after this step.

To start defining activities, the project manager should think about four main things:

1. Definition document – The project's reasons and goals in the scope statement are important for this process.[2]
2. Past projects – What was needed in similar projects before can help us understand what's needed in this one.‎[2]
3. Limits – Things that restrict the team's choices, like a set end date or a strict budget, need to be taken into account.‎[2]
4. Basic work breakdown structure – A simple breakdown of the project into phases can help guide this step.‎[2]

Constructing Work Breakdown Structures
At the beginning of creating a Work Breakdown Structure, tasks should be grouped by similar traits. These groupings can be structured by different similarities such as activities, geographies, or functions. As described earlier, using an existing template can greatly speed up the process of defining activities. However, if no such template is available, the clustering of tasks "can be as much art as science". After the grouping process, the level of detail of the tasks should get assessed. Too little detail would be a three-phase plan with 1000 hours each and the other end of the spectrum, for example, a plan with 3000 one-hour tasks would be too detailed.[2] One rule that can help with figuring out the amount of detail is the so-called "Rule of 80". “The 80-hour rule stipulates that you break a project into tasks of 80 hours or less, each of which must result in a tangible product or deliverable.”[3] In general, the level of detail for a project varies for different projects and needs to be decided each time. However, rules of thumb such as the "Rule of 80" and experience can help a lot.

How to deal with "Non-Deliverables" Tasks
When going through the tasks of the work breakdown structure, one might think that many tasks are missing which are not deliverables themselves but are helping or are needed for other deliverables. These types of tasks are called "scaffolding tasks". They are named after the scaffolding in the construction industry. Similarly, as scaffolding is only used during the construction process of a building, and then removed these tasks are only done during deliverables. They can take up significant time and recourses and therefore need to be considered in the planning process.[2]
Three main categories of scaffolding tasks are being distinguished:
1. Support Tasks - An example of a support task would be writing a script to convert a database from one format into another one. The deliverable is the database in the new format and the support task is writing the script for the conversion.[2]
2. Project Management Tasks - This type includes tasks such as task tracking, analysis, and scope management.[2]
3. Administrative Tasks - This category includes tasks such as printing, non-project meetings, and more.[2]

2. Relationships of Tasks in the WBS

Task Dependencies
The next step, after building the work breakdown structure and deciding on tasks, is to analyze the tasks in regard to dependencies between each other. This step is highly important because some tasks can only start when others are done. An example would be that the foundation of a building needs to be completely finished before the building of walls can be started. Therefore, the predecessor and successor relationships of tasks need to be examined thoroughly. This also enables the creation of the critical path of the project.[2]
Four kinds of task dependencies are distinguished:
1. Finish-to-Start - If two tasks have a finish-to-start dependency, the predecessor task needs to be completely finished, before the successor task starts immediately when the first one is done.[2]
2. Start-to-Start - If two tasks have a start-to-start dependency, the predecessor task needs to start, before the successor task starts.[2]
3. Finish-to-Finish - If two tasks have a finish-to-finish dependency, the successor task can not be finished, before the predecessor task is done.[2]
4. Start-to-Finish - If two tasks have a start-to-finish dependency, the successor task is not allowed to finish, before the predecessor task starts.[2]


critical path


schedule



4. Resource Planning and Acquisition

5. Team Development

6. Cost Estimation and Budgeting

Summary

References

  1. 1.0 1.1 1.2 S. Norman, Shelly A. Brotherton, Robert T. Fried, Work Breakdown Structures - The Foundation for Project Management Excellence, (Wiley, 2008)
  2. 2.00 2.01 2.02 2.03 2.04 2.05 2.06 2.07 2.08 2.09 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 2.18 2.19 2.20 2.21 2.22 2.23 2.24 2.25 2.26 G. Cicala, The Project Managers Guide to Microsoft Project 2019_ Covers Standard, Professional, Server, Project Web App, and Office 365 Versions-Apress, (Apress, 2020)
  3. Donald H. Plummer, Productivity management: Keane's project management approach for systems development, (Keane Inc., 1995)
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox