A paper presented to the first Engineering Congress, The Institution of Engineers, India - Calcutta, January 1987

Introduction | Definition | Traditional | Hard-Soft | Environment
Characteristics | Concepts | Control | Breakdown | Fundamentals
Prerequisites | Summary | Appendix A | Appendix B

Work Breakdown

Work Breakdown Structure

As described earlier, the process of project control requires the establishment of a firm base line for the project. The base line must be defined in terms of scope, cost, time and quality, on a compatible basis. To be successful, the Project Manager must be able to make use of this and all other available information. At any point in time, he must be able to identify problems early to minimize their effects.

Therefore, the scope of the project must be broken down into a suitably coded structure that identifies manageable segments with clearly assigned responsibilities. This is known as a project breakdown, or Work Breakdown Structure (WBS), see Figures 6a, b, and c for a typical example.

Figure 6a: Top level of a process plant project WBS

Figure 6a: Top level of a process plant project WBS

Figure 6b: Detailed WBS for the Conception and Definition phases

Figure 6b: Detailed WBS for the Conception and Definition phases

Figure 6c: Detailed WBS for the Execution and Transfer phases

Figure 6c: Detailed WBS for the Execution and Transfer phases

Work Breakdown Structure - a task-oriented "family tree" of activities, which organizes, defines, and graphically displays the work to be accomplished.

A WBS must:

  • Establish an information structure for describing the project's scope;
  • Serve as an effective means of communication to integrate the objectives and activities of all the internal and external organizations involved in the project;
  • Represent the planning of the project, step by step;
  • Separate sequential and parallel activities assigned to different groups who will schedule, measure and control their own performance; and
  • Reflect the procurement strategy during the various stages of the project's life cycle.

To be effective this WBS and corresponding coding requires:

  • Early implementation;
  • Flexibility and expandability;
  • Universal application;
  • Simplicity; and
  • Capability of summation.

Work Packages

The "manageable segments" of the project referred to above, are usually referred to as activity, commitment or Work Packages.

A Work Package describes the work to be performed by a specific organizational unit, and serves as a vehicle for monitoring and reporting on progress, cost and schedule. All work packages fall into one of three different categories:

  • Discrete Tasks which have a specific end result or objective. These normally cover 60 to 75 percent of the total work in a project.
  • Apportioned-effort Tasks which can be directly related and apportioned to discrete tasks. Examples include quality control or inspection. These tasks are required in support of the discrete tasks, and hence, their schedule and budget can be related to the discrete tasks.
  • Level-of-effort Tasks which have performance standards rather than specific end results. These consist mainly of the overhead accounts, e.g., management, administration, liaison, coordination, etc. These tasks are characterized by relatively level, time-phased budgets and are not time-limited as in the case of the discrete tasks.

Essential Work Package Rules

Note that a work package is a generic term describing the unit at the lowest developed level of the relevant part of the WBS. The distinction is made between the lowest developed level and the lowest possible level, because at any given time not all work packages will be classified at the same level. In other words, a work package is not a distinct level in the Work Breakdown Structure.

To be effective, work packages should be controlled by the following rules.

Rule 1: A work package must represent a unit of work at a level where work is performed.

Rule 2: It must be clearly distinguishable from all other work packages.

Rule 3: It should have scheduled start and completion dates.

Rule 4: It should have a budget.

Rule 5: Its size and duration should be limited to relatively short spans of time.

Rule 6: It must integrate with other work packages and schedules.

Rule 7: It must represent a level at which actual costs can be collected or assigned.

Note, however, that a project should not be broken down to too great an extent. If some work packages are too small, unnecessary administrative effort will be expended in maintaining the information flow. This suggests some additional rules governing work packages:

Rule 8:On small projects the following "test of reasonableness" is suggested: a work package should at least be large enough to constitute a scope of work that could be competitively bid and contracted for by itself.

Rule 9: On large, multi-million dollar projects design work packages should not be less than, say, 300 man-hours and two months in duration.

For construction, a minimum work package value of, say, 0.1 percent is a good rule of thumb.

A number of work packages may be assembled into a contract package for procurement purposes. Within such a contract, the identity of the individual work packages should be maintained for control purposes. However, to be consistent with the Work Package definition, the following further rule must be applied:

Rule 10: The same work package must not appear in more than one contract. If this is likely to happen, the affected work package should be subdivided, and the respective parts separately defined and coded.

Managment Control  Managment Control

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page