CompTIA Project+ PK0-003

Create WBS and WBS Dictionary

by Steve Caseley

Start your 7-day free trial today.

This video is only available to subscribers.

A free trial includes:

  • Unlimited 24/7 access to our entire IT training video library.
  • Ability to train on the go with our mobile website and iOS/Android apps.
  • Note-taking, bookmarking, speed control, and closed captioning features.

What is Project Management

Project+ and how to prepare for the exam

Pre-Project Setup

Project Planning

Prepare Scope Statement

Create WBS and WBS Dictionary

00:00:00 - Continuing on our 2.0 project planning road map, this nugget
00:00:04 - is 2.2 Create WBS and
00:00:08 - WBS Dictionary. Again I have shortened it for brevity for this
00:00:11 - forum, the official name from CompTIA is 2.2
00:00:16 - Use a work breakdown structure, WBS, and
00:00:21 - WBS dictionary to organize project planning. So let's get into
00:00:24 - this nugget and see what a WBS and a WBS dictionary is all about. This
00:00:30 - nugget, as I said, is focused on creating the WBS, the Work Breakdown
00:00:34 - Structure. Consistent with the fact that this nugget comes immediately
00:00:38 - after defining the scope, creating of the WBS is the next logical
00:00:44 - step in project planning because documenting the work, the WBS,
00:00:50 - is absolutely based on the scope. We want to identify all the
00:00:55 - work required to produce all of the deliverables that we defined
00:01:03 - in the scope statement. So effectively we started with the scope
00:01:09 - that was a primary building block for Project Management. We're
00:01:12 - going to take that scope statement in the WBS, we're going to
00:01:18 - identify all of the work that's required
00:01:22 - to achieve, to satisfy the scope, i.e. identify all of the work
00:01:28 - that's required to produce the deliverables that are part of
00:01:31 - the scope definition and that then is going to be our next step
00:01:36 - in the building block for the other Project Management planning
00:01:40 - activities, i.e. the creation of the schedule, the identification
00:01:44 - of the resources, the development of the project budget. It's
00:01:49 - all going to build from the WBS. Why? I repeat myself because
00:01:55 - the WBS identifies all of the work and once we have all of the
00:01:58 - work defined then we can identify the resources,
00:02:04 - the schedule,
00:02:06 - the budget,
00:02:10 - etc. etc. which are the other nuggets in this 2.0 series.
00:02:16 - Once we have the WBS fully defined it is the most detailed view
00:02:21 - of the project. Again, it identifies all of the work,
00:02:27 - every single work package that is required to satisfy the scope,
00:02:34 - to produce the deliverables that the scope definition defined
00:02:38 - are going to be contained ion our WBS, our Work Breakdown Structure,
00:02:43 - because it identifies the work, all of the work, and only the
00:02:47 - work required to satisfy the scope statement. So again let's
00:02:54 - talk about what the WBS and how to create the WBS. So
00:03:00 - I think the first critical step is making sure we have a common
00:03:03 - definition of what is a WBS. It's easy to say it identifies all
00:03:07 - of the work
00:03:11 - and only the work.
00:03:14 - What does that mean? How do we identify all of the work? Have
00:03:17 - we written a 15-page prose that defines all of the work? No.
00:03:23 - A WBS is very much a structured
00:03:27 - definition of the work,
00:03:33 - i.e. the word S in the work breakdown structure. It is a structured
00:03:39 - definition of the work. WBSs are typically done in one of two
00:03:44 - ways. One is I'm going to describe it as an ordered list.
00:03:50 - At a high level the WBS consists of a single line that says this
00:03:54 - is my project. The high level then breaks down into major components
00:04:00 - major component number 1, major component number 2, major component
00:04:04 - 3, 4, 5 through a very large number. Major components are going
00:04:09 - to break down into sub-components sub-component 1, sub-component
00:04:14 - 1.2, sub-component 2.1 and so on and again we're going to have
00:04:18 - many major components. we're going to have many sub-components,
00:04:21 - and then we're going to break it down
00:04:24 - to the task level
00:04:27 - 2.2.1, 2.1.1,
00:04:31 - 2.1.2 and I am creating this as a hierarchy.
00:04:38 - These naming conventions are not critical to WBS but it certainly
00:04:43 - again is in keeping with our definition of the structured and
00:04:47 - it's defining the relationship that this task has with the sub-component,
00:04:54 - the major component as part of our WBS. Now for the purpose of
00:04:59 - this demonstration I have put together my WBS as three levels
00:05:03 - only with the major component, component and task. There is no
00:05:09 - rule defining
00:05:13 - how many levels a WBS has. I would suggest most projects will
00:05:18 - have a minimum of three levels but it would be not out of the
00:05:22 - question to have 5 to 10 levels
00:05:26 - of decomposition
00:05:29 - in your work breakdown structure. How far you go with your decomposition
00:05:34 - we're going to discuss this later in this nugget. We're going
00:05:37 - to give you some tips and hints to know when you're done decomposing
00:05:41 - your work breakdown structure but the work breakdown structure
00:05:44 - again is a structured layout identifying all of the work in terms
00:05:48 - of major component components, all of the work within this task
00:05:53 - group should be focused purely on satisfying
00:05:57 - the requirement to complete the work for this component, and
00:06:01 - all of these components should be satisfied exclusively on satisfying
00:06:06 - the requirements of the major component, i.e. there is a true
00:06:10 - owner-subordinate relationship
00:06:13 - within our hierarchy of our WBS. Another
00:06:18 - way of describing or defining the WBS is in a tree structure
00:06:24 - so I have exactly the same definition here, my project has my
00:06:28 - major components, my major components break down into sub-components,
00:06:32 - and my sub-components break down into tasks, and again this is
00:06:37 - three levels,
00:06:40 - the number of levels is going to be based on the complexity of
00:06:44 - the size of your overall project. Although
00:06:49 - I've kind of already described how to create the WBS it is a
00:06:54 - structured decomposition I would like to spend just a few minutes
00:06:58 - to discuss the formalities of how to create a good WBS. We've
00:07:04 - already described, defined that the WBS starts with the definition
00:07:09 - of the scope and we need to identify all of the word sorry for
00:07:13 - repeating myself
00:07:16 - required to satisfy that scope and only the work
00:07:23 - required to satisfy the scope. The
00:07:27 - main method for doing that is we start with the definition of
00:07:31 - the major deliverables.
00:07:33 - I would suggest the major deliverables are already defined in
00:07:36 - the scope
00:07:41 - and as we discussed in the scope nugget the major deliverables
00:07:46 - should be defined with the table of contents
00:07:49 - and the table of contents is probably going to be annotated to
00:07:52 - give us a very good understanding of what the work
00:07:58 - again when we described the scope we described the scope with
00:08:02 - the annotation to make sure that the business understood the
00:08:06 - content of that table of contents section but by describing the
00:08:10 - content of that table of contents section we are also defining
00:08:15 - all of the work I know I'm a broken record required to satisfy
00:08:20 - that deliverable.
00:08:23 - We then take our major deliverables with the table of contents
00:08:27 - and we validate that we can work directly from that table of
00:08:31 - contents or potentially we need to define minor deliverables
00:08:36 - or working documents
00:08:42 - to allow us to achieve the production of the major deliverables.
00:08:46 - So again we had the table of contents that says analysis
00:08:54 - of the existing system.
00:09:01 - Do we have minor deliverables associated with the work required
00:09:05 - to do the analysis of the existing system? Do we need to document
00:09:11 - the current
00:09:16 - review? Do we need to document
00:09:21 - the backlog
00:09:24 - report? Do we need to document
00:09:29 - minutes of meetings? Are there minor deliverables and sometimes
00:09:37 - the minor deliverables are only working documents that your team
00:09:40 - is going to produce that's going to be required to allow you
00:09:43 - to produce the deliverables that are required to satisfy the
00:09:48 - scope? The common term
00:09:54 - is decomposition.
00:09:57 - We start with the scope, we decompose the major deliverables.
00:10:01 - We decompose the major deliverables into minor deliverables.
00:10:04 - We decompose the minor deliverables into working documents. We
00:10:08 - may even need to do another level of decomposition to identify
00:10:12 - the work packages.
00:10:14 - For example, document the minutes
00:10:23 - if we have to interview
00:10:28 - 15 business users
00:10:32 - as part of analysis of the existing system I would suggest
00:10:39 - you need to identify additional work packages above and beyond
00:10:43 - documenting the minutes of 15 business users. The work package
00:10:48 - would say interview
00:10:52 - business user 1.
00:10:55 - The next work package would be interview
00:11:02 - business user 2 and so on.
00:11:07 - Now you may even want to decompose a little further than that
00:11:10 - where interview business user 1 has a decomposition of conduct
00:11:17 - interview, create minutes,
00:11:23 - and validate minutes.
00:11:27 - That probably is too far a level of decomposition and again in
00:11:33 - my tips and hints I'll give you some ideas of when it's time
00:11:36 - to stop decomposing
00:11:39 - but the goal is you start with the scope, you define the deliverables,
00:11:45 - you find the minor deliverables, you define the working documents
00:11:49 - required to get the work done, and then you may need to do further
00:11:55 - decomposition into the work packages
00:11:58 - to allow you to identify all of the work required to complete
00:12:04 - the scope. I was going to say and that's all there is to creating
00:12:10 - a WBS.
00:12:12 - This is
00:12:15 - the process for creating a WBS. This is a lot
00:12:21 - of work.
00:12:23 - In your scope statement you may have had 8 to 10 major deliverables.
00:12:30 - Each of those major deliverables has a
00:12:34 - TOC with 10 to 15 chapters.
00:12:41 - To create each of those 10 to 15 chapters you may have another
00:12:46 - 5 to 10 minor deliverables with additional work packages associated
00:12:50 - with that. So having 8 to 10 major deliverables it's not inconceivable
00:12:57 - to have 250
00:13:00 - to 500
00:13:02 - work packages,
00:13:04 - these guys,
00:13:06 - that are going to be required to identify all of the work and
00:13:10 - only the work required to produce those 8 to 10 major deliverables.
00:13:15 - This is the process,
00:13:18 - the process in and of itself is straightforward and simple, but
00:13:22 - don't be lulled into a false sense of security by how simple
00:13:25 - the process is there's a lot of work to decompose the scope to
00:13:31 - the major deliverables to the minor deliverables to the work
00:13:34 - packages but that's what creating an effective WBS is. So
00:13:40 - we're busy decomposing
00:13:42 - our WBS to the work packages,
00:13:45 - the key is as I just said is knowing when to stop.
00:13:49 - Well the simplistic answer is you stop decomposing when you know
00:13:54 - you've identified all of the work that's required to produce
00:13:58 - all of the deliverables. But that's kind of a self
00:14:03 - fulfilling I don't want to use the word self evident because
00:14:06 - I don't think it is self evident at all but we want to stop creating
00:14:11 - the work packages when we have identified all of the work that
00:14:14 - s required to produce the deliverables. And again we do this
00:14:17 - through the thing called decomposition.
00:14:24 - The key to stopping decomposition is this next statement that
00:14:28 - says all of the work is assigned or probably the better word
00:14:32 - is assignable.
00:14:37 - So how do we know when work is assigned or assignable? Well when
00:14:43 - we get to the point where we have identified a specific skill
00:14:47 - and/or a specific resource to do the work so we know that a
00:14:54 - BA will be the person required to conduct
00:14:58 - the interview.
00:15:02 - We know that a technical architect is the person that's going
00:15:06 - to be required to review
00:15:09 - the existing doc.
00:15:15 - The goal with decomposition
00:15:18 - is to get it to the point where we have identified a specific
00:15:21 - skill, specific resource to complete the task, i.e. it's assignable
00:15:30 - to a single
00:15:33 - resource. Now at this point in time it's assignable to a specific
00:15:38 - skill but we want to get our WBS
00:15:43 - decomposed where a single resource is assigned to a single
00:15:52 - task. This creates ownership,
00:15:58 - this assigns responsibility,
00:16:04 - and we need to get the WBS assigned to a single resource to ensure
00:16:11 - that resource understands that they are the owner of producing,
00:16:16 - completing that work package and that they are responsible. There's
00:16:20 - no saying "Oh, I thought my peer, I thought somebody else was
00:16:24 - doing this." Well no,
00:16:26 - it's assigned to you, you have the ownership, you have the responsibility.
00:16:31 - Now that can still be a very large task conduct interviews. We
00:16:37 - know we have 15 business units that need to be interviewed so
00:16:42 - I would suggest were' not done decomposing yet because we need
00:16:47 - to get it to the point that it's estimatable and measurable.
00:16:51 - If we have 15 interviews
00:16:57 - is it estimatable? Well you might say it is because each interview
00:17:03 - is going to take two hours, picking a number out of the air,
00:17:07 - therefore it's going to take 30 hours to do the job. and that
00:17:12 - could be a true statement but if we expect these interviews to
00:17:17 - be at varying levels of complexity we're going to have senior
00:17:20 - interviews for senior management interviews
00:17:26 - and we know senior management time is very hard to get and we
00:17:30 - figure at best we're going to get 30 minutes
00:17:33 - to do those interviews.
00:17:36 - Then we're going to do middle managers
00:17:41 - and they have a more detailed understanding of the system and
00:17:44 - those interviews may in fact take two hours. And then we're going
00:17:48 - to do line
00:17:50 - workers and with the line workers we're going to literally shadow
00:17:56 - them doing their job and for the line workers it may take four
00:18:00 - hours to complete the interview. So the key with taking the WBS
00:18:06 - decomposition to the point that it's estimatable is do I have
00:18:10 - enough information about the work package to be able to assign
00:18:17 - a meaningful, realistic,
00:18:20 - and measurable estimate.
00:18:26 - Thirty minutes for a senior executive, two hours for middle manager,
00:18:31 - four hours for a line worker I believe satisfies all of those
00:18:35 - criteria it's estimatable and it's measurable.
00:18:39 - If we had taken it at the high level of 15 interview 30 hours
00:18:45 - is it estimatable? Well not really because that's a bit of a
00:18:49 - guess that on average interviews you're going to take two hours,
00:18:53 - realizing that we have a very wide range of time frame, and it's
00:18:57 - probably not measurable. If we simply have this huge bucket of
00:19:01 - 30 hours
00:19:03 - for 15 interviews
00:19:07 - and our business analyst goes off and conducts the first three
00:19:13 - interviews and the first three interviews are all line levels
00:19:23 - and takes 12 hours. Remember
00:19:27 - a line level interview is going to take four hours, it takes
00:19:29 - 12 hours that business analyst is going to come back to us in
00:19:34 - a panic or at least I hope that analyst is going to come back
00:19:37 - to us in a panic and says "Steve, I've only done three interviews
00:19:42 - and I've already used up 12 of your 30 hours. At this rate I'm
00:19:46 - not going to get through all 15"
00:19:49 - that means we're satisfying our measurable criteria because we
00:19:55 - are achieving what we probably expect but our measurement, our
00:20:00 - evaluation, our project control activities are not going to be
00:20:05 - realistic. Or alternatively they didn't do the line level, they
00:20:10 - did the senior executives first, they completed the first three
00:20:14 - interviews, and they're done in two hours and again they're going
00:20:18 - to come back to you and "Steve, I think there's something wrong
00:20:20 - with this estimate. I've done three interviews, it's only taken
00:20:24 - me a total of two hours to get them all done, and I think I'm
00:20:27 - going to be done in 10 hours or whatever." So again I don't believe
00:20:31 - that satisfies our measurable activity or measurable criteria.
00:20:36 - Now the last statement on decomposition, when to stop, is
00:20:44 - we've got the interviews down, we're doing 30 minutes for the
00:20:47 - executives, two hours for the middle, and four hours for the
00:20:51 - line managers and as I discussed a minute ago do we need to further
00:20:55 - decompose that to conduct
00:20:59 - interview, document
00:21:03 - minutes, and
00:21:08 - obtain approval?
00:21:15 - If we took that 30 minutes
00:21:18 - and said 10 minutes is going to be for the interview or let's
00:21:22 - say 15 minutes for the interview, 10 minutes for the documentation,
00:21:26 - and five minutes for the obtaining of the approval it still satisfies
00:21:31 - the estimatable and the measurable and the same thing if we go
00:21:34 - in the middle management and say one hour for the interview,
00:21:37 - 30 minutes and so on, and yes it satisfies all the criteria but
00:21:43 - are we getting too specific,
00:21:52 - too controlling,
00:21:57 - too much detail
00:22:01 - and I'm deliberately using these words because I believe that's
00:22:05 - true in all of those instances. If we take it down to that level
00:22:09 - of granularity we are not giving our team members the ability
00:22:14 - to think of themselves. We probably need to tell the team members
00:22:18 - as part of conducting interviews I expect you to do the interviews,
00:22:21 - I expect you to get validation of the minutes. But we don't need
00:22:26 - to take the WBS down to the level and assign the estimates, we're
00:22:30 - simply too granular. We stop
00:22:35 - when we have all of the deliverables produced, all of the work
00:22:38 - is assigned to a specific resource at the level that's estimatable
00:22:42 - and measurable
00:22:44 - and I believe we achieved that here, that we do not need to go
00:22:49 - here. Knowing when to stop, taking our WBS to three levels,
00:22:58 - five levels,
00:23:00 - ten levels whatever it's going to be is going to again the key
00:23:04 - to stopping is we're estimatable
00:23:07 - and it's measurable and it's realistic. So
00:23:12 - we've really been through the complete process for creating a
00:23:15 - WBS scope, deliverables, decomposition, work packages, assignable,
00:23:21 - and measurable
00:23:23 - but how do we take from the deliverables
00:23:30 - to the work packages?
00:23:33 - How do we know that we need to analyze the existing doc? How
00:23:39 - do we know that we need to conduct
00:23:43 - interviews? Well one of the best ways to work through and identify
00:23:50 - all of the appropriate work packages required to produce your
00:23:53 - deliverables is to use existing guidelines. Something has happened
00:23:59 - before, someone somewhere has done something
00:24:06 - similar. Maybe there were previous projects that you have worked
00:24:12 - on, maybe there were previous projects that some other project
00:24:15 - manager in your organization has worked on but find something
00:24:19 - similar and reuse. Yes the deliverables may be slightly different,
00:24:25 - yes the end result for a deliverable for a warehousing system
00:24:30 - is going to be very different than the deliverables for a human
00:24:35 - resources system but the analyzing of the existing system, the
00:24:39 - conducting of the interviews, the various steps in the work packages
00:24:43 - should be very similar independent of the actual content in the
00:24:48 - deliverables. Find templates, buy a book,
00:24:55 - browse the web
00:24:58 - if there's nothing in your organization that looks at all like
00:25:02 - you've done there are thousands,
00:25:05 - hundreds of thousands of models out there, excellent textbooks,
00:25:10 - these things called methodologies,
00:25:15 - define the proven steps
00:25:19 - to successfully complete deliverables, to do analysis,
00:25:26 - design, etc.
00:25:31 - These methodologies could be described as industry guidelines
00:25:35 - but don't
00:25:38 - start from a blank page
00:25:44 - to do your work package decomposition, find something somewhere
00:25:49 - that's similar
00:25:51 - which is basically using analogies.
00:25:54 - What has been done? What can I reuse that looks something like
00:25:59 - this before? Now
00:26:02 - a couple more tips and hints I'm going to give you in developing
00:26:05 - a work breakdown structure. Some people prefer to do the work
00:26:09 - breakdown structure top down, others prefer to do it bottom up.
00:26:14 - I personally am a top down person and really the process that
00:26:18 - I've described is very much top down. We take the scope
00:26:24 - to the deliverables, to the sub-deliverables, to the work packages
00:26:29 - that's the top down. Scope is my project and I've done a top
00:26:35 - down decomposition.
00:26:37 - Bottom up works when you truly don't have a solid definition
00:26:43 - of scope and you start with
00:26:46 - something similar here are all of the work packages that are
00:26:51 - required, here's everything
00:26:55 - I think I need to do.
00:27:00 - Take all of your work packages, organize them into your sub-deliverables,
00:27:05 - organize your sub-deliverables into the deliverables and form
00:27:08 - the deliverables you can come up with the scope statement. Again
00:27:11 - I personally find top down to be my
00:27:14 - preferred way to work but I have worked with project managers
00:27:18 - who seem to be very successful starting with the "Here's everything
00:27:22 - that ever has to be done to get a project done." Identify the
00:27:26 - right pieces for their project and then organizing it upwards
00:27:29 - into the tree structure. And when you're developing a WBS identify
00:27:35 - the milestones what
00:27:37 - key events
00:27:41 - does the business
00:27:47 - care about?
00:27:51 - A milestone is not a work package, a milestone is the result
00:27:59 - of completing work packages
00:28:02 - and these are key events the business cares about, if you identify
00:28:06 - the milestones, build them into your WBS it makes status reporting
00:28:10 - as part of project delivery far easier and simpler for us to
00:28:14 - do. So this is really a let's get the job done faster when we're
00:28:19 - in delivery by identifying the milestones as part of our WBS
00:28:24 - and often the milestones can be directly related to the deliverables
00:28:28 - but if the deliverables are large you may need to have independent
00:28:33 - milestones potentially associated with your sub-deliverables. And
00:28:38 - a few more tips and hints to help you prepare an effective WBS
00:28:43 - involve anyone you can think of that's going to help you develop
00:28:47 - good solid realistic work packages. Involve the team, talk to
00:28:52 - the business, consult experts
00:28:57 - ask for help.
00:29:02 - Developing a good WBS is not something a project manager should
00:29:06 - undertake on their own. You need to talk to the team, the team
00:29:11 - is the people that are going to be producing the work packages,
00:29:15 - producing the deliverables rather, ask them what work packages
00:29:18 - they think they need to work on to produce the deliverables.
00:29:22 - Ask the business what work they think needs to be done, consult
00:29:26 - the experts.
00:29:28 - Take all of these
00:29:32 - and create sticky notes, put it on a whiteboard, do a workshop.
00:29:38 - Here's everything
00:29:42 - we thought of from asking all of these people what makes sense,
00:29:49 - use the sticky notes,
00:29:54 - and organize
00:29:57 - into the structure. Or
00:30:02 - alternatively complete your WBS one layer at a time. Have we
00:30:07 - identified all of the deliverables?
00:30:11 - Okay, if I complete every one of these deliverables I will satisfy
00:30:16 - the business requirements, I will satisfy the scope. When you
00:30:19 - can confidently say "I have absolutely identified all of the
00:30:24 - deliverables" then you pick one deliverable
00:30:29 - and say "What
00:30:32 - sub-deliverables do I need to complete that deliverable?"
00:30:37 - You consult the team and when you can confidently say that "When
00:30:41 - I produce every one of these sub-deliverables I will satisfy
00:30:44 - the deliverable" then you go on and say "Okay, what's the next
00:30:49 - deliverable?" and
00:30:52 - you complete that layer. And then again what are all of the work
00:30:56 - packages required to complete the sub-deliverables.
00:31:00 - Complete one layer at a time and the key is "Have
00:31:08 - I identified
00:31:12 - everything to satisfy
00:31:19 - the parent?"
00:31:22 - And when you can absolutely answer that question with confidence
00:31:25 - I have identified everything to satisfy the deliverable it's
00:31:29 - time to move on. When you're creating the WBS don't worry about
00:31:34 - the estimates. Yes, I talked about the fact that the executive
00:31:40 - estimate for the interview is going to be four hours and the
00:31:43 - middle manager sorry it was going to be 30 minutes and the middle
00:31:47 - manager was four hours and so on if you know it fine but if you
00:31:54 - don't have the detailed estimate simply ask the question "Can
00:31:59 - I later on develop a realistic estimate, a measurable estimate
00:32:04 - for this particular WBS work package?" And if you are confident
00:32:08 - that you can develop a realistic measurable estimate you're done,
00:32:12 - you don't need to estimate at this time, we're going to do our
00:32:15 - estimating in a future nugget as part of planning for schedule
00:32:19 - and development, we want to focus on identifying all of the work
00:32:23 - packages. Don't get hung up, I'm trying to do the estimating,
00:32:27 - do one thing at a time almost the same as completing one layer
00:32:31 - at a time, don't worry about the estimating, don't worry about
00:32:34 - the sequencing, we're going to do that when we develop the schedule.
00:32:40 - We want to focus on the WBS and the work packages.
00:32:46 - The estimates and the sequences come later. With
00:32:51 - the WBS fully defined we need to spend just a moment or two discussing
00:32:55 - what the WBS dictionary is. the WBS dictionary is simply the
00:33:00 - documentation of the,
00:33:07 - for the
00:33:09 - WBS itself,
00:33:11 - the work breakdown structure. The WBS dictionary is going to
00:33:15 - identify every element in
00:33:19 - the WBS, it's
00:33:22 - going to define
00:33:25 - the content of the work package,
00:33:32 - and it does that by defining each work package is going to produce
00:33:38 - a deliverable, a sub-deliverable, a working document but every
00:33:44 - component of the work package or every work package element should
00:33:51 - be building towards satisfying the deliverable so every work
00:33:55 - package is going to have a deliverable even if it's only a work
00:33:58 - document. What's the acceptance criteria? Who's going to review?
00:34:05 - Who validates that the team member has completed the work package
00:34:09 - successfully, that the deliverable, sub-deliverable working document
00:34:13 - is appropriate? What are the quality requirements? What are the
00:34:18 - time estimates? What are the milestones? What are the cost estimates?
00:34:21 - I said don't worry about these,
00:34:25 - that's still a true statement. The WBS is going to be built
00:34:30 - throughout planning.
00:34:37 - So in this nugget we're focused on defining the WBS which really
00:34:43 - probably comes down to the definition of the deliverables, what
00:34:47 - the work package content is, and what the acceptance criteria,
00:34:50 - how it's going to be reviewed. The quality requirements, the
00:34:54 - estimates, the milestones, the cost estimates, and the resource
00:34:58 - assignments are going to come
00:35:00 - in later nuggets.
00:35:03 - But we need to have a vehicle
00:35:11 - and the WBS dictionary is the vehicle for maintaining all of
00:35:15 - these information related to the work package. Now
00:35:20 - Project Plus exam will have questions related to a WBS dictionary.
00:35:27 - In my real life experience delivering projects I have never created
00:35:33 - anything formally called a WBS dictionary, I take my WBS, I put
00:35:40 - it into project scheduling software,
00:35:47 - and in the project scheduling software it will become
00:35:53 - my WBS dictionary. The project scheduling software is going to
00:35:57 - identify the WBS, the contents, the deliverables are going to
00:36:01 - be documented in my project scheduling software, the acceptance
00:36:05 - criteria, the estimates, the costs, the resources will all be
00:36:10 - simply data that I'm going to plug into my project scheduling
00:36:15 - software. Again I don't formally produce something called the
00:36:19 - WBS dictionary but to satisfy the requirements for the Project
00:36:22 - Plus you need to understand the concept
00:36:27 - of a WBS dictionary, a project dictionary, understand what goes
00:36:30 - into a WBS dictionary but recognizing that you will be doing
00:36:35 - this through your scheduling software.
00:36:41 - And when you're using your scheduling software you're not going
00:36:44 - to be having a form that pops up that says "Fill in these elements
00:36:50 - of the WBS dictionary" these are simply pieces of data that's
00:36:54 - part of using scheduling software.
00:36:58 - And I hope this statement has confused you. Elements of the WBS
00:37:03 - dictionary, the principles of a WBS dictionary absolutely apply
00:37:08 - and will be tested on the Project Plus exam. The reality is the
00:37:14 - WBS dictionary is delivered through your standard scheduling
00:37:17 - software. This completes 2.2
00:37:22 - use a WBS structure and WBS dictionary to organize project planning.
00:37:27 - In this nugget we focused on creating the work breakdown structure,
00:37:32 - we identified all of the work packages
00:37:38 - that were assignable to resource,
00:37:43 - to a skill, to
00:37:45 - a resource, that we're estimatable
00:37:50 - and we're measurable.
00:37:55 - We used this thing called decomposition
00:38:03 - to break the scope down to the deliverables, down to sub-deliverables,
00:38:08 - down to work packages and we knew to stop our decomposition when
00:38:13 - we got the work packages defined to the point that they were
00:38:17 - assignable, estimatable, and measurable. Developing a good WBS
00:38:23 - is critical because that's the building block for our future
00:38:27 - project planning activities from the WBS,
00:38:32 - we assign resources,
00:38:39 - we develop the estimates,
00:38:48 - we use this project scheduling software, and we develop a schedule
00:38:58 - and from the schedule we develop the budget.
00:39:07 - If the WBS is incomplete,
00:39:10 - if the WBS doesn't identify all of the work to satisfy the scope
00:39:14 - not only are we not going to be successful in completing the
00:39:17 - project, we're not going to know which resources, we're not going
00:39:20 - to have realistic estimates, we're not going to have appropriate
00:39:23 - schedule, we're not going to have a budget, we're setting our
00:39:26 - project up for failure before we even start. Developing a good
00:39:31 - WBS is a lot of work
00:39:36 - but it's a critical building block and it's going to produce
00:39:39 - that detailed view of your project. This
00:39:43 - concludes our nugget on create WBS and WBS dictionary. I hope
00:39:48 - this module has been informative for you and thank you very much
00:39:51 - for viewing.

Define Change Management Process

Develop Project Schedule and Resources and Roles

PERT/GANTT/CPM and Schedule Compression

Communications Management Plan

Risk Management Plan

Quality Management Plan

Cost Management Plan

Procurement Management Plan

Transition and Project Management Plan

Human Resource Management

Project Governance

Project Tracking

Project Change Management

Project Risk Management

Project Quality Management

Project Delivery Management

Earned Value Management

Project Communication Management

Project Closure

Please help us improve by sharing your feedback on training courses and videos. For customer service questions, please contact our support team. The views expressed in comments reflect those of the author and not of CBT Nuggets. We reserve the right to remove comments that do not adhere to our community standards.

comments powered by Disqus

Course Features

Speed Control

Play videos at a faster or slower pace.


Pick up where you left off watching a video.


Jot down information to refer back to at a later time.

Closed Captions

Follow what the trainers are saying with ease.

Premium Features

Transcender® Practice Exams

These practice tests help you review your knowledge and prepare you for exams.

Offline Training

Our mobile apps offer the ability to download videos and train anytime, anywhere offline.

Accountability Coaching

Develop and maintain a study plan with assistance from coaches.
Steve Caseley

Steve Caseley

CBT Nuggets Trainer


Area Of Expertise:
Project Management, MS Project, Development Methodologies, Agile Development

Stay Connected

Get the latest updates on the subjects you choose.

  © 2015 CBT Nuggets. All rights reserved. Licensing Agreement | Billing Agreement | Privacy Policy | RSS