2.2 Planning and the WBS, Part 1

Lets talk a little bit about, planning. And specifically we’re going to talk about the WBS. We’ll talk more about some other elements of planning after this. But first we’ll start with this one. WBS, it’s a work break down structure. It’s a way to plan the tasks for a project. It’s a way to display the tasks for a project. It’s a way to communicate the project complexity. What is a WBS? A deliverable, oriented grouping of project elements. Each ascending level represents an increasingly detailed definition of project work. This is the official definition from the Project Management Institute. Let’s talk just a little bit about two schools of thought on the WBS. Some people say that the work break down structure should include the deliverables and a high level of work but not all the details of work. The detailed tasks of the project, according to the Project Management Institute, would be listed either in a thing called a WBS dictionary and or a separate task list, though the tasks would not be on the WBS. Another school of thought, the detailed tasks are on the WBS. Starts with the deliverables, goes all the way down through, through descending layers and levels of detail until we get to a very fine level of detail called a task, a detailed project task. Why are you going to do a WBS? Well, you just have to. There’s just no way around it. It’s a foundation for most of the rest of the project plan. It provides a detailed illustration of the project. By the time you’re done with this thing, you’ll have a way to define your human resource costs, and it provides assignments for people. So, this is going to be a foundation for costing, for resources, it’s going to be the foundation for our schedule, it could, also add a number of elements to our communication plan. This piece is going to be the foundation for a number of other elements on the project plan. We’re going to have deliverables and tasks on a WBS. The way the PMI lays out the common terms that are used, we have deliverables at the high level. We worked down to work packages, we break the work packages into project activities, and we break the project activities into detailed tasks. When we move into a schedule, we are going to put the detailed tasks on the project schedule. Two major schools of thought like we talked about. Only deliverables and work packages or everything. And on ours we will put everything. Really doesn’t matter which one these you do. You just need to put all of this information some place. So, PMI has listed out a WBS dictionary and a task list, in addition to the WBS. We are going to put everything, like I said, on the WBS. Doesn’t make any difference how you do this. Just as long as you have all that information some place. Identify the tasks. First, we’re going to define the deliverables. Second, we’ll identify the tasks. Deliverables have come from the initiating phase, and then in the beginning of the planning phase, to make sure that we’re clear about the deliverables. Now we’re gonna figure out how we’re gonna make all this stuff happen. Deliverable. Unique verifiable product or result. Project Activity, component of work. WBS will outline all three ways that we’ve talked about Scope before. It will show us the Product Scope, all the deliverables, all the things. It will show us all the work. And together, it’s going to show us the total Scope of the project. In the early development of WBS, started to look like this, and in this slide you’ll notice that the top level is called Program. Program is a group of related projects, that together these projects make up one, one total thing, one total entity of some kind, called a Program. Most of us are going to be starting at the Project level. We’re Project Managers rather than Program Managers who are managing a whole lot of interrelated projects and Project Managers.