Detail and Summary Activities
If you look at a WBS activity and determine that it needs to be broken down to another level, the original activity becomes known as a “summary” level. A summary activity does not have any work or hours specifically associated with it. It represents a logical roll-up of the activities that are under it.
On the other hand “detailed” activities are those that have not been broken down further
Summary activities are broken down into detailed activities. Therefore once the detailed activities are under the summary activity are completed, the summary activity is also considered to be completed. If there is more work required, then additional detailed activities must be added under the summary.
Use the Post-It Note Approach for Collaboratively Creating the WBS
It might surprise you to know the number of people that use Post-it pads and a blank wall to create the first draft of the Work Breakdown Structure. This technique is very easy. You first get the appropriate people into the same room. These are the project team members and clients who have the expertise to build the WBS. Typically you start off by writing the names of the major deliverables on Post-it notes – one deliverable per note. Make sure the attendees agree on the major deliverables to begin with. If any of the deliverables are very large, you can create new Post-it notes that describe the deliverables at a lower level, or individual work package. These are arranged under the higher-level deliverable. The deliverable needs to be identified at a level low enough that you understand what it takes to build it. In general two levels should be enough to describe the deliverables.
At this point you have a deliverable-based WBS. You can break the work down further into an activity-based WBS as described below.
For each deliverable or work package, describe the activities that must take place to complete it. Each activity goes on a separate Post-it note. These activities are arranged under the specific deliverable they refer to. If you have a sense for the order that the activities need to be completed, you can arrange the Post-it notes sequentially. However, this is not important at this point. The important thing is to identify all the work.
Look at the activities that are required to build each deliverable or work package and estimate the work associated with each activity. If the effort associated with an activity is larger than your estimating threshold, identify the more detailed activities that make up the higher-level one. Each of these activities is represented by new Post-it notes under the higher-level activity (which now becomes a summary activity). Continue with this process until the work required to complete all of the deliverables is defined, as best you know today. The levels of activities will not be the same for each deliverable. Some simple deliverables may meet the threshold criteria in one or two levels. Others may take three or four, or more levels.
The advantage of this approach is that your team can visually see the work and they can help ensure all the work is identified to complete the project. The Post-it sheets also give you the ability to easily move things around. If you add an activity and then decide to remove it, you just pick up the Post-it sheet. Likewise, if a deliverable or group of activities is in the wrong place, you just move the Post-it notes to where they need to be.
When you are all done, you can enter the summary and detailed work activities into your scheduling tool.
A Common Approach is to Identify Deliverables in the First or Second Level, and Then Identify Activities
Sometimes people have a hard time getting a WBS started because they are not sure what to put at the very top and they are uncertain about how to break the work down from there. Although there are many ways that the WBS can be started, ultimately you want to focus on deliverables. If you assume that the top level is the overall project (level 0), then the next level can start to describe the main deliverables. After the deliverables are described, the activities can be defined that are required to build the deliverables. The project schedule is ultimately made up of activities, but the activities need to be listed in the context of completing deliverables.
There are a number of options for defining the WBS at level 1 (under the top level 0).
It might make sense to place the major project deliverables directly at level 1, and break the deliverables into smaller components on the next level, if necessary.
Another option for level 1 is to describe the organizations that will be involved, such as Sales, Marketing, IT, etc. The next level should describe the deliverables that each organization will produce.
A third option is to look at level 1 in terms of the project life cycle; for instance analysis, design, development, testing, etc.
Again, if that is the best logical way to look at level 1, then level 2 should describe the deliverables produced in each life cycle stage.
You see that level 1 can start with deliverables or level 1 can describe another way to logically group major portions of the project. However, if you choose another way to initially organize your thinking of the project, you need to transition quickly from there to deliverables and then move to the activities necessary to build the deliverables.
Tenstep