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.
Note
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.
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.
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.
Note
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).
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 Creating and Modifying a WBS on the Fly). 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.
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.
The Column Definition dialog box appears. In the “Field name” drop-down list, choose WBS, as shown in Figure 4-2, and then click OK. The new column appears to the left of the Task Name 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 (Setting Up Customized WBS Codes).
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 Figure 4-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.
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.
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 Figure 4-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.
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 Figure 4-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 outline box 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.
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 27, 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.
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 out-line 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 sub-tasks, 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.
The WBS codes built into Project are simple outline codes with a number for each level in the outline hierarchy. For instance, a WBS code of 2.1.3 might represent the second phase of the project, the first summary task in that phase, and the third work package for that summary task. If your organization uses customized codes, you can build a tailored numbering system—called a code mask—to specify each level of your WBS code. If you use abbreviations for phases, numbers for summary tasks, and letters for work packages, a customized WBS for the design phase of a project might look like this: Dsn 1.a.
To define a customized WBS code, follow these steps:
Choose Project → WBS → Define Code.
The WBS Code Definition dialog box appears. Although any existing WBS codes show numbers for each level with a period as a separator, the boxes in the WBS Code Definition dialog box are empty until you specify a custom scheme for your WBS codes.
Note
If you assemble several projects into a single master project (Creating a Master Project), you can make WBS codes unique for each project, even if they use the same code mask. If you work with multiple projects, set up the code mask for a new project before you get too deep into defining the project tasks. That way you don’t have to renumber all your tasks later. In the Project Code Prefix box, type a prefix for the current project. Project inserts the project prefix at the beginning of the WBS codes for the tasks in the project; for instance, PRJ01.1.4.1.
In the “Code mask” section, in the first Sequence cell, choose the type of characters you want to use for the top level of the hierarchy, as shown in the top figure of Figure 4-7.
You can choose from Numbers (ordered), Uppercase Letters (ordered), Lowercase Letters (ordered), and, for most flexible coding, Characters (unordered). Ordered numbers and letters mean that Project automatically increments the numbers or letters as you add tasks to the WBS, for example, proceeding from 1.1 to 1.2. to 1.3.
In the first Length cell, choose a number (from 1 to 10) for the length of the mask for the top level.
Project initially selects Any, which means the entry for the level can be of any length. If the level uses a number, Project increments the number beginning at 1 and continuing to 10, 100, or 1000, if necessary. If the level uses letters, then you can type a code of any number of characters at that level.
Choosing a number limits the entry to between one character and the length you specify. If you limit a numeric entry to one character, Project cycles through the numbers 1 through 9, moves to 0, and then repeats.
In the Separator cell, choose the character that separates the top level from the next level.
The only choices for separators are a period (.), minus sign (−), plus sign (+), or slash (/).
Repeat steps 2, 3, and 4 for each additional level of the code mask.
You can specify dozens of levels in a code mask (in fact, a WBS code can be as long as 255 characters), but being miserly with levels makes the schedule easier to comprehend.
Figure 4-7. Top: The choices for characters, length, and separators are limited. If you use unordered characters, you have to type the characters you want for each code, such as Dsn-.1, Const.3, or Rvw.7.Bottom: As you specify the code mask for each level, the “Code preview” box at the top of the dialog box displays a sample WBS code.
After you’ve defined all the levels in the code mask, be sure that the “Generate WBS code for new task” checkbox is turned on if you want Project to automatically assign a WBS code to new tasks you create.
The only time you might decide to turn this checkbox off is when you plan to renumber all the WBS codes after you’ve organized your tasks, and don’t want to be distracted by the interim codes that Project assigns.
To ensure that your WBS codes are unique, keep the “Verify uniqueness of new WBS codes” checkbox turned on. Click OK, and then review the refreshed WBS codes in the task list, as shown in Figure 4-8.
Although Project adds WBS codes to tasks when the “Generate WBS code for new task” checkbox is turned on, sometimes you want to type WBS codes manually, and that can lead to duplicate WBS codes. The only time you might turn off the “Verify uniqueness of new WBS codes” checkbox is if you’re planning to renumber tasks later, and you get tired of the warnings that Project displays. As the box on Documenting a WBS in Another Program explains, you can renumber the WBS codes for tasks to correct or reorder your project.
Everyone has a favorite word processor, but Microsoft Word is a strong favorite for WBS creation because of its outlining feature. Word makes it easy to indent, outdent, insert, move, and delete tasks. Then, with a few additional steps, you can import the Word WBS into Project, as described in the next section. Moreover, more of your team members are likely to be familiar with Word than with Project, so you’re likely to get project information from them in Word documents.
Folks who are fans of Word outlining already know that adding and rearranging topics goes as fast as your fingers on the keyboard. If you haven’t experienced the joy of Word outlining, here are some techniques you can use:
Switch to Outline view. In Word 2007, click the View tab, and then, in the Document Views section, click Outline. In Word 2003, choose View → Outline.
Add tasks. Insert a new line by clicking at the end of the preceding task, and then pressing Enter. Type the task name. Press Enter to add another task.
Demote tasks. Select the task or tasks you want to push to a lower level, and then press Tab (or Alt+Shift+right arrow key). In Word 2007, click Outlining → Outline Tools → Demote, as shown in Figure 4-9. In Word 2003, you can also press Tab or, on the Outlining toolbar, click the Demote arrow.
Note
In Outline mode, you can select an outline item by clicking to the left of the item. To select several adjacent items, drag to the left of the items. Ctrl+click items to select several nonadjacent items.
Figure 4-9. Microsoft Word’s Outline view is a friendly environment for project outlining. To promote an item to the top level, click the “Promote to Heading1” button. Word offers a button for demoting items to Body Text, but it’s best to stick to heading levels, since these levels translate into Project outline levels when you import the tasks from Word into Project. (This picture shows Word 2007.)
Promote tasks. Select the task or tasks you want to promote to a higher level and then press Shift+Tab or Alt+Shift+left arrow key. In Word 2007, click Outlining → Outline Tools → Promote. In Word 2003, press Shift+Tab or, on the Outlining toolbar, click the Promote arrow.
Move tasks. Select the task or tasks you want to move, and then drag them to a new position. Or, use Ctrl+X and Ctrl+V to cut and paste the tasks from one position to another. If need be, demote or promote the tasks to the correct level.
Delete tasks. Select the task or tasks you want to delete, and then press Delete or Ctrl+X.
If you build a list of tasks in Word or, for that matter, Excel, WordPad, or another program that can produce text files, you can easily import tasks into Project. Suppose different teams use Word outlines to document the tasks they plan to perform. They can save their outlines as text files and send them to you. All you have to do is open the text file in Project; the Import Wizard launches to guide you through importing the tasks into a Project file.
Word doesn’t save Tab-delimited files out of the box. In addition, ideally you’d like imported tasks to come in at the correct WBS level. If you use Word outlining, the heading styles in the Word document correspond to the WBS level in the Project file.
The Import WBS Word template (created in Word 2003) at www.missingmanuals.com/cds has some handy tools for importing tasks into Project. The heading styles number each task with a WBS code, so you can confirm that the tasks are at the correct level before you import them. In addition, the template includes a macro that creates a text file that separates the task name (the first value) from the outline level (the second value).
Note
To use the macro in the Import WBS template, you must set up your copy of Word to let macros run. Because the steps to enable macros depend on the level of security you use, refer to Word Help or a book about Microsoft Word—like Word 2007: The Missing Manual by Chris Grover—for instructions.
Here are the steps to use the Word template (CH04 WBS Outline.dot) to import a WBS text file into Project:
Replace the text in the template with the tasks for your project.
Use the techniques described on Documenting a WBS in Another Program to indent or outdent tasks to the correct WBS level.
In the custom WBS toolbar, click “Create WBS for Import“.
You can specify the number of levels that you want to export, for example, if you plan to import the first several levels into a master project. When you click OK, then Word creates a new Word document with the outline levels separated from the task names with commas.
Choose File → Save As. Navigate to the folder you want to use, and then make sure to set the “Save as type” box to Plain Text.
Name the file, and then click Save to create the text file.
To import this file into Project, switch to Project, and then choose File → Open.
The Open dialog box automatically sets the “Files of type” box to Microsoft Project Files, so you need to tell Project you’re importing a text file.
In the “Files of type” drop-down list, choose Text (Tab delimited).
As you navigate folders, text files appear in the file list. The text file you created is comma-delimited, but the idiosyncrasies of Microsoft programs require you to choose Text (Tab Delimited). You’ll change the delimiter in a few steps.
If you import a comma-delimited file instead, for instance, one created with Excel, choose CSV (Comma delimited). Then, continue with the following steps.
When you locate your WBS text file in the file list, doubleclick its name. Alternatively, click the file name, and then click Open.
Project opens the text document, and then launches the Import Wizard.
Click Next to start the wizard.
On the Import Wizard—Map page, the wizard automatically selects the New Map option, which is usually what you want.
Tip
If you make a habit of importing text files, you can save the map (Importing Data into Project) you define. Then, the next time you import a file, select the Use Existing Map option, and then choose the map. The fields and other settings are ready for the import.
On the Import Wizard-Import Mode page, if you want to import the WBS into a blank project, keep the “As a new project” option selected. Click Next.
If you’re importing several text files into the same project, the “Append the data to the active project” option imports the tasks at the end of the existing task list. Selecting the “Merge the data into the active project” option imports the tasks at the currently selected row.
On the Import Wizard-Map Options page, keep the Task option selected. Click Next.
If the first row of the text file includes column names (as it might if you’re importing from an Excel file), then make sure the “Import includes headers” checkbox is turned on. However, if you used Word outlining to build a text file, turn off that checkbox.
The “Text delimiter” box specifies the character that separates fields, including a comma, tab, or space. For the WBS template, verify that the value is “,”.
On the Import Wizard-Task Mapping page, match the values in the text file to Project fields, as shown in Figure 4-10.
If your text file doesn’t include headings, the cells in the From: Text File Field column display sequential numbers for each field in the text file. For the WBS import template, you see “1” and “2” in the first two rows. In the first To: Microsoft Office Project Field cell, choose Name, because the first field in the text file is the task name. In the second cell in the column, choose Outline Level.
Note
If you import tasks from another source, match up the fields in the To: column with Project fields in the From: column. You can match as many fields as you want as long as the field in the text file for names maps to the Name field in Project and the outline level field in the text file maps to Outline Level.
Click Finish.
Project imports the tasks into your Project file.
If you’ve ever asked a teenager to do a chore, you already know the importance of clearly specifying the work to perform and the results you expect. Otherwise, the dishes in the dishwasher might be placed in the cupboards—unfortunately, before they’re washed. Providing project team members with clear guidance is equally important, but the task names in Project are too short to get into detail. For that reason, separate documents that describe work packages are a great way to tell team members how to do their assignments completely and correctly. And you don’t even have to worry about keeping track of lots of loose documents: You can link them to the Project schedule, as described at the end of this section.
Figure 4-10. As you map the fields, the Preview area shows how the values in your text file map to Project fields. In this example, the Name field will hold the values Planning, Identifying Requirements, Documenting Assumptions, and so on. If the mapping isn’t correct, then modify the fields in the To: Microsoft Office Project Field cells until you’re satisfied
Ideally, a work package document describes the work to perform, how to tell when the work is done, and how to tell whether it’s done right. A work package for baking a loaf of bread might include the steps for mixing, kneading, forming, and baking the bread. The document could specify that the bread is done when tapping the loaf delivers a hollow thump. Similarly, the work package might state that a successful loaf of bread is an attractive brown color, twice as tall as the unbaked dough, and full of evenly sized holes.
Even small projects require dozens of work package documents. You can speed up your work by creating a Word template for work packages, as basic or as fancy as your knowledge of Word. That way, you can open the template and have a document all labeled and ready for you to fill in. For example, you might set up a basic work package template with the following information:
WBS number. The WBS number that Project assigned to the task in your Project schedule.
Work package name. The task name from the Project schedule.
Description of work. You can use paragraphs or bullet points and provide as much detail as you need to ensure success. If you know an experienced resource is going to do the work, the document can be brief. For trainees, you can provide detailed checklists of steps, or, perhaps, the name of the person who can mentor the assigned resource.
Result. Describe the final state when the work is done as well as how to verify that the work is done correctly. For a work package for setting up a computer, you might include the list of programs that should launch when the installation is complete.
Reference materials. Projects use many types of documents to specify deliverables: requirements, specifications, blueprints, and so on. If additional detailed documentation exists, include the location of those documents, like the folder on the network drive or the project notebook.
Creating a Word template is no harder than creating a Word document. However, finding and using a template takes some setup. Here’s how to create a Word template and save it for reuse:
Create a Word document with the labels you want to include.
If you want to get fancy, then insert a logo, add instructions to help others fill in work packages, and so on.
In Word 2007, choose Office button → Save. In Word 2003, choose File → Save.
The Save As dialog box appears.
Navigate to the folder you use for your custom templates.
For example, create a folder called Templates in the My Documents folder.
In Word 2007, in the “File name” box, type the name of the template, and in the “Save as type” box, choose Word Template. In addition, in the navigation bar on the left side of the dialog box, click Trusted Templates. Click Save.
In Word 2003, in the “Save as type” box, choose Document Template.
To set up faster access to your template, Click the Office button and then, at the bottom of the Office menu, click Word Options.
Telling Word where to find your custom templates makes it easier to find and open this template later. That way, you can see these templates right in the New Document dialog box every time you start a new project, as described in the next section.
In the Word Options dialog box, click Advanced. Then scroll to the bottom of the window to the General section, and select File Locations.
You want to tell Word where to find your templates.
Select “User templates” or “Workgroup templates”, and then click Modify. In the Modify Location dialog box, navigate to your template folder, and then click OK.
Choose the folder you created in step 3.
Click OK again to close the Options dialog box.
In Word 2007, click the Office button, and then choose New. In the New Document window, click “My templates.” The New dialog box appears showing the templates in your Trusted Templates folder. Select the template, and then click OK.
To use a template in Word 2003, choose File → New. In the New Document task pane, under the Templates heading, click “On my computer”. The Templates dialog box appears open to the General tab, which displays the templates in your User templates or Workgroup template folders (whichever you chose in the previous steps). Select the template, and then click OK.
With work package documents illuminating the details of tasks, you’re likely to refer to those documents as you work on your Project schedule. There’s no need to open them by hand or try to remember where they are. Instead, you can insert a hyperlink from a task in the Project schedule to the corresponding work package document. With a hyperlink in place, opening the work package document is a quick click in Project.
To create a hyperlink in a Project task, do the following:
In Project, select the task you want to link to a work package document, and then choose Insert → Hyperlink.
The Insert Hyperlink dialog box appears.
In the “Link to” bar, click Existing File Or Web Page.
Navigate to the folder that contains the work package document, and then double-click the name of the work package file. The “Look in” box shows the folder while the Address box displays the file name.
Click OK.
In the Indicators column, a hyperlink icon appears, as shown in Figure 4-11.
Figure 4-11. The Hyperlink icon looks like a globe with a link of chain, a not-so-subtle commentary that hyperlinks connect the world. If the Indicators column isn’t visible, then right-click the Entry table and choose Insert Column on the shortcut menu. In the Field Name drop-down list, choose Indicators, and then click OK.
To access a hyperlinked file, simply click the hyperlink icon in the Indicator cell.
The program associated with the file launches, and the file opens.
Get Microsoft Project 2007: The Missing Manual now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
