A project is a huge bundle of work that has to be organized. Therefore, the “huge bundle” has to be divided into “little bits”, which can be handled. The basic idea is to break down the work in a hierarchical structure with several levels.

This chapter will describe:

• What a work breakdown structure is
• How it can be developed.

Before you proceed, please read chapter 4, pp. 109-143, of the textbook (Wysocki 2009).

What is a work breakdown structure?

The starting point – and the highest level – is the POS and the requirements/system specification. Wysocki (2009) defines it as “level 0”. Level 1 is the first division into “activities”. Activities can be broken down to lower-level-activities (level 2 – n). At the lowest level, each activity is divided into tasks. A group of tasks is defined as a work package (see Wysocki, 2009, Fig. 4.2).

Sometimes, the creation of such a Work Breakdown Structure is difficult due to the complexity of the project results. Therefore, the creation of an additional Product Breakdown Structure (PBS) could be helpful to break down the resulting product of the project into smaller sub-products. For more information on Product Breakdown Structures please have a look here.

There several ways to represent a work breakdown structure (WBS). Two examples are a simple text description (outline) and waterfall diagrams. The following figures depict a very simplified work breakdown structure of an IT project:

WBS: Textual outline

1. Project management

1. Meetings
2. Controlling
3. Reporting

2. Updating and detailing requirements and system specification

1. User interviews
2. System architecture

3. Prototyping

1. Development of components
2. System integration

4. Testing

1. End user tests
2. Administrators tests

5. Implementation

1. Technical implementation
2. Workflow implementation

6. Closing out

1. Documentation
2. Maintenance concept

WBS: Waterfall diagram

However, definitions are different. The following figure provides an example from the EC project “Bridge-it”. As before, the starting point is the overall project design and goals. However, the following levels are “work packages” and “tasks”:

Diagram - Click here

Another possibility, similar to the textual outline above, is realized by the software tool Microsoft Project: With the title “Task ID”, the “work packages are simply listed numerically in a hierarchy:

Diagram - Click here

Another option to name the different levels of this hierarchy is:

• Project (POS/specifications)
• Work packages
• Tasks
• Activities.

In the European context, the notation of “work package” for level 1 is more common, and will be used in this course. In contrast to the textbook, “activity” will be used as a synonym for “activity” and “task”.

No matter the wording, the most important aspects are:

• Activities are derived from POS and requirements and system specifications.
• The WBS is a hierarchical division of “bundles of work”.

A well-defined WBS fulfills the following criteria (derived from Wysocki 2009):

1. The status and the completion of an activity are measurable.
2. There is a clear start and end (event) of an activity.
3. Each activity has a physical result.
4. Each activity has fixed resources in terms of costs and duration.
5. The activity’s duration is acceptable against the background of the overall project.
6. From start to end, an activity is independent from other activities.

The WBS is an essential tool of managing a project. It is used for

• Visualization of what the project is
• Design of the overall project management
• Planning of project management tools, e.g., creating milestones
• Analysis of the processes and dependencies within the project
• Analysis for the status-quo of the project.

Development of a Work Breakdown Structure

The development of a WBS implies two questions:

• How?
• Who?

How:

The Top-down-approach starts with the highest level of the WBS, trying to break down the “bundle of work” from level to level. The contrary approach is to collect the required activities on the lowest level, e.g., in a brainstorm of all project team members, then grouping the low-level activities upwards from level to level.

Who:

The development of the WBS can be a team-oriented process of groups and sub-groups, as suggested by Wysocki (2009). A contrary approach is the development of the WBS by the project manager. Here, we can also speak of top-down and bottom-up approaches.

Personal experience is that most projects are running in a mixed-mode of both – top-down and bottom-up.

Projects are not necessarily “islands of democracy”. Especially in the conception phase, it can make sense if a single person develops a draft version of the WBS – at least for the higher level of work packages. Also, in the case of corrections and decisions, a project manager might be the boss. On the other hand, a single person will not be able to provide a substantial WBS, especially in bigger projects and on the lower levels of activities. A single person will lack the required know-how, and a group-orientated process will help a lot to provide this know-how and to generate ideas and solutions.

Also, the “how” to develop a WBS is often a mix of bottom-up and top-down approaches. As seen above, especially in the conception phase, the top-down approach of defining the work packages can make sense. On the other hand, the bottom-up-approach, starting with low-level activities, e.g., brainstorming with project partners or team members, supports the completeness of the needed activities.

It will depend on several factors, to which extent “how” and “who” will be performed in a top-down or bottom-up manner:

• Complexity of the project
• Number of project partners and team members
• Company culture concerning hierarchies vs. teamwork.