Project Planning I: The Work Breakdown Structure

Project Planning II: Effort

Introduction

A lot of work has to be done in a project (or in a major task). But how much effort will it really cause, and when will it be finished?

Fundamentals of planning

When it comes to project planning we have to make a basic distinction: What type of desired result has our project? It could be e.g. unknown, a building, a factory, a product, a changed behaviour of an organisation, or a software application.

In general the result of the project may be a) fairly unknown, b) tangible, c) intangible or d) a complex system. In each of these cases the emphasis of the project is a different one:

When the result of the project is fairly unknown, the project itself has to focus on evolution, when it is tangible, the project has to focus on structure, when it is intangible, the project has to focus on behaviour, and when the result of the project is a complex system, the project itself has to focus on structure and behaviour.

How is this done in detail?

Fairly unknown project result: evolution

If the desired result of the project is fairly unknown you have to use agile methods. In this case there is no "project planning" in the stricter sense. You have to establish certain procedures and rules instead.

Tangible project result: structure

In the case of a tangible project result you produce a first "object breakdown structure" like this one at the beginning. What will the result of the projct consist of?

(If the project is not about a new building but about a new company, this could be a first organisational chart of the new company. In case it is about a new product it could be a first product structure of the new product.)

Now you derive a work breakdown structure (WBS) from this. The WBS exclusively focuses on all the work that has to be performed in the project:

Here the work packages are clustered as logical phases (named with nouns), e.g. "Architecture", "Preparation", "Purchase", ..., but all the work that has to be done is described with verbs and nouns etc., like "Interview users", "Draw drafts and plans", "Produce a model", ...

Work is something you perform, it is an activity, not an object - therefore the verb in the description of the workpackage.

Please compare the OBS above and this WBS carefully. There is a lot of project work causing effort, cost and time shown in the WBS, which is never mentioned in the OBS above. Keep in mind that any work which is not reflected in the WBS will get no budget and no time in your project. Therefore this step of breaking down all work into a profound WBS is the most important step of all project planning.

Afterwards the Gantt chart is identical with the graphical WBS, only shown as a list instead of a graphical tree:

This will be the basis for your schedule and other plans later on.

Intangible project result: behaviour

If the desired result of the project is intangible and therefore focuses on behaviour, you first create a business process model.

Based on this - however shallow it may be at the beginning - you derive a WBS. In this case you consider all work which has to be done to change the behaviour of the current system towards the new processes. This is an example:

When you study this WBS you see that it is not about the new processes and the new behaviour of an organization. Instead of this it shows all the work that has to be done in order to bring the new processes to life. So it is all the work which has to be performed in order to reach the goals of the project. These goals are not to describe the processes, these goals are to implement them.

The Gantt chart is then again only a special view onto the WBS:

Complex system as project result: structure and behaviour.

The planning of a project producing a complex system (like a software application) is a combination of the structural and the behavioural challenges described above. So in the first step you use unified modeling langugage (UML) in order to create all necessary and useful structural and behavioural diagrams and models of the desired system.

Based on these models - however shallow they might be - you derive your WBS, e.g. like this one:

The Gantt chart then again is only a specific list view of this graphical WBS:

Again you see, that all the work packages in this plan are necessary for developing and implementing the software system, but this work is not directly found in any structural or behavioural model of the system. All the necessary work packages are derived from the system models - and the experience of how to develop software of course.

Therefore the creation of a proper WBS is usually done by brainstorming and clustering the necessary work packages in the project team.

Step 1: Collecting work packages in the core team

Step 2: Clustering work packages

Step 3: Completing the WBS

Step 4: Defining phases

Step 5: Numbering

But you may also copy and adapt your WBS from a sample WBS. It depends on how new and unique your specific project is.

Finally, when you have produced a convincing WBS you can continue with the effort planning, cost planning, schedule, resource planning and so on. But that is a different article.

Points of interest

In reality modern buildings and organisations are also considered as complex systems, but I used them in the form of simplified examples here.

And for the sake of ease I omitted all work packages concerning project management activites in my examples at the beginning. Of course the project management work itself must be reflected in a proper plan as well.

History

18^th of November, 2015 - Published

25^th of November, 2015 - WBS brainstorming example images added

26^th of November, 2015 - Links to part II added