Locked lesson.
About this lesson
The Work Breakdown Structure (WBS) is the most commonly used technique for organizing the project scope. The WBS decomposes the scope into tasks and organizes the tasks into logical groupings.
Exercise files
Download this lesson’s related exercise files.
WBS Structure.docx.docx64 KB WBS Structure - Solution.docx.docx
143.8 KB
Quick reference
Work Breakdown Structure
The Work Breakdown Structure (WBS) is the most commonly used technique for organizing the project scope. The WBS decomposes the scope into tasks and organizes the tasks into logical groupings.
When to use
The WBS technique is very useful for large projects (in excess of 40 or 50 tasks). The WBS is created during project planning. The WBS is normally updated at the beginning of each phase or whenever there is a formal project change.
Instructions
The WBS is intuitively a very easy technique to understand. However, think carefully about your WBS structure. The structure will soon drive the creation of budget and schedule reports. The WBS structure can make communication planning and execution easier for the project management team or create extra complexity without adding value. The key is to create a structure that reflects the manner in which you intend to manage the project. If managing by phase, then create a phase structure; if by deliverables, then deliverables structure; if by department or function, then a department or function structure. The WBS can mix structures to reflect different management reporting and relationships at different times in the lifecycle of the project.
To actually create the tasks in the WBS, start with the Project Charter or scope statement. The scope deliverables are decomposed (see Deliverables Deployment) into tasks. The tasks are then placed in logical groupings. The WBS grouping can be determined first and tasks placed into them, or the tasks can be created and then grouped.
Another typical question is how much decomposition is required? What is the right level of detail? Again the answer is that the WBS should reflect how you intend to manage the project. Take it down to the detail at which the Core Team will be reporting. This may be different levels of detail for different parts of the project. My rule of thumb is that the higher the risk, the more detail I want in the WBS. Some of the criteria to help you select the proper level of detail for each task are:
- Level at which the task will be managed.
- Estimate for the task effort, duration, and budget can be set.
- Dependencies with other WBS tasks is clear.
- Definition of task deliverable exists.
- Definition of roles and responsibilities can be set.
Work Breakdown Structure (WBS): “A hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.” PMBOK® Guide
This definition is taken from the Glossary of the Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Sixth Edition, Project Management Institute, Inc., 2017.
Login to download- 00:04 Hi, I'm Ray Sheen.
- 00:05 Let's talk now about a very practical and
- 00:07 useful scope planning technique called the work breakdown structure.
- 00:12 The Project Management Body of Knowledge, the PMBOK Guide, defines work breakdown
- 00:17 structure, or WBS, as a hierarchical decomposition of the total scope of
- 00:21 work to be carried out by the project team to accomplish the project objectives and
- 00:26 create the required deliverables.
- 00:28 What a mouthful.
- 00:29 What that means is that the WBS breaks out all the project work into pieces and
- 00:34 organizes those pieces in some logical fashion.
- 00:37 A key question is how to organize the work.
- 00:41 Well, we could organize all the tasks alphabetically, but
- 00:44 that probably won't make the project easier to manage.
- 00:48 Now, a good WBS organizes the work based upon the project management
- 00:52 approach that is being used.
- 00:54 Another key question is, what is the size of a piece of work in the WBS?
- 00:58 This is a judgment call.
- 01:01 For now, let's just say that it is bite-size piece of work,
- 01:04 and I'll discuss that more in a few minutes.
- 01:06 So we will be taking all of these pieces of work and
- 01:09 organizing them in some logical manager to create a picture of everything that must
- 01:13 be done on the project.
- 01:14 It captures the full scope of the project.
- 01:17 The WBS is associated with traditional projects.
- 01:20 It's equivalent in the Agile Scrum world is the product backlog.
- 01:23 Let's discuss how to organize a WBS.
- 01:27 The WBS should be organized in a manner that is consistent with
- 01:30 the project management methodology that is being used on the project.
- 01:34 In addition, I like to focus the WBS on the areas of high risk by making those
- 01:39 categories of WBS tasks.
- 01:40 What are some of the ways to organize the WBS?
- 01:46 An obvious way that you could organize them is by project objectives found in
- 01:50 the project charter.
- 01:51 Each objective is a WBS category and
- 01:53 all tasks needed to complete that objective are in that category.
- 01:58 A very common approach is to organize the WBS by stages or phases of your project.
- 02:03 A classic example of this would be a six sigma project.
- 02:07 They would have five stages, define, measure, analyze, improve, and control.
- 02:12 Each of those would be a separate WBS category.
- 02:16 Many times on development projects, I've organized the WBS by major components
- 02:21 that were being developed such as hardware, electronics and the software.
- 02:26 Another approach is by business process such as market research,
- 02:30 design development, procurement, testing, training.
- 02:33 An approach often used when cost control is very important is
- 02:37 organizing by function or department,
- 02:40 each of which would have a project budget that they must manage.
- 02:45 On large, complex projects with activity in multiple locations,
- 02:49 I've often used the approach of organizing the WBS by geographic location.
- 02:54 So there's a category for the activity in Shanghai, another category for
- 02:58 Singapore, another category for Chicago, and a fourth category for London.
- 03:02 That makes it easy for a site manager to manage their portion of the project.
- 03:07 Why do we care about all this?
- 03:09 The WBS automatically organizes project information both during planning and
- 03:14 during execution.
- 03:16 It consolidates the information within categories and
- 03:19 allows us to focus on just one category without the need to get details from all
- 03:24 of the project categories.
- 03:25 A well constructed WBS makes project management easier and more accurate.
- 03:30 A poorly constructed WBS adds bureaucracy and creates confusion.
- 03:35 So the bottom line is organize it the way you intend to run the project.
- 03:40 Don't take some WBS you found online from a company in Seattle or Bangkok.
- 03:44 They probably manage their companies and
- 03:47 projects differently than you manage yours.
- 03:50 Recall that we also had the question of how much detail should be in the WBS.
- 03:55 I said use bite sized chunks of information.
- 03:57 Well, how big a bite should you take at one time?
- 04:00 The answer to that question depends upon how you answer several other questions.
- 04:06 Remember I said that the WBS helps us to manage risk.
- 04:09 Well, I go into more detail in the areas of high risk and
- 04:13 less detail in the areas of low risk.
- 04:15 So let's say that the detail is the level at which the core team is
- 04:19 managing the project.
- 04:21 Some of the considerations then would be, one,
- 04:24 a core team members managing the task.
- 04:26 Two, there are estimates for the task, effort, duration and budget.
- 04:30 Three, the relationship or dependencies between the task and
- 04:34 other tasks are clear so the core team members understand any linkages.
- 04:38 Four, the task deliverable, the definition of done, is clear and
- 04:42 understood by all core team members.
- 04:44 And five, the roles and responsibilities of core team members and
- 04:48 their departments with respect to each task is also clear.
- 04:52 Too much detail creates an extra burden on the core team and
- 04:56 adds unnecessary complexity.
- 04:59 Breaking the project into hundreds or thousands of micro tasks just adds a lot
- 05:03 of work which may make it harder to manage the project effectively.
- 05:08 But not enough detail will mask risks and hide problems until it's too late
- 05:12 to fix them without a major impact for the project.
- 05:16 So, the bottom line is a judgment call based upon risk.
- 05:19 In the areas of high risk, such as a poor estimate, an unclear deliverable,
- 05:24 or confused roles and responsibilities, it requires more detail.
- 05:28 When there is low risk because the questions here are easily answered,
- 05:32 less detail is required.
- 05:34 One other comment, on a small project with only one or two people and
- 05:38 just a handful of tasks, you don't need a WBS.
- 05:41 It's easy to track what is happening.
- 05:44 On a large project with hundreds of tasks and dozens of people,
- 05:48 a WBS is critically important as a tool for project management and the core
- 05:53 team to keep track of what is happening in identifying and managing risk.
- 05:58 The work breakdown structure is a great tool that help
- 06:03 both the project manager and the core team to keep
- 06:08 track of all the work on large complex projects.
Lesson notes are only available for subscribers.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.