How to Create a Work Breakdown Structure: A WBS Masterclass

Summary

This video script outlines the creation of a Work Breakdown Structure (WBS), a critical project management tool. It emphasizes the global approach of breaking down projects into deliverables and identifying activities. The script details the hierarchical levels of WBS, from the project itself at level zero to sub-deliverables at level three and beyond. It stresses the importance of a systematic approach to ensure all project components are included. The script also discusses documenting the WBS, creating a WBS dictionary, and refining it with stakeholder feedback. It highlights the WBS's role in project planning, scheduling, resource allocation, risk management, and governance, making it a comprehensive tool for project success.

Takeaways

• 🛠 The Work Breakdown Structure (WBS) is a fundamental tool in project management, essential for projects of significant scale.
• 🌐 The common approach to creating a WBS is by breaking down the project into products or deliverables and then identifying the activities associated with them.
• 🔄 There are different approaches to WBS; in the UK, activities are broken down to determine products, while in the US, the focus is on deliverables first.
• 📈 A WBS is a hierarchical decomposition of all deliverables, ensuring nothing is missed in the project scope.
• 📍 Level zero of the WBS represents the entire project, while level one, known as the 'key line', sets up the categories for further breakdown.
• 🔑 Level two of the WBS includes major deliverables, utilizing expert knowledge to identify end and interim deliverables.
• 📚 Level three breaks down major deliverables into components and interim deliverables, which are necessary for reaching the end deliverables.
• 📝 The WBS should be documented with a clear index, and a WBS dictionary can be created for detailed descriptions and additional information.
• 🔍 It's crucial to present and refine the WBS with stakeholders for feedback, ensuring it accurately represents the project scope.
• 🔄 The WBS is adaptable and may evolve as a project progresses, with the potential to add or remove elements as new requirements are discovered.
• 🔗 The WBS serves as a foundational tool for planning, resource allocation, risk management, governance, communication, and quality management in project management.

Q & A

What is the primary purpose of a Work Breakdown Structure (WBS) in project management?

The primary purpose of a WBS is to decompose the project into smaller, manageable deliverables or components. This helps in planning, scheduling, and managing the project effectively by identifying all the necessary tasks and ensuring nothing is missed.

Why is it important to create a WBS for projects of significant scale?

Creating a WBS for projects of significant scale is important because it ensures that all the work required is systematically identified, organized, and defined. This helps in avoiding omissions and duplications, and it provides a clear roadmap for project execution.

What are the two different approaches to creating a WBS, as mentioned in the script?

The two different approaches to creating a WBS are: 1) Breaking down the work into activities and then determining the products or deliverables, which is more common in the UK, and 2) Breaking down the project into products or deliverables and then identifying the activities, which is the more common approach globally and often used in technical projects.

What is meant by 'deliverables' in the context of a WBS?

In the context of a WBS, 'deliverables' refer to the products, capabilities, or results that are tangible and can be experienced. These can be a thing, a process, or an event that the project aims to produce.

What is the significance of the 'key line' in a WBS?

The 'key line' in a WBS is the organizing principle that sets up the categories by which the deliverables are decomposed. It represents the major work streams or themes of the project and is crucial for structuring the WBS effectively.

Why is it essential to involve experts when identifying major deliverables at level two of the WBS?

Experts are essential in identifying major deliverables at level two because they possess the necessary knowledge and understanding of the project's requirements. Their input ensures that all critical end and interim deliverables are included in the WBS.

What are interim deliverables, and how do they differ from end deliverables?

Interim deliverables are products or outputs created during the project to help achieve the end deliverables. They are not the final products of the project but are necessary for its completion. End deliverables, on the other hand, are the final products or outcomes that the project aims to produce.

How should level three of the WBS be created?

Level three of the WBS should be created by brainstorming the sub-deliverables and interim deliverables for each item at level two. This involves breaking down the major deliverables into their components and identifying all the necessary interim deliverables.

What is the purpose of a WBS dictionary, and how does it differ from the WBS itself?

A WBS dictionary is a document that provides additional details for each item in the WBS, such as descriptions, standards, specifications, resources, costs, and durations. It differs from the WBS in that the WBS is a hierarchical decomposition of deliverables, while the dictionary offers a more detailed and comprehensive view of each deliverable.

How should the WBS be presented to stakeholders, and what is the purpose of this presentation?

The WBS should be presented to stakeholders for feedback and refinement before finalizing. This presentation allows stakeholders to understand the project scope, provide input, and ensure that all necessary work is accounted for, leading to a more accurate and agreed-upon project plan.

What are some good practices to follow when creating a WBS?

Good practices for creating a WBS include providing clear and unambiguous labels for each item, ensuring the WBS is mutually exclusive and collectively exhaustive, and being open to evolving the WBS as the project progresses to accommodate new requirements or changes in project understanding.