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.docx64 KB WBS Structure - Solution.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 the 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:06 Let's talk now about a very practical and
- 00:08 useful skill planning technique called the work breakdown structure.
- 00:13 The project management body of knowledge to PMBOk guide to find the work breakdown
- 00:18 structure or WBS as a hierarchical decmposition of the total scope of work to
- 00:23 be carried out by the project team to accomplish the project objectives and
- 00:27 create the required deliverables.
- 00:30 What a mouthful.
- 00:32 What that means is that the WBS breaks all the project work down into pieces and
- 00:35 organizes those pieces into some logical fashion.
- 00:39 A key question is how to organize the work.
- 00:42 Well we could organize all the tasks alphabetically, but
- 00:45 that probably won't make the project any easier to manage.
- 00:49 Now a good WBS organizes the work based upon the project
- 00:52 management approach that's being used.
- 00:54 Another key question is, what is the size of a peace of work in the WBS?
- 00:59 This is a judgement call.
- 01:01 For now let's just say, that it's a bite size piece of work and
- 01:04 I'll discuss this more in a few minutes.
- 01:07 So by taking this pieces of project work and
- 01:09 organizing them in some logical manner,
- 01:12 we have a description of everything that must be done on the project.
- 01:16 You may recall that when we put the WBS into spreadsheet and add columns for
- 01:20 start and end dates and resource assignments, we call it a WBS dictionary.
- 01:26 Let's discuss how to organize a WBS.
- 01:28 The WBS should be organized in a manner that is consistent
- 01:32 with the project management methodology that is being used for the project.
- 01:35 In addition, I'd to use the WBS to focus in on areas of high risk,
- 01:40 by making those categories of WBS tasks.
- 01:43 What are some of the ways to organize the WBS?
- 01:46 An obvious way would be that you can organize it by the project objectives
- 01:50 found in the project charter.
- 01:52 Each objective is a WBS category and
- 01:54 all the task needed to complete that objective are in that category.
- 01:58 A very common approach is to organize the WBS by stages or
- 02:02 phases of your project based on your project management methodology.
- 02:06 A classic example of this would be for six sigma project.
- 02:10 You would have five phases, define, measure, analyse, improve and control.
- 02:15 Each of those would be a separate WBS category.
- 02:18 Many times in development projects I have organized the WBS
- 02:22 by major product components such as the hardware, the mechanical parts,
- 02:27 the software or the packaging.
- 02:30 Another approach is by a business process such as market research design and
- 02:35 development, procurement, testing, training.
- 02:38 An approach often use when control is very important is organize by functions or
- 02:43 departments.
- 02:45 Each of which have a project budget that they must manage.
- 02:49 And on large complex projects with activities in multiple locations.
- 02:53 I've often use the approach of organizing a WBS by geographic location.
- 02:58 So there's a category for the activity in Shanghai.
- 03:01 Another for Singapore, and yet another category for Chicago, and
- 03:05 a fourth for London.
- 03:06 This makes it easy for a site manager to manage their portion of the project.
- 03:11 Why do we care about all this?
- 03:13 Well, WBS automatically organizes project information both during planning and
- 03:17 during execution.
- 03:19 It consolidates information within categories and allows us to focus on
- 03:22 just one category or one snapshot of the project, without the need to get details
- 03:27 from all of the different project categories at the same time.
- 03:31 A well constructed WBS makes project management much easier and more accurate.
- 03:37 A poorly constructed WBS just add bureaucratic waste and
- 03:41 nonsense creating confusion.
- 03:43 So the bottom line is organize the project the way you intend it to run the project.
- 03:48 Don't take some WBS format you found online from some company in Seattle or
- 03:52 Bangkok.
- 03:53 They probably manage their company and
- 03:55 projects very differently from how you manage yours.
- 03:58 Recall that we also said,
- 03:59 we had a question of how much detail should be in the WBS?
- 04:03 I said I'd use bit size chunks of information.
- 04:06 Well how big a bit should you take at one time?
- 04:09 The answer to that question is it depends.
- 04:11 It depends upon how you answer several other questions.
- 04:15 Remember that I said the WBS helps us manage risk.
- 04:18 Well I go into more detail in the areas of high risk and
- 04:22 less detail in areas of low risk.
- 04:24 So let's say that the WBS detail is a level which the core team is managing
- 04:28 the project.
- 04:29 Some of the considerations would then be,
- 04:31 a core team member is actually managing that task.
- 04:34 There are estimates for that task, effort, duration and budget.
- 04:38 The relationship or dependencies between that task and other tasks are clear so
- 04:42 that the core team member understands any linkages.
- 04:46 The task deliverable and the definition of done is clear and
- 04:49 understood by all the core team members.
- 04:52 And the roles and responsibilities of court team members and
- 04:55 the other departments with respect to each task is clear.
- 04:58 Too much detail will create extra budget on the court team, and
- 05:02 add unnecessary complexity.
- 05:04 Breaking the project into a hundred of thousands micro-tasks,
- 05:07 just adds a lot of work which may make it harder to manage the project effectively.
- 05:12 But by the same token not enough detail will mask risks and high problems
- 05:16 until it's too late to fix them without a major impact to the project.
- 05:21 So the bottom line is that there is a judgment call based upon risk and
- 05:25 the areas of high risk.
- 05:27 Such as a core estimate or unclear deliverable, or confused rules and
- 05:31 responsibilities.
- 05:32 It requires more detail.
- 05:34 When there is low risk because the question here area easily answered,
- 05:38 less details required.
- 05:40 One other comment, on a small project, with only one or two people, and a dozen,
- 05:44 or so, tasks, you don't even need a WBS.
- 05:47 It's easy to keep track of what's happening on the project.
- 05:51 On a larger project, with hundreds of tasks, dozens of people involved,
- 05:56 a WBS is a critically important tool for a Project Manager, and a Core Team
- 06:00 to keep track of what is actually happening and identify and manage risk.
- 06:06 >> The work breakdown structures are great tool that helps both the project manager
- 06:10 and the core team to keep 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.