Work breakdown structure#

wsman sysman sysadmin

The work breakdown structure is the foundation of every project plan.

Within the overall planning process, a work breakdown structure answers the question of what needs to be done. Depending on the method used, this breakdown of a project undertaking into individual items is called a work breakdown structure ( DIN 69901-5) , product breakdown structure ( PRINCE2) or work breakdown structure ( PMBOK® Guide 2017).

What all of these plans have in common is that they encompass all the elements of a project and their relationships to one another. The elements are arranged hierarchically in a tree structure, without making any statement about the precise chronological course of execution.

On the basis of this “plan of plans”, the later planning stages then address schedule and process planning, resource planning and cost planning.

../../_images/projektstrukturplan.png

According to DIN 69901-5, a work breakdown structure (WBS) is structured using three kinds of element:

  • sub-projects

  • sub-tasks

  • work packages

Sub-projects make it possible to use different process models within an overall project. For example, it may make sense to use a classic waterfall method in a sub-project for the development of an electronic component and to work with agile methods in a sub-project for the associated software development. In Allegra you can use hierarchical workspace structures with different workspace types for this purpose.

Sub-tasks are elements that can be broken down further in the work breakdown structure. In Allegra we call sub-tasks “parent items” or “summary items”.

Work packages represent the lowest level of a work breakdown structure and can be broken down further into items or tasks in the course of the planning process. We also model work packages in Allegra as “parent items”.

In this form, the work breakdown structure appears activity-oriented, with a focus on the activities rather than the results. A product breakdown structure emphasizes the results, whereas a work breakdown structure requires the combination of an activity and a verifiable result.

../../_images/projektstrukturplan-horizontal.png

Finding items#

In order to create a work breakdown structure or product breakdown structure, you first have to find the elements that belong to it. In Allegra we call such elements “items”. To do this, picture two points in time: the initial situation and the final situation. If the final situation can be described in terms of objects that are to be created over the course of the project, break these objects down into sub-objects. Break the sub-objects down further unless they are purchased externally or elementary. In other words, you create the plan in a product-oriented way.

If the projects are strongly activity-oriented in character, such as a relocation, you collect the activities and try to categorize them. In the case of a relocation, the rooms lend themselves as the topmost category level, for example.

Collecting the elements for the project or sub-project can be supported by mind mapping or brainstorming.

Arranging items in the work breakdown structure#

How do you arrange the elements for your breakdown structure? For the work breakdown structure, DIN 69901 offers three suggestions for arriving at a good structure depending on the type of project:

  • object-oriented breakdown

  • function-oriented breakdown

  • time-oriented breakdown

In the following, we go through these principles using an example: the construction of a small workshop.

Object-oriented breakdown#

This approach is best when the project goal is a concrete object, such as a garage, an office building or a gas burner. The object-oriented structure produces a plan that is very similar to a product breakdown structure according to PRINCE2.

../../_images/projektstrukturplan-objekt.png

The advantage over a function-oriented approach lies in better traceability during project execution. A result is easier to check than activities. Checking the process essentially requires accompanying the project in real time, whereas checking on the basis of the process results can easily be done much later.

An object-oriented work breakdown structure is, in principle, a product breakdown structure if you look not only at the end products but also at intermediate products such as design documents or test reports.

Function-oriented breakdown#

The function-oriented breakdown is best when the project can be described more vividly through the activities or work packages to be carried out than through the results of those activities. For a relocation, for example, you could describe what the result should look like. In doing so, however, you would miss the essential point, namely the relocation of the objects from the point of origin to the destination.

For comparison, the next figure shows the function-oriented work breakdown structure for the construction of a new workshop. Unlike a relocation, in this case a function-oriented approach is also possible.

../../_images/projektstrukturplan-funktion.png

Time-oriented breakdown#

In a time-oriented structure, you create the plan directly from the necessary tasks. To do this, you think through the course of the project, i.e. what has to be done one after another. You write these activities down on a list or enter them directly into the system. As the list gets longer, you break the sequence down into phases. For a relocation, for example, you could provide a phase for each room and, below that, phases for furniture and odds and ends.

../../_images/projektstrukturplan-phasen.png

Which breakdown principle should you use?#

The choice of breakdown principle depends on the type of project. Whenever possible, you should favor the object-oriented approach, and only use the function-oriented method when that does not fit. The function-oriented structure lends itself to projects in which the project can be described more vividly through its activities than through the results of those activities.

Coding in the work breakdown structure#

In order to uniquely identify the individual items in the work breakdown structure, it is important that they are assigned a code. This makes it possible to always assign efforts, resources or changes unambiguously to a work package later on. The coding must reflect the hierarchical position of the element. Several types of coding are distinguished:

  • Numeric coding: use of digits, e.g. 1, 1.1, 1.1.2…

  • Alphabetic coding: use of letters, e.g. A, AA, AB, …

  • Alphanumeric coding: a mix of numbers and letters, e.g. A, A1, A.1.1 …

  • Decimal coding: digits in a base-10 format, e.g. 1000, 1100, 1110 …

Allegra always uses numeric coding automatically. Note that an item is assigned a different code when its position in the breakdown structure changes.

How detailed do you have to plan?#

A major challenge when creating a work breakdown structure is finding the right level of detail. It would be pointless to plan steps early in the project that depend on many boundary conditions and for which there is no way to predict what those conditions will look like at the time the plan is realized.

As a rule of thumb, work packages at the lowest level should not take longer than the interval between the regular project meetings. This ensures that deviations can be detected no later than at the meeting after next.