6 April, 2011. Techniques to Create a Work Breakdown Structure (WBS)
There are two types of WBS's - a deliverable-based WBS and an activity-based WBS. The deliverable-based WBS goes down to the deliverable or work package level. The activity-based WBS contains the activates needed to create the deliverables.
When the team is creating the activity-based WBS, there are usually questions about how small the detailed work activities should be. The answer determines when to stop breaking the work down into smaller activities. Part of the answer is to utilize an overall estimating threshold. This threshold is a maximum size (in effort hours) that an activity should be. Once you are under that threshold you can stop breaking the work down further. For instance, if your threshold is 80 hours, you can stop breaking down the work further once you have activities that are less then 80 hours.
Other things to take into account include:
The activity should contain sub-activities that are related and continuous. For instance, if you had an activity called 'Create Testing and Training Strategy', it probably should be broken down further, since the Testing Strategy and Training Strategy are not necessarily related and they are not necessarily continuous.
The activity should be able to be completed by one person, or one group of related people. If you have an activity that requires different people for different sub-activities, then it should be further broken down into the sub-activities so that a person or the same group of people can complete the entire activity. Remember that the detailed activities ultimately are carried over to the schedule. You don’t want to have one schedule activity that is assigned to two different groups, or two unrelated people.
In general, the work should be broken down to a level that makes sense for the project manager to control. Theoretically, the schedule could be broken down to a point where each activity was one or two hours. Obviously, it does not make sense to break the work down to this level. The assigned team member will not need the work described at that level of detail and the project manager does not need to manage the work at that level.
Other techniques are described below.
Do Not Make the WBS Too Tall
If you envision the WBS being built with Post-it notes on the wall, it is important that you not let the WBS get too tall (or too deep). Depending on your WBS approach, it may take you one to three levels to get the deliverables defined. The general rule of thumb is that the number of levels for each deliverable should not exceed five and even five might be too many. Smaller projects may not need more than two or three levels of activities for each deliverable. If you have a very large project, the levels might be deeper. However, there is a point where the detail will be too complex to manage. If you find that you are defining down to five or more levels of activities for a deliverable, stop and evaluate what you are doing. First, you may be defining the work at too low a level. Second, you may have defined your deliverable too broadly. In that case, see if a large deliverable can be broken up into smaller, integrated pieces. The work associated with the smaller deliverables should not require so many levels.
Break Large Projects into Phases and Stages
There are differing terms used to describe the ways that large projects can be divided and subdivided. A couple of the common terms are phases and stages. There may not be universally recognized definitions for these terms, but in general they mean the following.
Stage: This is the easier term. This is usually always used to signify an internal breakdown of work on one project. For instance, you might refer to the gathering of business requirements, and all related work, as the Analysis Stage. Similarly, if your project requires the building of a prototype, you might call this the Prototype Stage.
Phase: Phases can have two meanings. First, in many cases, the word 'phase' means exactly what was just described as a ‘stage’. For instance, a project may have a Requirements Phase or a Prototype Phase. In that context, phase refers to a high-level breakdown of internal work. If the term 'stage' is also used, it refers to a further subdivision of a phase. For instance, in the Analysis Phase, there may be a Business Requirements Stage and a Strategy Definition Stage.
The second use of the term “phase” refers to a series of independent but related projects. For instance, the original execution of a project to deliver basic functionality might be referred to as Phase I. A subsequent project to add more functionality might be called Phase II. A rollout of the package might be Phase III. In all these cases, the term 'phase' is used to imply a separate project, but one that is related to similar projects in a series that come before it and after it.
The names of the term is not as important as the concept to group related chunks of work together.
Create a Work Breakdown Structure Dictionary for Large Projects
Normally a dictionary would not be needed, but if your WBS has hundreds (or thousands) of detailed activities, there may just be too much to keep track of by hand. If the WBS is very large, it might make sense to place all of the important information in a data dictionary. The dictionary helps keep track of all of the summary and detailed activities, including a short description, the WBS numeric identifier (1.1, 1.1.1, 1.1.2, etc.) and the estimated effort. Once the WBS information is entered into a tool, the tool can also help to keep track of changes to the work so that you can trace how the change impacts the WBS and the schedule. Having the WBS in a tool also makes the information easier to reuse for future projects.
Use Your Summary Activities for Schedule Milestones
Your WBS contains both detail and summary activities. When you create the network diagram in your schedule, however, you should only include the detailed activities, not the summary ones. For the sake of clarity and readability, it often makes sense to include these higher-level summary activities in the schedule as well to represent a logical roll-up of the detailed activities. A summary activity that represents the completion of a major deliverable could also be included in the schedule as a milestone. |
