Work Breakdown Structure Made Easy
"Would you please help me print out this Work Breakdown Structure? It won't fit to one page, and I have a project status meeting with the project sponsor in a few minutes!" A colleague of mine approached me and asked. "This is a project schedule in the form of a hierarchical structure." I replied sarcastically when I saw her drawing on the screen. She had listed all project deliverables then decomposed each one into relevant tasks. This is not what a Work Breakdown Structure (WBS) is intended to be used for. Does the project sponsor or the client need to know how you are going to complete each deliverable? Do you really need to present scores of deliverables and tasks to get your sponsor to agree on your project scope? Absolutely not.
The Work Breakdown Structure is a deliverable-oriented, hierarchical decomposition of the work to be completed by the project team. It is a Tree Diagram in which the project is broken down into deliverables and sub-deliverables needed to accomplish the project objectives. It looks like the organisational structure of a company or a family tree.
This project management tool defines the project's scope, and it must be simple in order to reap the intended benefits. Firstly, it depicts the boundaries of the project scope. If it is well-structured and includes nothing but the project deliverables, the client or the sponsor can easily sign it off. Secondly, it ensures that effort is not wasted on unnecessary or out-of-scope deliverables. That is, if redundant components are listed, extra resources, time and cost will be required. Finally, it can be used as a dashboard to communicate scope changes, hence prevents scope creep. The more complicated the Work Breakdown Structure is, the less likely you will achieve these objectives.
The intended use of this tool makes it different from the project schedule. The Work Breakdown Structure does not include activities; it only lists deliverables down to the Work Package level, whereas the project schedule lists all tasks required to complete the deliverables.
From another perspective, the hierarchical decomposition of work depicts the life cycle through which the project evolves from inception to completion. In a software development project, for instance, the project life cycle may consist of the following major phases:
- 1.1 Analysis
- 1.2 Design
- 1.3 Construction
- 1.4 Testing
- 1.5 Rollout
Each one of the phases can be broken down into its main deliverables. For example, the Analysis phase may be decomposed into 'Glossary' and 'Requirements Specifications'. Each deliverable is then decomposed into sub-deliverables, and so on. The Analysis phase can be broken down as shown in the following structure:
- 1.1 Analysis
- 1.1.1 Glossary
- 1.1.2 Requirements Specifications
- 126.96.36.199 Use Cases
- 188.8.131.52 Supplementary Specifications
- 184.108.40.206 Reporting Requirements
The decomposition process should stop when you reach the smallest manageable components of the project work, called Work Packages. A Work Package is the lowest-level component whose cost and time can be reliably estimated. For example, 'Reporting Requirements' sub-deliverable can be broken down into two work packages: 'Financial Reports' and 'Operational Reports', each of which can be estimated in terms of cost and time required to complete their development.
It is worth mentioning that the project management deliverables are part of the project work, therefore, they should be listed in the structure as well. One way to incorporate these deliverables is by creating a separate phase, named Project Management, and decomposing it into its components. Examples of deliverables that can be listed under this phase are Project Management Plan, Risk Plan, Scope Statement and Project Schedule.
Although the Work Breakdown Structure is progressively elaborated, i.e. built in increments as the project progresses, the project manager should make sure that it is complete. Completeness is achieved when 100% of the agreed scope is covered. You can check completeness bottom-up; that is, sub-deliverables make up 100% of their parent deliverable, deliverables make up 100% of their parent phase, and phases constitute 100% of the project scope.
Only after the decomposition process has been completed and approved, the project schedule is created. For each work package, the project team members list the tasks required to complete the package. Then, time, dependencies, resources and cost are allocated to each task. When all details have been estimated, the project schedule is approved and the schedule baseline is set.
In conclusion, the Work Breakdown Structure is an essential tool to set the project scope. It forms the agreement between you and your client on what is included and what is not included in your end deliverable. However, to be effective, it must be simple and, more importantly, must not be confused with the project schedule that serves a different purpose in your project management plan.
Mohammed K Barakat is an Industrial Engineer who worked in diverse industries; air conditioning, steel manufacturing, ERP solutions, and logistics and supply chain. He is a Certified Project Management Professional, Six Sigma Black Belt, Six Sigma Green Belt, Microsoft Certified Trainer, and Microsoft Certified Technology Specialist. For more information, you can visit his LinkedIn profile at:
Creating a Work Breakdown Structure (WBS)
If the Six Sigma project you are implementing is huge how can you get it done in a reasonable timeframe? A Work Breakdown Structure (WBS) can help and here's how.
Work Breakdown Structure: Purpose, Process and Pitfalls
Creating a Work Breakdown Structure (WBS) requires a substantial amount of energy, time and people, but in the end is not rocket science.
Project Planning a Step by Step Guide
This project planning article provides a step by step approach to creating a simple and effective project plan at the beginning of a project.
Planning a Project Using a Work Breakdown Structure & Logic Network
How to create a well thought out, detailed project plan using a Work Breakdown Structure and Logic Network while building a committed high performing team.
Common Cost Management Mistakes:
- Not understanding what is involved to complete an item of work.
- Starting with an amount of money and making the project cost fit it.
- Assigning people at more than 80% utilisation.
- Failing to build in contingency.
- Providing estimates under pressure in project meetings.
Discover our forum where you can ask questions, get advice from other people and share your experience.