Breaking Work into Task-Sized Chunks - Building a WBS from the top down
(Page 4 of 4 )
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.
Please check back next week for the continuation of this article.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 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.
|
|
