Breaking Up Your Work in Microsoft Project - When Is Enough Enough?
(Page 2 of 4 )
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.
Next: Building a WBS in Microsoft Project >>
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.
|
|
