Chapter 5: Work Breakdown Structure

Work Breakdown Structure

If we are going to get any project done, we must follow a hierarchical process of first defining the goal, objectives and measures, then defining the major steps which need to be taken to meet that goal. This gives us an overall perspective on where we are going, but it is not enough to clearly plan out what the activities are going to be. To complete the plan, we need to develop a work breakdown structure for the project.

The work breakdown structure takes the systems development lifecycle and develops it into a set of specific activities. It is the basis for all of the estimating and scheduling which needs to be done. It can also be the basis for defining the budget for each activity and assigning responsibilities.

The key to developing a work breakdown document is to carefully define all of the activities which are going to take place in the project. This is the foundation for our overall project plan.

The activities must be developed with the lifecycle as a base so that we have the upper level tasks which can help define each of the activities for the project. These activities can then be further broken down into tasks and subtasks and even sub-subtasks. We want to define the project down to a level where it is manageable. A project is manageable when we have broken down our tasks to the point where they are clearly independent from each other, can be assigned to one person or a small group of people and are easy to measure.

This "bottom" level of the work breakdown structure is impossible to define in one single way for all projects. You do not necessarily need to break down every project to the fourth, fifth or sixth level. If you break down large projects into too fine a level of detail, you will find yourself "micro-managing" and lose yourself in the details. On the other hand, if you do not break the project down far enough, you will not be able to effectively estimate, schedule, and assign responsibilities. What we are trying to do is break down the project to the convenience level - a level of detail that is sufficient to allow us to manage the project, but not get lost in the detail.

For example, in most information systems projects we want to make sure that we have a clear idea of the requirements for the system. Typically this will be the second major phase in the project, right after the project initiation has been completed. In defining the activities for this phase, we would follow the suggestions from our systems development lifecycle and include the following major activities:

Define current system

Interview current users

Document business functions

Define initial costs and benefits

Define organizational implications

Define overall work plan

Each of the these activities is then further broken down into a set of tasks, using either a hierarchical or indented structure method. For example, the second activity, interviewing users, might be broken down into the following tasks:

Schedule interviews

Hold interviews

Document interviews

Those tasks might further be broken down into sub-tasks, depending on the size of the project:

Interview current users

Schedule interviews

Obtain management approval

Schedule meeting rooms

Identify interviewees

Create questions

Schedule interviews

Hold interviews

Interview each user

Review interview notes with users; make corrections

Document interviews

Collate interview notes

Verify problem areas

Write interview documentation

Publish interview results

Obviously, as the work breakdown structure is being developed, the project manager is going to need the assistance of the people who are going to be doing the work. They will be able to help you define the work steps along with their scope and sequence. A project manager can effectively plan one or two levels below his or her own level - beyond that you need help. Besides, having the people who will do the work assist in the planning helps get them interested and involved in the project.

Each of the work breakdown steps should be a clear definition of the work that is going to be accomplished at a specific point in the project. The beginning and end points for the work units should be clearly specified and they should be clearly distinguishable. Each of these work units should also be budgetable in terms of money, labor hours, and indirect costs.

Since each of the individual work units is a separate, meaningful job, they should also have specific expectations and measurable results tied to them. That way you, as project manager, will be able to tell when a particular part of the project is supposed to start, when it will end, and whether or not it was done correctly.

Each of the levels of the work breakdown structure should be thought out carefully. When changes are made to the work units, those changes should be cross-checked with the individuals who helped define them. As all elements of the WBS are defined, the need for those changes will become evident. Getting the individuals who helped define parts of the WBS to sign off on the changes will help maintain the commitment to the whole.

Each level of the WBS should be at approximately the same level of generality. For each level, such as the phases of the lifecycle, try to keep the number phases to less than 20. This helps you keep track of all those phases more easily. If the number of phases, activities, or tasks gets too great at any one level, it becomes difficult to maintain control. Also, make sure that you are defining tasks in the WBS, not events or outcomes. Events may mark the beginning or end of an activity, and as such be represented as milestones in the overall project plan.

You can begin developing your WBS using the phases of the lifecycle and then successively break down tasks into finer levels of detail. Continue until all the meaningful tasks have been identified and meets the criteria laid out above.

For each of the identified tasks you can make up the necessary task elements, defining what the work unit is, any vendors or contacts, budget numbers, responsible parties and precedence relationships. Precedence relationships are especially important because they form the basis for developing schedules and PERT charts.

Once you have defined all of the work units in the project, you can then begin the estimation and scheduling process. Once the estimates and budgets have been defined at the lowest level of the project, you can then start summing up the costs and time estimates to successively higher levels. This allows you to estimate the overall time and cost for the project. The WBS is then the basis for: