Guidelines for Developing the WBS
One important question in constructing a WBS is “When do you stop breaking down the work?” The general guideline is that you stop when you reach a point where either you can estimate time and cost to the desired degree of accuracy or the work will take an amount of time equal to the smallest units you want to schedule. If, for instance, you want to schedule to the nearest day, you break down the work to the point where tasks take about a day to perform. If you are going to schedule to the nearest hour, then you stop when task durations are in that range.
Stop breaking down work when you reach a low enough level to do an estimate of the desired accuracy.
Remember the rule that the people who must do the work should participate in planning it? That applies here. Usually a core group identifies top-level parts of the WBS; those parts are further refined by other members of the team and then integrated to obtain the entire WBS.
One important point: the WBS should be developed before the schedule. In fact, the WBS is the device that ties the entire project together. It allows resources to be assigned and estimates of time and cost to be made and shows the scope of the job in graphic form. Later, as the project is tracked, the work can be identified as falling in a particular box in the WBS.
The WBS should always be developed before the schedule is worked out, but without trying to identify the sequence of activities.
There is at least one software package, SuperProject Expert™, that prints a WBS after schedule data have been entered. That is a nice feature, since it gives a graphically attractive WBS, but the rough drawing should be made before you use the scheduling software. The reason is quite simple: until everyone has agreed that all tasks have been identified, it is misleading to develop a schedule. You cannot be sure that the critical path identified by a partial schedule will be the same for the full schedule.
There are a number of approaches to developing the WBS. Ideally, you proceed top-down, following development of a good problem statement and mission statement. As I have mentioned, however, the mind does not always operate in such nice, linear fashion; as you develop the WBS, you may sometimes find that it helps you to understand the job better. For that reason, I am not a purist about doing things in a specific order. You do what works best for you.
A WBS does not have to be symmetrical. All paths do not have to go down to the same level.
The WBS does not have to be symmetrical. That is, all paths need not be broken down to level 6 (or whatever level you stop at). Since the rule is to break work down to a level sufficient to achieve the estimating accuracy you desire, one path may take six levels, while another may need only three.
Uses of the WBS
As I have said, the WBS is a good way to show the scope of a job. If you have ever given someone an estimate for project cost or time and seen the person’s horrified look, you know that they are seeing the project in their mind as much simpler than it is. When you show a project in WBS form, it is clear to most individuals why the job costs so much. In fact, I have had the experience of the planning group members themselves being overwhelmed by the complexity and magnitude of the WBS. If it impresses them, think of the impact on the outsider.
The WBS is a good way to portray the scope of a project.
Assigning responsibility for tasks is another important use of the WBS. Each task to be performed should be assigned to a particular person who will be responsible for its completion. These assignments can then be listed on a separate form, often called a Responsibility Chart (see Figure 5-4).
