Skip to content

Building the Work Breakdown Structure (WBS)

This article describes how to build and plan the activities by means of a Work Breakdown Structure (WBS) regarding scope management during project execution.

My vision is that the project planning is intended to be a means and not an objective. What do I mean by this? The amount of time a Project Manager invests in planning and the amount of details should be proportional with the size of the project. In other words: don’t invest too much time in a project planning and keep the project planning clear. A project planning of eg. 1000 lines is hardly to oversee and requires a lot of time to build and maintain (even when you use the ‘fold mechanism’ of the tool). The structure of the project planning is of utmost importance to keep an overview and to see the relationships between the tasks.

The scope defines what should be delivered by the project. Nothing more and nothing less. However, in practice this is one of the hardest things to manage in a project also due to changes during the course of the project (proper change management can save you a lot of trouble).

The scope description should not only contain what will be inside but also what will be outside the scope. In case you apply eg PRINCE2 this should be described in the Project Initiation Document (in the project definition section).

What should be delivered should be documented by means of the ‘product decomposition structure’. This is the basis for the planning and management.

Also add to the planning overall activities such as Quality Management and Communications Management.

Some practical tips for making a project planning:

  1. Start with making one main task and indent all other (‘summary’) tasks which enable you to see immediately the entire project duration.
  1. Create a ‘summary’ task for Project Management while you need this role during the entire project.
  1. Create a ‘summary’ task called ‘dependencies’ (eg.hardware delivery) in which you define all external (outside the project) dependencies (might be in the form of a milestone). Link all other tasks (or summary tasks) which are depending on this dependency. In this way you can see immediately what the impact will be of a dependency on your planning.
  1. Terminate a ‘summary’ task with a deliverable (as milestone) which enables you to see quickly when what is being delivered (and this is why we are doing the project isn’t it?).
  1. Planning of tasks etc. over a half a year is normally not very useful. Of course you plan what needs to be done but that’s about it. In the meantime so many things can (and will) change (often called ‘progressive insight’) that the chance is pretty big that this part needs to be planned again.
    When you are using an Agile approach this is quite different while a ‘sprint’ is of a rather short period (weeks).
  1. Use the task ‘note’ option to document remarks and assumptions.
  1. Use for instance first ‘mindmapping’ to determine the project planning structure and then make the actual project planning which can be derived directly from the ‘mindmap’. The big advantage of a ‘mindmap’ is that this on a single page makes it easier to keep the overview and see the relationships.
  1. Add in the ‘footer’ of the project planning the date so you can always see which planning version this is.

This is an article by Lex van der Heijden regarding practical Project Management. For questions/remarks I’m available via [email protected] or via LinkedIn (