Building the WBS

,

The WBS is a hierarchical description of all work that must be done to complete the project as defined in the RBS. Recognize that the RBS documents in detail the deliverables needed to produce the expected business value as described in the POS. The WBS is a further decomposition of the RBS components and describes in detail how those components will be created. In other words it defines the work of the project. Several processes can be used to create this hierarchy. They are described in this section.

The Requirements Breakdown Structure (RBS) is the input to constructing the WBS. If the RBS is complete, then a traditional approach to project management can be taken and the complete WBS developed. This chapter describes how to build a complete WBS. However, in most cases the RBS will not be complete, and therefore, the WBS will not be complete, and some other project management approach will have to be taken. Those are discussed later in Chapters 10, 11, and 12, which consider all of the exceptions.

Using the RBS to Build the WBS

One of the major benefits of the RBS is that it can dramatically reduce the work and improve the effectiveness of the WBS. Figure 5-2 is the RBS graphical depiction first introduced in Chapter 4.

Figure 5-2: The RBS

Excluding the “Feature” level for the moment, the lowest level of decomposition in the RBS constitutes the level “n” Activities defined in the WBS in Figure 5-3. So using Figure 5-2 as the actual RBS Function 1.1, Sub-Function 1.2.1, Process 1.2.2.1, Activity 1.2.2.2.1, and Activity 1.2.2.2.2, are the lowest level of decomposition in the RBS. The tasks needed to build these deliverables would define the WBS as shown in Figure 5-3.

Activities as shown in Figure 5-3 are simply chunks of work. The decomposition of these chunks of work continues for each chunk until the lowest level of decomposition meets the six criteria tests for completion and then no further decomposition of that chunk is needed. Although not shown in Figure 5-3 the second term is task. The lowest level of decomposition that meets the six completion criteria is called a task rather than an activity. The term task is used to differentiate the chunk of work it defines from all other chunks of work that are called activities. Although these definitions may seem a bit informal, the difference between an activity and a task will become clearer shortly.

Figure 5-3: Hierarchical visualization of the WBS

The terms “activity” and “task” have been used interchangeably among project managers and project management software packages. Some think of activities as being made up of tasks, others say that tasks are made up of activities, and still others use one term to represent both concepts. In this book, I refer to higher-level work as activities. An activity is composed of two or more tasks. When the tasks that make up an activity are complete, the activity is complete.

Another term is work package. A work package is a complete description of how the tasks that make up an activity will actually be done. It includes a description of the what, who, when, and how of the work. Work packages are described in more detail in Chapter 6.

Decomposition to the task level is important to the overall project plan because it enables you to estimate the duration of the project, determine the required resources, and schedule the work. By following the decomposition process, activities at the lowest levels of decomposition will possess known properties that enable you to meet planning and scheduling needs.

This process of decomposition is analogous to the process many students use in school for writing research papers. Despite the teacher's extolling the value of preparing a detailed outline before writing the paper, the student chooses to do it the other way around — writing the paper first and extracting the outline from it. That won't work in project planning. You have to define the work before you set out to do it.

Those who have experience in systems development should see the similarity between hierarchical decomposition and functional decomposition. In principle, there is no difference between a WBS and a functional decomposition of a system. My approach to generating a WBS departs from the generation of a functional decomposition in that I follow a specific process with a stopping rule for completing the WBS. I am not aware of a similar process for generating the functional decomposition of a system. Veterans of systems development might even see some similarity to older techniques such as stepwise refinement or pseudo-code. These tools do, in fact, have a great deal in common with the techniques I use to generate the WBS.

Uses for the WBS

The WBS has four uses: as a thought-process tool, an architectural-design tool, a planning tool, and a project-status-reporting tool. The following sections describe how to use the WBS for each of these purposes.

Thought-Process Tool

First, and maybe foremost, the WBS is a thought process. As a thought process, it is a design and planning tool. It helps the project manager and the planning team visualize exactly how the work of the project can be defined and managed effectively. It would not be unusual to consider alternative ways of decomposing the work until an alternative is found with which the project manager is comfortable.

Architectural-Design Tool

When all is said and done, the WBS is a picture of the work of the project and how the items of work are related to one another. It must make sense. In that context, it is a design tool.

Planning Tool

In the planning phase, the WBS gives the planning team a detailed representation of the project as a collection of activities that must be completed in order for the project to be completed. It is at the lowest activity level of the WBS that you will estimate effort, elapsed time, and resource requirements; build a schedule of when the work will be completed; and estimate deliverable dates and project completion.

Project-Status-Reporting Tool

Although this is not a common use of the WBS, it has been used as a structure for reporting project status. The project activities are consolidated (that is, rolled up) from the bottom as lower-level activities are completed. As work is completed, activities will be completed. Completion of lower-level activities causes higher-level activities to be partially complete. Shading is often used to highlight completed tasks and activities. Some of these higher-level activities may represent significant progress whose completion will be milestone events in the course of the project. Thus, the WBS defines milestone events that can be reported to senior management and the client.

In the final analysis, it is the project manager who decides on the architecture of the WBS and the level of detail required. This detail is important because the project manager is accountable for the success of the project. The WBS must be defined so that the project manager can manage the project. That means that the approach and detail in the WBS might not be the way others would have approached it. Apart from any senior management requirements for reporting or organizational requirements for documentation or process, the project manager is free to develop the WBS according to his or her needs and those of management. Because of this requirement, the WBS is not unique. That should not bother you because all that is required is a WBS that defines the project work so that you, the project manager, can manage it. “Beauty is in the eyes of the beholder” applies equally well to the choice of which of several approaches to building the WBS is the best choice. As project manager you have the responsibility of making that choice.

Generating the WBS

The best way to generate the WBS is as part of the JPPS. You'll learn the steps as you look at two different approaches to building the WBS in this section. Before I discuss those approaches, I want to remind you of where you are in the planning process and then offer a few general comments about procedures I have followed in my practice regardless of the approach taken.

At this point in the planning process, you should have completed the RBS and have an approved POS. You may have to go back and reconsider the POS as a result of further planning activities, but for now assume the POS is complete. My technique for generating the WBS will reduce even the most complex project to a set of clearly defined activities. The WBS will be the document that guides the remainder of the planning activities.

As many as 10 to 20 participants may be involved in building the WBS, so gathering around a computer screen won't do the job. Neither will projecting the screen on an overhead LCD projector. The only way I have found that works consistently is to use sticky notes, marking pens, and plenty of whiteboard space. In the absence of whiteboard space, you might wallpaper the planning room with flip-chart or butcher paper. You cannot have too much writing space. Using butcher paper, I have even filled the four walls of the planning room and several feet of hallway outside the planning room. It is sloppy, but it gets the job done.

Converting the RBS to the WBS

This approach begins at the lowest levels of decomposition in the RBS. From that point each of these deliverables is hierarchically decomposed to one or more levels of work detail until the participants are satisfied that the work has been sufficiently defined. The completion criteria discussed later in this chapter is the guide to the decomposition exercise for this approach.

After the project work activities have been defined using this approach guided by the completion criteria, they are defined at a sufficient level of detail to enable the team to estimate time, cost, and resource requirements first at the activity level and then aggregated to the project level. Because the activities are defined to this level of detail, the project time, cost, and resource requirements are estimated much more accurately.

Because every work activity at the lowest level of work decomposition appears as a manageable activity in the project plan, there is good reason to not define work at a level that is too detailed so that it is more of a management burden than it is worth. For that reason the team should look for opportunities to “roll up” the work to less detailed levels while being cognizant of the completion criteria.

I have used and can recommend two variations of this approach: the team approach and the subteam approach. I have used both in my consulting practice.

Team Approach

Although it requires more time to complete than the subteam approach, the team approach is the better of the two. In this approach, the entire team works on all parts of the WBS. For each of the lowest levels of decomposition in the RBS, appoint the most knowledgeable member of the planning team to facilitate the further decomposition to the work level of that part of the RBS. Continue with similar appointments until the WBS is complete. This approach enables all members of the planning team to pay particular attention to the WBS as it is developed, noting discrepancies in real time.

Subteam Approach

When time is at a premium, the planning facilitator may choose to use the subteam approach. The first step is to divide the planning team into as many subteams as there are requirements in the RBS. Assigning similar requirements to the same team is okay too. Then follow these steps:

1. Each subteam begins further decomposition to the work level for the part of the RBS associated with the requirement(s) assigned to them
2. Each subteam reports its results to the entire team. The entire team is looking for overlaps between their results and the reporting subteam's, missing work, and scope boundary issues.
3. The entire WBS is approved by the team.

It is important to pay close attention to each presentation and ask yourself these questions: Is there something in the WBS that I did not expect to see? Is there something missing from the WBS that I expected to see? The focus here is to strive for a complete WBS. In cases where the WBS will be used for reporting purposes, the project manager must be careful to attach lower-level activities to higher-level activities to preserve the integrity of the status reports that will be generated.

As the discussion continues and activities are added and deleted from the WBS, questions about agreement between the WBS and the POS will occur. Throughout the exercise, the POS should be posted on flip-chart paper and hung on the walls of the planning room. Each participant should compare the scope of the project as described in the POS with the scope as presented in the WBS. If something in the WBS appears out of scope, challenge it. Either redefine the scope or discard the appropriate WBS activities. Similarly, look for complete coverage of the scope as described in the WBS with the POS. This is the time to be critical and carefully define the scope and work to accomplish it. Mistakes found now, before any work is done, are far less costly and disruptive than they will be if found late in the project.

The dynamic at work here is one of changing project boundaries. Despite all efforts to the contrary, the boundaries of the project are never clearly defined at the outset. There will always be reasons to question what is in and what is not in the project. That is fine. Just remember that the project boundaries have not yet been set in concrete. That will happen after the project has been approved to begin. Until then, you are still in the planning mode.

Using the WBS for Large Projects

For very large projects, you may be tempted to modify the preceding approach. Although I prefer to avoid modification, difficulty in scheduling people for the planning meeting may necessitate some modification. This brief section describes a modification that serves this situation well.

As project size increases, it becomes unwieldy to build the entire WBS with the all of the planning team assembled in a single planning session. My rule of thumb is to partition the project into subprojects whenever the planning team has more than 30 members. Each requirement or group of similar requirements can be assigned to a subteam. A temporary program office can be established for managing the entire project. Each subproject manager is accountable to the program office manager.

Iterative Development of the WBS

After the RBS has been built, you choose the best-fit PMLC. Depending on your feeling about the degree of completeness of the RBS, you will choose one of the six approaches: Linear, Incremental, Iterative, Adaptive, Extreme, or Emertxe. As discussed in Chapter 2, the less you know about the RBS and the less certain you are that the client has been able to define the solution, the more likely you are to choose an approach toward the Adaptive and Extreme part of the landscape. The Linear and Incremental approaches require a complete WBS. The Iterative approach can work in cases where all of the functions and sub-functions have been defined and only a few processes, activities, and features have not. These will be eventually described at the lower levels of decomposition of the WBS, but they will not be completely defined at the outset. When there are missing or incomplete functions and sub-functions, an Adaptive approach should be used, and the WBS will have large gaps that need to be defined through iteration. Finally, when even the goal is not clearly defined, very little of the WBS can be built at the beginning of the project. Both the goal and solution (functions and features) must be defined through iteration.

Six Criteria to Test for Completeness in the WBS

Developing the WBS is the most critical part of the JPPS. If you do this part right, the rest is comparatively easy. How do you know that you've done this right? Each activity must possess the following six characteristics in order for the WBS to be deemed to be complete — that is, completely decomposed. When an activity has reached that status, it changes from an activity to a task. The six characteristics that an activity must possess to be called a task are as follows:

• Status and completion are measurable.
• The activity is bounded.
• The activity has a deliverable.
• Time and cost are easily estimated.
• Activity duration is within acceptable limits.
• Work assignments are independent.

If the activity does not possess all six of these characteristics, decompose the activity and check it again at that next lower level of decomposition. As soon as an activity possesses the six characteristics, there is no need to further decompose it. As soon as every activity in the WBS possesses these six characteristics, the WBS is defined as complete. The following sections look at each of these characteristics in more detail.

Status and Completion Are Measurable

The project manager can question the status of an activity at any point in time during the project. If the activity has been defined properly, that question is answered easily. For example, if a system's documentation is estimated to be about 300 pages long and requires approximately four months of full-time work to write, here are some possible reports that your activity manager could provide regarding the status:

• The activity is supposed to take four months of full-time work. I've been working on it for two months full-time. I guess I must be 50 percent complete.
• I've written 150 pages, so I guess I am 50 percent complete.
• I've written and had approved 150 pages and estimate that the remaining work will require two more months. I am 50 percent complete.

No one would buy the first answer, but how many times is that the information a project manager gets? Even worse, how many times does the project manager accept it as a valid statement of progress? Although the second answer is a little better, it doesn't say anything about the quality of the 150 pages that have been written, nor does it say anything about the re-estimate of the remaining work. You can see that an acceptable answer must state what has been actually completed (that is approved, not just written) and what remains to be done, along with an estimate to completion. Remember that you'll always know more tomorrow than you do today. After working through about half of the activity, the activity manager should be able to give a very accurate estimate of the time required to complete the remaining work.

A simple metric that has met with some success is to compute the proportion of tasks completed as a percentage of all tasks that make up the activity. For example, if the activity has six tasks associated with it and four of the tasks are complete, the ratio of tasks completed to total tasks is 4/6 — that is, the activity is 60 percent complete. Even if work is done on the fifth task in this activity, because the task is not complete on the report date, it cannot be counted in the ratio. This metric certainly represents a very objective measure. Although it isn't completely accurate, it is a good technique. Best of all, it's quick. A project manager and activity manager do not have to sit around mired in detail about the percentage complete. You can use this same approach to measure the earned value of an activity.

The Activity Is Bounded

Each activity should have a clearly defined start and end event. After the start event has occurred, work can begin on the activity. The deliverable is most likely associated with the end event that signals work is closed on the activity. For example, the start event for systems documentation might be notifying the team member who will manage the documentation creation that the final acceptance tests of the system are complete. The end event would be notifying the project manager that the client has approved the systems documentation.

The Activity Has a Deliverable

The result of completing the work that makes up the activity is the production of a deliverable. The deliverable is a visible sign that the activity is complete. This sign could be an approving manager's signature, a physical product or document, the authorization to proceed to the next activity, or some other sign of completion. The deliverable from an activity is output from that activity, which then becomes input to one or more other activities that follow its completion.

Time and Cost Are Easily Estimated

Each activity should have an estimated time and cost of completion. Being able to do this at the lowest level of decomposition in the WBS enables you to aggregate to higher levels and estimate the total project cost and the completion date. By successively decomposing activities to finer levels of granularity, you are likely to encounter primitive activities that you have performed before. This experience at lower levels of definition gives you a stronger base on which to estimate activity cost and duration for similar activities.

Activity Duration Is Within Acceptable Limits

Although there is no fixed rule for the duration of an activity, I recommend that an activity have a duration of less than two calendar weeks. This seems to be a common practice in many organizations. Even for long projects in which contractors may be responsible for major pieces of work, they will generate plans that decompose their work to activities with a two-week or shorter duration. Exceptions will occur when the activity defines process work, as is the case in many manufacturing situations. In addition, there will be exceptions for activities involving work that's repetitive and simple. For example, if you are going to build 500 widgets and it takes 10 weeks to complete this activity, you need not decompose it into five activities with each one building 100 widgets. This type of activity requires no further breakdown. If you can estimate the time to check one document, then it does not make much difference if the activity requires two months to check 400 documents or four two-week periods to check 100 documents per period. The danger you avoid is longer-duration activities whose delay can create a serious project-scheduling problem.

Work Assignments Are Independent

It is important that each activity be independent. An activity should continue reasonably well without interruption and without the need for additional input or information until the activity is complete. The work effort could be contiguous, but it can be scheduled otherwise for a variety of reasons. You can choose to schedule it in parts because of resource availability, but you could have scheduled it as one continuous stream of work.

Related to activity independence is the temptation to micromanage an activity. Best practices suggest that you manage an individual's work down to units of one week. For example, Harry is going to work on an activity that will require 10 hours of effort. The activity is scheduled to begin on Monday morning and be completed by Friday afternoon. Harry has agreed that he can accommodate the 10 hours within the week, given his other commitments that same week. Harry's manager (or the project manager) could ask Harry to report exactly when during the week he will be working on this 10-hour activity and then hold him to that plan, but what a waste of everyone's time that would be! Why not give Harry credit for enough intelligence to manage his commitments at the one-week level? No need to drill down into the workweek and burden Harry with a micro-plan and his manager with the task of managing that micro-plan. Such a scenario may in fact increase the time to complete the activity because it has been burdened with unnecessary management overhead.

The Seventh Criterion for Judging Completeness

I've separated this from the preceding six criteria because it is not a criterion in the same sense as they are. This seventh “criterion” is pure judgment on the part of the project manager. A WBS could be defined as complete based on the preceding six criteria, yet the project manager might have a lingering doubt simply because of the way the client conducted themselves during the WBS decomposition process. Something might alert the project manager that things may not be what they seem to be. For example, perhaps the client never seemed to be fully engaged or never bought into the decomposition process. They simply went along with the exercise, but never really contributed to it. That might give you reason to suspect that scope change requests may be just around the corner and that you had better have chosen a project management approach that expects and can accommodate change, rather than one that incorrectly assumes the WBS to be complete. Better to be safe than sorry. If there is any doubt in your mind about the completeness of the WBS, choose some type of Iterative or Adaptive approach so that you will be in a position to accept scope change requests.

Exceptions to the Completion Criteria Rule

In some cases, the completion criteria do not have to be satisfied in order for the WBS to be considered complete. Two common scenarios are discussed in the sections that follow.

Stopping Before Completion Criteria Are Met

A common situation where this occurs is duration-related. Suppose the activity calls for building 100 widgets, and it takes one day per widget. The maximum duration for a task has been set at 10 days. If you follow that rule, you would decompose the activity to build 100 widgets into 10 activities. That doesn't add any value to the WBS — it only adds management time. Leave the activity at 100 days and simply ask for status at the appropriate intervals. Adding activities that simply increase management time and do not add value to the project are a waste of time.

Decomposing Beyond Completion of the Criteria

For projects of a shorter duration (for example, four weeks), it would be poor management to set the acceptable activity duration at 10 days. That would create a situation with too few management checkpoints and hence create a project that would be poorly managed. Instead, the acceptable duration limit might be set at three days, for example. Even shorter duration limits might be imposed for projects that contain surgical procedures or other processes of very short duration. If the entire surgical procedure lasts only a few hours, the acceptable duration limit might be set at a few minutes. These will always be judgment calls on your part. Do what your common sense tells you to do rather than conform to a rule that might not be appropriate given the situation.

One other situation often arises when decomposition beyond satisfaction of the completion criteria makes sense. That is with activities that are considered high risk or have a high estimated duration variance. An activity with an eight-day duration and five-day variance should raise your concern. Even though the activity has met the duration limit of 10 days, you should further decompose it in an attempt to isolate high-risk parts or the high variance parts of the activity. Again, do what makes sense.

Approaches to Building the WBS

There are many ways to build the WBS. Even though you might like the choice to be a personal one that you, the project manager, make (reasoning that because you are charged with managing the project, you should also be the one to choose the architecture that makes that task the easiest), unfortunately that will not work in many cases. The choice of approach must take into consideration the uses to which the WBS will be put. What may be the best choice for defining the work to be done may not be the best choice for status reporting.

There is no one correct way to create the WBS. Hypothetically, if you put each member of the JPPS in a different room and ask them all to develop the project WBS, they might all come back with different renditions. That's all right — there is no single best answer. The choice is subjective and based more on the project manager's preference than on any other requirements. In practice, I have sometimes tried to follow one approach only to find that it was making the project work more confusing, rather than simpler. In such cases, my advice is simply to throw away the work you have done and start all over again with a fresh approach.

The three general approaches to building the WBS are as follows:

You have probably seen one or more of these approaches used in practice to create the WBS. The following sections take a look at each of these approaches in more detail.

Noun-Type Approaches

There are two noun-type approaches: physical decomposition and functional decomposition.

Physical Decomposition

In projects that involve building products, it is tempting to follow the physical decomposition approach. Consider a mountain bike, for example. Its physical components include a frame, wheels, suspension, gears, and brakes. If each component is to be manufactured, this approach might produce a simple WBS. As mentioned previously, though, you have to keep in mind the concern of summary reporting.

For example, consider rolling up all the tasks related to gears. If you were to create a Gantt chart for reporting at the summary level, the bar for the gears' summary activity would start at the project start date. A Gantt chart is a simple graphical representation of the work to be done and the schedule for completing it. The Gantt chart consists of a number of rectangular bars — each one representing an activity in the project. The length of each bar corresponds to the estimated time it will take to complete the activity. These bars are arranged across a horizontal time scale, with the left edge of the bar lined up with the scheduled start of the activity. The bars are arranged vertically in the order of scheduled start date. The resulting picture forms a descending stair-step pattern. That is, after all, where the detailed tasks of doing design work would occur. The finish of the bar would occur at about the project completion date. That is where testing and documentation for the gears occurs. Using the summary Gantt chart as a status reporting tool for the gears doesn't have much use. The bar extends from the beginning to the end of the timeline. The same is true of all the other physical components mentioned. Showing all of them on a summary Gantt chart would simply look like the stripes on a prison uniform.

This type of WBS is initially attractive because it looks similar to, and in fact could be identical to, a company's financial chart of accounts (CoA). A CoA is noun-oriented because it accounts for the cost of developing things such as gears and brakes. A CoA should not be confused with the WBS. The WBS is a breakdown of work; the CoA is a breakdown of costs. Most popular project-management software products provide code fields that can be used to link project task costs with accounting CoA categories.

Functional Decomposition

The WBS can also be built based on the functional components of the product. Using the mountain bike example from the preceding section, the functional components would include the steering system, gear-shifting system, braking system, and pedaling system. The same cautions that apply to the physical decomposition approach apply here as well.

Verb-Type Approaches

There are two verb-type approaches: the design-build-test-implement approach and the objectives approach.

Design-Build-Test-Implement

The design-build-test-implement approach is commonly used in projects that involve a methodology. Application systems development is an obvious example. Using the bicycle example again, a variation on the classic waterfall categories could be used. The categories are design, build, test, and implement. If you use this architecture for your WBS, then the bars on the Gantt chart would all have lengths that correspond to the duration of each of the design, build, test, and implement activities, and hence would be shorter than the bar representing the entire project. Most, if not all, would have differing start and end dates. Arranged on the chart, they would cascade in a stair-step (“waterfall”) manner. These are just representative categories — yours may be different. The point is that when the detail-level activity schedules are summarized up to them, they present a display of meaningful information to the recipient of the report.

Remember, the WBS activities at the lowest levels of granularity must always be expressed in verb form. After all, this is work, which implies action, which in turn implies verbs.

Objectives

The objectives approach is similar to the design-build-test-implement approach and is used when progress reports at various stages of project completion are prepared for senior management. Reporting project completion by objectives provides a good indication of the deliverables that have been produced by the project team. Objectives are almost always related to business value and will be well received by senior management as well as the client. There is a caveat, however. This approach can cause some difficulty because objectives often overlap. Their boundaries can be fuzzy. If you use this approach, you'll have to give more attention to eliminating redundancies and discovering gaps in the defined work.

Organizational Approaches

The deployment of project work across geographic or organizational boundaries often suggests a WBS that parallels the organization. The project manager would not choose to use this approach but rather would use it only when forced to because of the organizational structure. In other words, the project manager has no other reasonable choice. These approaches offer no real advantages and tend to create more problems than they solve. However, they are described here in case you have no other option for building the WBS.

Geographic

If project work is geographically dispersed, it may make sense from coordination and communication perspectives to partition the work first by geographic location and then by some other approach at each location. For example, a project for the U.S. space program because of its geographic components might require this type of approach.

Departmental

Departmental boundaries and politics being what they are, you might benefit from partitioning the project first by department and then within each department by whatever approach makes sense. You benefit from this structure in that a major portion of the project work is under the organizational control of a single manager, which in turn simplifies resource allocation. Conversely, using this approach increases the need for communication and coordination across organizational boundaries.

Business Process

The final approach involves breaking down the project first by business process and then by some other method for each process. This has the same advantages and disadvantages as the departmental approach, with the added complication that integration of the deliverables from each process can be more difficult when you use this approach. The difficulty arises from process interactions at the boundaries of the involved processes. For example, at the boundary between order entry and order fulfillment how would order verification be defined? It could be part of either process. The process in which you place it will impact the customer.

Selecting the Best Approach

Again, no single approach can be judged to be best for a given project. My advice is to consider each approach at the outset of the JPPS and pick the one that seems to bring the most clarity to defining the project work.

Representing the WBS

Whatever approach you use, the WBS can be generically represented, as shown previously in Figure 5-3. The goal statement represents the reason for doing the project. At Level 1 partition the goal into some number of activities (also known as chunks of work). These chunks of work are a necessary and sufficient set that define the goal. That is, when all of these first-level activities are complete, the goal is met and the project is complete.

Partition any activity that does not possess the six characteristics into a set of necessary and sufficient activities at the next level of decomposition. The process continues until all activities have met the six criteria. The lowest level of decomposition in the WBS defines a set of activities (renamed “tasks”) that will each have a task manager, someone who is responsible for completing the task.

Tasks are further defined by a work package. A work package is simply the list of things to do to complete the task. The work package may be very simple, such as getting management to sign off on a deliverable, or it may be a mini-project and consist of all the properties of any other project, except that the activity defining this project possesses the six criteria and need not be further partitioned.

Some examples will help clarify this idea. Figure 5-5 is a partial WBS for building a house, and Figure 5-6 is the indented outline version (for those of you who prefer an outline format to a hierarchical graph). Both convey the same information.

Figure 5-5: WBS for a house

Figure 5-6: Indented outline WBS for a house

Figure 5-7 shows the WBS for the traditional waterfall systems development methodology. If you're a systems project manager, this format could become a template for all your systems development projects. It is a good way to introduce standardization into your systems development methodology.

Figure 5-7: WBS for a waterfall systems development methodology