Breaking Up Your Work in Microsoft Project
(Page 1 of 4 )
In this second part to a three-part series on using Microsoft Project to build a work breakdown structure (WBS), you'll learn how to develop a WBS from start to finish. 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.
Developing a WBS from start to finish
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 page 84 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.
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.
Next: When Is Enough Enough? >>
More BrainDump Articles
More By O'Reilly Media
|
 This article is excerpted from chapter four of the book Microsoft Project 2007: The Missing Manual, written by Bonnie Biafore (O'Reilly, 2007; ISBN: 0596528361). Check it out today at your favorite bookstore. Buy this book now.
|
|
