Techniques to Build a Work Breakdown Structure

Break Summary Activities into Two or More Detailed Activities

Since you chose to break a summary activity into smaller activities, it does not make sense to only have one detailed activity under a summary one. If you do, the detailed activity represents the exact same work as the summary activity. This does not buy you anything. If this occurs in your WBS, you either need to:

Break the summary activity into multiple smaller tasks

Get rid of the detailed activity and associate the work with the summary – which now becomes a detailed activity

The Detailed Activities Should be Written as Action Oriented Activities

The detailed activities on your WBS are carried down to be the activities in your schedule. For that reason, it is easier if the detailed activities in your WBS are action oriented – just as activities in your schedule would be. For example instead of stating a detailed WBS activity as “meeting”, you should state it as “schedule a weekly meeting”, or “attend a weekly meeting”. Instead of having a WBS detailed activity for “Testing Plan”, you should state it instead as “Create Testing Plan”. In this way, the detailed activities can be moved to the schedule with a minimum of wording changes.

Do Not Place Requirements on the WBS

The WBS is used to break down larger pieces of work into smaller pieces of work. If you place a deliverable on your WBS, you can break this deliverable down into the activities that are required to create it. You do not break a deliverable down into the requirements that describe it. Requirements do not belong on a WBS.

The detailed activities from your WBS are moved to your schedule. The schedule does not contain items such as “needs to have simple interface” or “must be able to work 25 feet below water”. These are requirement statements. Requirements belong in the Requirements Management Plan. They do not belong on the schedule or in the WBS.

You Can Leave Your WBS at the Work Package Level for Large Projects

Very large projects generally have very large deliverables. One way to build your WBS on these projects is to define your deliverables and then break your deliverables into work components. Work components are simply smaller portions of a large deliverable. When all of the smaller work components are completed and integrated, the larger deliverable is also created.

Sometimes on very large projects it is not practical to determine the summary and detail activities because there are just too many of them. On these very large projects, the WBS may only be broken down to the work component or “work package” level. This work package level may be very large – perhaps big enough to be a sub-project and probably big enough to have a cost account associated with it.

If you have a large project, you may stop the WBS at the work package level. However, the work should still not be assigned to team members at that level. The work package should be assigned to a team. The team leader should take the work package and break the work down to the activities required to actually build the work component (or to complete the entire scope of work in the work package).

In this scenario, the full WBS is still created down to the detailed level of activities. However, it is done in two parts – the first iteration stops at the high-level work package, and then the detailed activities are defined when the work package is actually assigned to a work team.

tenstep