When you organize a simple activity like seeing a movie with friends, you probably don't bother writing out the steps. You just call your friends, pick a movie, get tickets, and buy popcorn without a formal plan. However, for more complex projects—like preparing your income tax return or launching a new product line—identifying the work involved is key to planning how and when to get it done. For example, missing the April 15 deadline can cost you hundreds of dollars in penalties. That new product may make a profit only if you keep costs below $100,000 and get it on the shelves before Thanksgiving. At such times, cost, delivery dates, and other objectives are important.
That's where a WBS (work breakdown structure) comes in. Carving up the project's work into a hierarchy of progressively smaller chunks until you get to bite-sized pieces is the first step to figuring out how and when everything will get done. If you're new to managing projects, don't panic—you've built a WBS before. The movie example in the previous paragraph is actually a simple WBS. The structure of a WBS is much like the system of blood vessels in your body, with the aorta representing the entire project and the smaller blood vessels as progressively smaller chunks of the overall work at each level (summary tasks). The hoards of tiny capillaries that deliver blood to every part of your body correspond to the individual tasks (called work packages) at the bottom of the WBS, which are the smallest chunks of work that you assign to people to complete the project.
In this chapter, you'll learn how to create a WBS that successfully communicates the work within a project. Equally important, you'll learn how to tell when the WBS is broken down enough. The rest of the chapter helps you get your WBS into Microsoft Project, so you can proceed to constructing a project schedule as described in Chapter 6.
The fastest way to create a WBS is to construct it directly in Project, and this chapter shows you several ways to do just that. If you're working alone, you can empty your brain into Project, or you can just as easily transcribe the results of collaborative WBS sessions. You can also build a WBS in Microsoft Word, and import the results into Project (in case you love working in Word, or teams submit individual Word documents for their portions of the project). Finally, you'll also learn how to create documents that describe and support your project's work packages.
Knowing the high-level tasks that make up your project is important, but big chunks like Build Bridge, Hire New Staff, and Plan Grand Opening Party don't help when you're trying to estimate costs, line up resources, schedule work, or track progress. You need to get much more specific about the actual work all this is going to take. The point of a WBS is to break down the work into small enough pieces so you can do the following:
Improve estimates. Smaller tasks are not only less intimidating, they make it much easier to figure out how many people you need to perform each portion of work, how long it'll take, and how much it'll cost.
Keep the team focused. Because the WBS spells out exactly what's needed to achieve the project's objectives, it acts as a checklist for the work on the project team's plate. And it also gently guides team members away from doing things outside the scope of the project.
Assign work to resources. When the work is broken down into discrete tasks, it's easier to identify the skills needed to complete the assignment. The project manager can clearly determine who's responsible for what. Also, team members are more likely to understand their individual assignments, which makes them happy, and helps keep the project on track.
On the other hand, don't go overboard by dissecting work into miniscule assignments. Productivity drops when team members keep switching to new assignments while your temptation to micro-manage increases. (You'll learn how to determine the appropriate size for a work package in the next section.)
Keep the project on track. Shorter tasks give you frequent checkpoints for tracking costs, effort, and completion dates. Moreover, if tasks have strayed off course, you can take corrective action before things get too far out of hand.
In the PMI project management methodology, introduced briefly in Chapter 1, a WBS is the result of the scope definition process. The starting point is a scope statement (Gauging Success), in which you define the boundaries of the project—what's within the scope of the project and, just as important, what isn't within the scope. For example, knowing whether the cleaning service you hire takes on teenagers' rooms could be essential to success. For many projects, especially those performed for government agencies, the WBS is a contractually binding document, making the correct inclusion and exclusion of work essential.
Like Goldilocks, you have to find the right size for the work packages—not too big, not too small, but just right. Large work packages can be so vague that team members aren't sure what they're supposed to do. Moreover, your team could reassure you for weeks that a large chunk of work is running smoothly, only to beg for a schedule-busting extension just when you thought they'd be done. Too-small work packages, on the other hand, carry all the disadvantages of micromanagement: excessive communication, unending status reporting, lost productivity, and so on. So, how do you build a WBS with work packages that are just right?
Each project is unique, so don't expect the same project management approach to work for every project you manage. Identifying work can run the gamut from invigoratingly informal to scrupulously methodical, depending on whether you're planning a small project for a close-knit group or wrestling with a multi-year, multi-vendor project. (Whatever the project, a sure-fire shortcut is to borrow from existing sources, as described in the box below.)
A WBS has only two types of elements: summary tasks and work packages. As you learned in Chapter 3, the lowest level of a WBS contains the work package tasks—hunks of actual work that you assign to team members. Anything else in a WBS is simply some level of summary of that work, which can nest to as many levels as you need, as shown in Figure 4-1. As it turns out, you can build a WBS from whichever direction you prefer—top down, bottom up, or side to side—as described in the following sections.
Figure 4-1. The organization of a WBS can vary, but the work packages remain the same. For example, you might track a project by phases (planning, design, and construction) or by completed components (from condo unit to floor to building). As you build a WBS, you can change summary tasks and move work packages around.
As the name "work breakdown structure" implies, the most common way to build a WBS is to start with the entire project and break it down until you reach assignable work packages at the bottom. The most common way to decompose (that is, break down) a project is by the deliverables that you want the project to produce and the milestones you want it to attain. (See Creating Milestones for a detailed definition of deliverables and milestones.)
A project scope statement (Gauging Success) usually lists a set of deliverables that the project customer and other stakeholders expect to receive. One of the best ways to identify project work is to create high-level tasks for every project deliverable. For example, if you're planning the party of the century, you'd create summary tasks for the tents and tables, the food, the drinks, the music, and the video you need to blackmail your friends after the fact.
Once you have these top-level tasks, you take another run at decomposition to identify intermediate deliverables and critical milestones, for instance, the completion of the celebratory rum cake or finalizing the reservations for all the party vendors. For each intermediate deliverable and milestone, ask yourself what work it entails. For instance, the music requires an audio system as well as a song list, so you add one task to rent the audio equipment and another to build a playlist of songs on your computer. Then, you simply repeat this process for each deliverable until you have work packages that you can assign to your spouse, your kids, the caterer, and other folks you hire. (See the box below for advice on effectively naming these tasks.)
Once you complete your WBS, take some time to verify it. Make sure all items in the scope statement have corresponding work on the WBS, and look out for work packages that don't support the scope. Add missing summary tasks and work packages. If you think of a deliverable that isn't on the scope statement, add the work to the WBS, and revise the scope statement. Keep in mind, though, if you're doing projects for customers, you probably need their approval to change the scope statement.
Another way to slice and dice a project is to identify what you have to do from the beginning of the project until the end. This approach isn't all that different from the top-down decomposition described in the previous section, except that you decompose each branch of the tree until you reach its work packages. Then, you go back to the top and work your way to the bottom of the next branch.
This variation on the top-down method is ideal when different teams or groups work on a project. Once you identify top-level tasks, you can assign their decomposition to the groups that do the work. See "Importing a WBS into Project" on Importing a WBS into Project for instructions on assembling WBSs from several groups.
Don't forget to include project initiation and management tasks in your WBS. Sure, some of your work goes on behind the scenes without obvious deliverables, but project management is essential to keeping projects within budget and on schedule. Besides, project management does have deliverables, since most customers and stakeholders sign off on project plans, and want to see status reports, documents, and expenditures.
Identifying work packages and then organizing them into summary tasks usually works only for small projects, but small projects occur often enough to make this a popular approach. Whether you write tasks on sticky notes or type them into Project, you can pump out every iota of work you think of, and then organize it into higher-level tasks.
Most people can keep track of up to five things, although stress and age increase forgetfulness. If you're a juggler extraordinaire, you might be able to absorb eight items, but, beyond that, all bets are off. For a WBS that audiences can digest, between three and seven levels of summary tasks are ideal. For example, you can divide the entire project at the top level into phases like defining requirements, designing systems, and developing components. Then, within each phase, you can create lower levels to identify work in more detail.
For monster projects, though, you can exceed the level limit without losing focus by breaking the behemoth into subprojects. If the overall project is building a new jet, you can have a few levels of decomposition to reach a set of subprojects, each of which contributes major deliverables (engines, fuselage, electronics, and so on). Then, separate WBSs for each subproject can use their own three to seven levels. When vendors or subcontractors perform subprojects, ask them to develop the WBSs for their subprojects.
If you have a bunch of folks helping you put the WBS together, see the box on Constructing a WBS from the bottom up for advice on working together effectively.
As with almost any endeavor, the last 20 percent is the most difficult. The first several levels of the WBS might appear almost effortlessly, but then the decomposition can slow to a crawl as you try to decide whether something represents a work package or not. Here are some ideas for how to choose what constitutes a work package:
To estimate work. When you break work down into work packages based on the work you know how to estimate, figuring out the overall project is as easy as adding up estimates for all the chunks. You may not have a clue how long it will take to deploy Windows Vista throughout your organization, but you do know that it takes 3 hours to upgrade and reconfigure one computer.
To track progress. One rule of thumb for defining work packages is to keep task duration between 8 and 80 hours (in other words, anywhere from one work day up to two work weeks). These durations also give you early warning when tasks overrun their estimates. In addition, if you break work down into durations no longer than the time between status reports, you're likely to have concrete progress to report. The downside is you need a clear idea of how long various tasks take, but this approach works well for projects similar to those you've performed in the past.
To maintain focus. Guidelines aside, simply decompose work to the level of detail that you can handle. If you're a keep-things-simple type, you can keep your WBS at a high level and let team leaders manage details. On the other hand, if you can remember details the way a Starbucks barista remembers coffee orders, you can break down the work to your heart's content. Just remember that dividing work into portions that take less than a day can reduce productivity and morale (with certain exceptions, as discussed in the box on Building a WBS in Microsoft Project).