THE WORK BREAKDOWN STRUCTURE

Once the business case has been approved, it is important for the project manager to move quickly on to the development of the work breakdown structure. The work breakdown structure is the structure that all project work is set against. It takes the existing plans and breaks them into manageable groups of work. For example, developing a software package might be broken into development, testing, project management and requirements management. There are many ways to define the work breakdown structure for a project but the method explained here normally proves effective.

To transform the existing plans into a work breakdown structure you need to use the schedule (or Gantt chart) developed as part of the macro plan. The schedule is likely to appear like a much larger version of the one shown in Figure 2.5.

Figure 2.5: Macro plan

The first step in changing this schedule into a work breakdown structure is rotating the schedule by 90 degrees. This is shown in Figure 2.6.

Figure 2.6: WBS - first pass

The chart can now be interpreted as showing five potential work packages, task group 5 running from March till May to task group 1 running from January to April. With a simple chart like this one it seems obvious that each of the task groups should be managed as a separate work package. However, a full plan for a real project would have many more task groups than five. When this happens it makes sense to group tasks together. There are several possible reasons for combing task groups together into a single work package:

• time;

• resource;

• similar work content.

Time

In general, projects run to a given life cycle like the one shown in Figure 2.7. This shows the general work flow that a project will follow is: requirements work, development work, testing work and finally release work. The curves related to each phase depict the amount of effort that is expended by the project team on an activity at any given moment in time. At the start of the project the majority of the work is focused on requirements. This focus rapidly changes into a focus on development work. This shift in attention happens since the project team will start to work on implementing requirements as soon as they are agreed. They do not wait for all the requirements to be completed before they start work on implementation. Similarly with the testing phase, the testers do not wait for all the development to complete before starting their work. Instead they begin planning as soon as is practicable. As the testing phase completes, the final stage, the release phase, starts. The end of the release phase is the end of the project.

Figure 2.7: Gradual work ramp-up in all areas

Knowing that the work in a project occurs in this manner allows the project manager to consider grouping tasks solely on the basis of where they occur in time. If task groups occur at the start of a project then it is likely that they are involved in requirements capture. If they occur at the end it is likely that they are related to the testing or release phases.

Returning to Figure 2.6 and examining it in this way reveals that task group 2 and task group 4 are related in time. Both have similar timescales for completion. It is therefore likely that the work they will be performing will be related. Therefore it would be worth considering joining these two task groups together to form one work package.

Using the time-based approach to forming work packages enables project managers to focus on the current work because the current work will be grouped together in the same work package. If project managers keep the number of work packages small, between six and eight in total, then they will only have to focus on one or two work packages at any moment in time. So using the time-based approach ensures that project managers are able to spend significant time on the current work. They will not be in the position of worrying about other work not receiving sufficient attention.

Resource

Although the time-based approach to setting up a work package has advantages, it also has difficulties. The principal difficulty arises because tasks are all different in size and volume of work. In Figure 2.6 it is possible that task group 2 and task group 4 may be double the size of all the other tasks. This can be seen visually in Figure 2.8, which relates Figure 2.6 to Figure 2.7.

Figure 2.8: Life cycle related to tasks

Task group 1 seems likely to be the activity associated with the requirements phase. Task group 2 and task group 4 seem likely to be the activities associated with the development phase. Task group 5 seems likely to be the testing phase activities and task group 3 the release phase activities. If this is the correct interpretation then task group 2 and task group 4 are likely to account for the majority of the volume of work. This makes it less sensible to merge the two task groups into one work package. It would be more sensible to spread the resources evenly across all of the work packages. Levelling the resources in the work packages helps to reduce the number of management levels needed for successful control. Reducing the number of levels in turn reduces the risk of failure. To overcome this difficulty in setting up work packages, some method of levelling the volume of work across the proposed work packages needs to be used.

To level the volume of work on its own is not a difficult task. The project manager should first set up the work packages by the time-based method previously explained. Once this is complete each work package should be examined in relation to the amount of resource being applied to it. Where a work package is grossly different to the other work packages then the project manager should consider splitting it into two work packages.

In addition to examining work packages for over-allocation of resource volumes, the project manager should examine them for under-allocation of resource volumes. A sample table of potential resource volumes for five work packages is shown in Figure 2.9.

Figure 2.9: Work package resource levels

Joining task group 2 and task group 4 would not be sensible for the scenario shown in Figure 2.9. Joining them would create a very large work package in relation to the other proposed work packages. Neither would it be sensible to have separate work packages for task groups 1, 3 and 5 since the resultant work packages would be under-allocated. Instead to avoid the over-allocation (joining task groups 2 and 4) and under-allocation (single work packages for task groups 1, 3 and 5) it would be more reasonable to create three work packages: one work package that combines task groups 1, 3 and 5, one work package for task group 2 and one work package for task group 4.

Similar work content

Deciding on work packages only on the basis of position in time and volume of resources fails to account for the work content of the task grouping. In many cases this will not pose a problem since the natural life cycle of the project will ensure that like activities are grouped together. However, problems can and do arise. The final work package configuration for the case considered above joined together three work packages on the basis of their resource levels. However, a different combination could have been achieved that might have ensured a smoother project.

Joining task group 1 and task group 2 (or alternatively task group 1 and task group 4) would have allowed the creation of a work package that is more likely to have similar work activity. Both task group 2 and task group 4 occur at the start of the project along with the end of task group 1. All are likely to be involved in requirements work. Where this similarity of activity can be achieved, it helps to reduce the risk of project failure. A common goal in relation to work activity ensures that resources are more likely to be able to support one another should something go wrong. Similarly, at the other end of the timescale it would perhaps be more sensible to join task groups 3 and 5 together.

Once project managers have assessed the project task groups from the three different perspectives they should be in a position to produce a draft work breakdown structure. The work breakdown structure is normally drawn as shown in Figure 2.10.

Figure 2.10: WBS outline

Although this diagram shows the work packages as discrete areas of work, they should not be thought of in this manner. It is important to remember that each of the work packages is related to the others. This is clearly illustrated by Figure 2.8, which shows the overlapping nature of the work in each phase. For example, task group 3 is the release activity and task group 5 the testing activity. Clearly task group 3 needs to start whilst task group 5 is in progress if unnecessary delay is to be avoided. You need to remember this when developing the detailed levels of the work breakdown structure.