Breaking Work into Task-Sized Chunks
When managing projects, it is important to build a WBS — a work breakdown structure. This article, the first in a three-part series, will explain why a WBS is important and show you how to build one. It is excerpted from chapter four of the book Microsoft Project 2007: The Missing Manual, written by Bonnie Biafore (O’Reilly, 2007; ISBN: 0596528361). Copyright © 2007 O’Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O’Reilly Media.
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.
Identifying the Work to Be Done
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.
Breaking Down Work
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.)
UP TO SPEED
Borrowing a WBS
Even with input from all the stakeholders for the project, a blank WBS can be as daunting as the first blank page of the novel you want to write. Fortunately, several methods of developing a WBS let you learn—or even borrow outright—from the ideas and work of project managers who walked this path before:
- Similar projects. If you know of a project that’s similar to the one you’re working on now, the fastest way to create a WBS is to use one that’s already finished, whether it’s stored in Project or another program. Be sure to check that project’s final schedule and its closeout documents (page 107) to identify work that was added during project execution.
- Experienced resources. If people in your organization (or outside consultants and contractors, for that matter) have experience with your kind of project, they can help flesh out a WBS or identify work you’ve missed. You can write up the WBS as best you can, and then ask folks to look it over for you.
- Microsoft Project templates. When you install Project, you automatically get a set of built-in templates for different types of projects, from technology deployments to residential construction (page 424). If these templates don’t meet your needs, Microsoft Office Online
(http://officemicrosoft.com)and other Web sites offer hundreds of specialized Project templates. Start with one of these templates to launch your WBS, altering it until it fits your project like a glove.
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.
Building a WBS from the top down
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 page 123 for a detailed definition of deliverables and milestones.)
A project scope statement (page 47) 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.
GEM IN THE ROUGH
Good Task Names
The more a task name conveys the work it represents, the less you have to worry about whether team members are doing what they’re supposed to. Effective task names include a verb and noun–the action you want people to take and the result you expect.
Using the present tense of a verb presents the task as a command or directive. For example, “Write How-to Manual” clearly identifies the type of work and which deliverable the work applies to. “How-to Manual” doesn’t tell the assigned resources whether they are reading, writing, editing, or printing a how-to manual. Unambiguous verbs help clarify work. Instead of telling your partner to prepare the chicken for dinner, specify whether you mean frying, roasting, or breaking the bad news about life expedancy to the chicken.
You can help your audience interpret tasks by differentiating summary tasks, work packages, and milestones with different grammatical forms:
- Because summary tasks represent a series of activities that span time, change the verbs for summary tasks to a gerund (a verb with “ing” at the end), like “Moving household goods.”
- Milestones represent goals or states. A typical form for a milestone name is the deliverable and its state, such as Steel Columns Fabricated or Steel Columns Erected.
Taken from: http://www.aspfree.com