Creating a Project WBS - A Practical Guide

One of the practices that that is recommended in almost all books and guides of project management is the WBS or, in other words, the creating of the work breakdown structure of your project.

Anyway, even being, let's say, part of the project manager "basic survival kit", it's very very very common to see projects already running without having this exercise made. What is, in somehow really scary.

In this article I will show you what is a WBS, why to create one and how to create using practical examples from a FRP manufacturing project.

What is a WBS?

 First things, first. 

 A WBS or "Work Breakdown Structure" is the result of the exercise of decomposing the work scope of your project in smaller levels.

 The output of this, usually is a hierarchical chart (like in the picture bellow) and, depending of the complexity and size of project (an how much you want to decompose) it can be additionaly described using tables and text.

Why to create a WBS?

 The exercise of creating a WBS, when made with some persistence, especially when you have the help of all your team, will provide you a clear and organized understanding of which work compose the project you are managing.

Furthermore, when you are planning your project (or the next phase of your project) and, you have a well created WBS, it will provide you also a solid basis to estimate and track the effort and costs in your project.

How to Create a WBS

Ok. Now you know basically what and why. Let's go a little deeper on "what" and How.

The basic elements / levels of a WBS are the following (from top to the bottom):

1. Deliverables / Categories

2. Sub-Deliverables / Sub-Categories

3. Work Packages

4. Dictionary / Work Instruction

Deliverables

Below the project level (usually the top level), the deliverables / categories level is where you decompose your project in the deliverables / categories of work that it will have. 

So, let's suppose you have a huge industrial project in your hands that is expected to manufacture and deliver 100 VLT train cabins made in reinforced fiberglass.

At first moment, you can see the project only as "manufacture the 100 cabins", but, if you think a little more, you can easily see that you have several top deliveries / categories of work like:

• Project Planning

• Tooling and Molds

• Initial Operation Setup

• First Article Inspection

• Ramp-Up

• Production

• Logistics and Shipping

• Quality Control

• Project Tracking and Control

As you can see, it's basically the decomposition of the project work by category / product / deliveries and, some of these boxes could be even sub-projects, like the "Initial Operation Setup" that could deal with a new factory for the hosting the operation, depending on scenario.

Sub-Deliverables / Sub-Categories

This intermediate level, depends of the complexity / size of your project and, also, on your need of how much to go ahead in decomposition.

In other words, you can create this intermediate level, decompose it in several sub-levels or, even do not create the level, depending on your need.

So, following the former example, if we look speciffically at the "Production" deliverable/box, and considering that in this project we're going to use a manual FRP lamination process (one of the several ways to manufacture parts using FRP materials), we could decompose as following:

• Mold Preparation

• First Lamination

• Demolding

• Trimming and Sanding

• Isolation

• Second Lamination

• Assembly

• First Painting

• Surface Preparation

• Second Painting

• Curing

• Finishing

Work Packages

At this, that usually is the lowest level in the most of WBS's, you need to decompose the upper level in work packages, or in other words, in activities / tasks.

So, if you want to decompose the "Mold Preparation" box in tasks / activities, it could be as following:

• Check the mold pieces for damages

• Clean the mold pieces

• Mount the mould

• Apply releasing agent

• Apply gelcoat

Dictionary / Work Instruction

Depending on the complexity of the activities, you can decide to create dictionaries / work instructions for the work-packages of your WBS.

As the name already says, the purpose is to describe textually and using checklist the detailed work that must to be don in the tasks.

 So, for example, if you decide to create a detailed dictionay / work instruction for the item "mount the mold", it should document notes and photos of the pieces that compose the mold, the sequence of mounting and how they fit in each other. You could also create and document a checklist for the operators.

 Note that, in the case of a professional manufacturing project, these dictionaries could be converted in the body of the work instructions to be provided to the shopfloor technical team in order to have the work clearly shared.

Some Final Tips

Enumerated Items and colours

 If you are a creating medium to huge WBS, a good practice to enumerate all the items of your WBS to keep easily the track.

When possible it's also interesting to use different colours for different levels or categories to make it more easy for reading.

It usually follows like in the picture bellow.

Use a Good Specific Software

In order to make your life easier, instead of using a presentation software, like Microsoft Powerpoint (like I used for this post examples), I suggest you to use one of the two softwares bellow:

• Microsoft Visio

• WBS Chart Pro

The last one, can even convert your WBS into a Microsoft Project format schedule.

Conclusions

As I wrote in the beginning of this post, it's somehow scary to see so many projects running in really proffessional and amazing companies without having even a WBS documented.

In my opinion, sometimes it's due to the fear / anxiety that the inherent uncertainty causes especially in the beginning and initial planning phase of a project, and, of course, it's almost impossible to know in details the future and future work in the project, but, it's not excuse for putting aside this valuable exercise.

If it's your case, you can always choose to focus on the next project phase, decomposing it in details and, keeping a macro vision for the phases that are still far.

Finally, sometimes, you can find people that says, that we should do not insist so much in a cartesian approach and focus in a systemic / holistic view of things and connections. 

I agree that especially in face of the rising complexity we face in huge projects we should not only go ahead only with cartesian / decomposition techniques, but, also with techniques and exercises that can provide a systemic view of the project (connections and interdependences).

Anyway, for smaller and less complex projects, a simple use of a decomposition technique as the WBS can be really valuable, even, if you are running an agile project with scrum, for example.

If you appreciate the article, please share the knowledge to your network.

All the best.

Eduardo Levenfeld