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.
Tip: 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.
Constructing a WBS from the bottom up
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.
WORD TO THE WISE
Too Many Cooks Can Spoil the WBS
If you’re a team of one, but tend to argue with yourself, asking another person to act as a tiebreaker can save time and frustration. In most cases, however, the problem is too many people with their own unquestionably correct ideas about how to break down the project. You’ll end up changing your WBS organization, rearranging summary tasks, and revising work packages with little progress toward a completed WBS.
Start with a small group of renaissance folks—people knowledgeable in one or more sections of the project and familiar with the overall goal. You could work with the managers for each department involved in the project to craft the top two or three levels of the WBS. Then, you can assign the decomposition of the lowest summary tasks of this initial WBS to work teams experienced with the type of work involved. The party caterer can identify the food tasks, whereas your brother-in-law may write up the tent-wrangling 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.
Note: If you have a bunch of folks helping you put the WBS together, see the box on page 72 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 page 73).
GEM IN THE ROUGH
When Short is Sweet
Most of the time, you don’t want to break down your WBS into tasks that take less than a day. Most people can handle a task like sending out invitations without reporting back to their boss after they buy the postage stamps. But suppose your project is about replacing a mission-critical software system. When it’s time to flip the switch to the new system, you probably have only a few hours or even minutes to make the change. That’s when you need a detailed plan with short work packages for the crucial period.
Fortunately, situations like this are few and far between. But here’s an example: You spend months preparing for the changeover with work broken into day- or week-long chunks. However, for the work that must be done over a single night before the staff starts coming back to work in the morning, you break work down into minute-by-minute packages. These miniature work packages help you line up the people you need (because you won’t have time to call them in at the last minute) and spot potential delays.
Your WBS may not have started out in Project. A WBS might be scribbled on a whiteboard, scrawled on sticky notes pasted to flip charts, or just rattling around noisily in your head. Regardless of where your ideas are, you can make short work of getting them into Project. Once you get familiar with the techniques for outlining tasks described on the next few pages, you’ll develop a rhythm to your data entry. If you already have an outline, you can quickly type it into Project from the top down (see the box on page 77). Or if work packages are bubbling up in your brain, you can enter them without worrying about the order of the tasks or the overall structure. You can rearrange and add summary tasks and work packages later.
Creating a WBS in Project from the Top Down
One of the more efficient data entry methods is to start at the top of a WBS and complete each level of tasks before dropping to the next level. Because Project creates a new task at the same outline level as the previous task, this approach keeps indenting and outdenting to a minimum.
For maximum efficiency, when you flesh out a lowest-level summary task, insert as many rows as there are work packages for that summary task, and then type the names of the work packages in the Task Name cells. The following steps show you exactly how to work your way down a WBS one level at a time:
Choose File -> New to create a new blank project file.
The Gantt Chart view appears with the Entry table on the left and the Gantt Chart timescale on the right. If the Gantt Chart view doesn’t appear, choose View -> Gantt Chart or, in the View bar, click Gantt Chart.
If the WBS column doesn’t appear in the Entry table, right-click the Task Name heading and, from the shortcut menu, choose Insert Column.
Figure 4-2. In the Column Definition dialog box, in addition to choosing the field to display, you can label the column with a different name, align the text in the column, and specify the column width.
Note:Project keeps track of WBS numbers for tasks whether the WBS column is visible or not. The WBS code format that comes out of the box is a number at each level, with levels separated by periods. If your organization has a custom WBS format, you can set up your own WBS code (page 79).
In the Entry table, click the first Task Name cell, and then type the name for the first top-level summary task.
Press Enter to save this task, and then move down to the Task Name cell in the next row, as illustrated in Figure4-3.
By the way, you don’t have to create a top-level task for the overall project. Project has a project summary task, which sits in an exalted position of Row 0 and rolls up the values for all the other tasks in the schedule. If you want to see the Project Summary task, though, you have to tell Project to display it. Choose Tools -> Options. In the Options dialog box, select the View tab, and then turn on the “Show project summary task” checkbox.
Figure 4-3. Project creates the next task at the same level in the WBS outline as the previous task, so you’re ready to enter the next top-level task. As you’ll see shortly, this behavior makes it easy to add several tasks at the same level, no matter which level of the WBS you’re creating. Figure 4-3:
Repeat Step 3 for each top-level task in the WBS.
Creating the tasks at the top-level is as easy as it gets. You type a task name, press Enter, and repeat until all your top-level tasks are there. Now you’re ready to add tasks at the next level of the WBS.
Building a WBS in Microsoft Project
To add subtasks to a summary task, click the Task Name cell immediately below the summary task you’re fleshing out, and then press Insert as many times as there are subtasks, as demonstrated in Figure4-4.
This step is the secret to speedy outlining because it works in the same way at every level of the WBS: second-level, third-level, or lowest-level summary task. When you insert rows for the lowest-level summary task, insert as many rows as there are work packages for that summary task. Then you can type away and fill them all in quickly.
Figure 4-4. You can insert blank task rows by clicking anywhere in the row below the summary task and pressing Insert. But if you click the Task Name cell, when you press Insert the blank task’s Task Name cell becomes the active cell— ready for you to type the name of the first subtask.
With the blinking insertion point in the blank Task Name cell beckoning you, type the name of the subtask, and then press Enter to create the task.
Pressing Enter moves the active cell to the next Task Name cell. However, the first subtask isn’t at the right level—it’s still at the same level as the summary task.
To indent the task, press the up arrow key, and then press Alt+Shift+right arrow. Or, on the Formatting toolbar, click Indent (the green arrow pointing to the right).
Project indents the subtask and indicates its subordinate position in two ways: with the WBS number and the outline box—both shown in Figure4-5 .
Press the down arrow key to move to the next Task Name cell, type the name, and then press Enter.
Because the first subtask is at the correct level, the remaining subtasks come to life at the right level for their summary task.
Repeat steps 5 through 8 for every summary task in the WBS, ultimately filling in each level of the WBS.
Your initial draft of the WBS is complete.
Figure 4-5.The WBS code for the subtask includes an additional level of numbers. If the summary task WBS number is 2.4, its first subtask has the number 2.4.1. Summary task names are preceded by an outline box—a square with a minus sign inside that indicates that the summary task is expanded. If you click the box, the summary task collapses and hides its subtasks, and the outline box changes to a square with a + sign.
POWER USERS' CLINIC
Displaying a WBS in a Hierarchy
The outline in Project shows the levels of the WBS hierarchy, but you might prefer to view the WBS as a hierarchy similar to an organization chart (see Figure 4-6), for example, when you’re presenting the WBS to audiences unfamiliar with Project. In Microsoft Project 2003, the Visio WBS Chart Wizard transformed a task list in Project into a tree diagram in Visio, but that tool has gone the way of the dodo bird in Project 2007. A visual report (page 410) is the Project 2007 solution for turning a task list into a tree, but the process and result aren't nearly as satisfying as the Visio WBS Chart Wizard.
Project 2007 doesn’t include a built-in visual report for displaying a WBS. But you can navigate to www.missing-manuals.com/cds and download a visual report template for a WBS. When you work with visual reports, you can specify which folders to search for customized templates, as described on page 421. Project then displays the templates in that folder in the visual report list. This template uses only the task name, WBS, Work, and Duration fields and sets up a tree structure. However, you must expand each summary task individually by right-clicking the task, and then, from the shortcut menu, choosing Tasks. (See page 411 to learn how to generate a visual report from a template.)
If you’re in high gear churning out project tasks, you can gleefully insert, delete, and rearrange the WBS outline as you go. The resulting WBS looks exactly the same as one methodically typed from the top down. Also, the methods for adding, moving, and changing outline levels for tasks are the same whether you’re creating or modifying a WBS.
Figure 4-6. In Project 2007, visual reports can make project information easier to digest by displaying the data in Excel or Visio. This visual report using Visio takes the tasks in a Project file and displays them as a WBS tree structure. As you’ll learn in Chapter 17, you can use other types of visual reports to decompose project information, for instance, or to analyze cost and schedule overruns to identify problems areas.
You can use the following techniques to develop a WBS in any order:
Insert a new summary task. In the row below the new summary task, click the Task Name cell, and then press Insert. Type the task name, and then either press Alt+Shift+left arrow or, on the Formatting toolbar, click Outdent until the summary task is at the level you want.
Insert a new subtask. Click the Task Name cell in the row that should be below the new subtask, and then press Insert. The task appears at the same outline level as the task you clicked.
Make a summary task into a subtask. Select the summary task, and then either press Alt+Shift+right arrow or, on the Formatting toolbar, click Indent (the green arrow pointing to the right). When you indent a summary task, its outline box disappears. In addition, the task above it remains at the same level in the outline.
Move a subtask to the next lower level. Select the task, and then press Alt+Shift+Right Arrow or, on the Formatting toolbar, click Indent. The task drops to the next lower level while the task above it turns into a summary task.
Tip: If you want to move, indent, outdent, or delete several tasks at once, then select them all, and then use the techniques in this section. To select adjoining tasks in the outline, drag across the adjacent tasks. To select several separate tasks, Ctrl+click each task.
Elevate a subtask to the next higher level. Click the task. On the Formatting toolbar, click Outdent (the green arrow pointing to the left) or press Alt+Shift+left arrow.
Move a subtask to another summary task. Click the ID cell (the first column of the view table) for the task you want to move. After the pointer turns into a four-headed arrow, drag the task to its new home in the outline. Change its outline level if necessary.
Delete a subtask. Select the subtask, and then press Delete.
Delete a summary task. If you want to delete a summary task and all of its subtasks, select the summary task, and then press Delete, or choose Edit -> Delete Task. (And if you want to delete a summary task and keep all of the subtasks, see the box below.)
Note: To use the Delete key to delete a task, you must select the entire task row (by clicking the ID number for the row). If you select only the Task Name cell, and then press Delete, Project deletes the text in the cell. Alternatively, if you click the Smart Tag with an X, which appears to the left of the Task Name cell, you can choose the “Only clear the contents of the Task Name Cell” option or “Delete the entire task” option.
FREQUENTLY ASKED QUESTION
Sparing the Subtasks
How do delete a summary task without deleting its subtasks?
It depends on what you want to do with the subtasks. If you want to shift the subtasks to a different summary task, it’s easiest to first relocate the subtasks to their new home. Then you can delete the empty summary task by selecting it, and then pressing Delete.
However, if you’re not yet where you want the orphaned subtasks to end up, simply change them to the same outline level as the summary task before deleting the summary task.
Here's how:
Select the subtasks by dragging across their Task Name cells.
Press Alt+Shift+left arrow to change the tasks to the same outline level as their summary task. You can tell that the summary task is devoid of subtasks because the outline box with the + or – sign disappears.
Select the summary task demoted to a regular task, and then press Delete.
BrainDump 
Codes and Packages in Microsoft Project 2007
