The rework

The Rework Cycle:
Benchmarks for the
Project Manager

Kenneth G. cooper, Consulting Group, Cambridge,
Massachusetts
Project Management JournaI 24.1 (March 1993)

Editor´s Note: The following article is the third in a three-part series, the first two of which are in the Feb. 1993 issue of PM Network where the concept and workings of the rework cycle are introduced. Based on dozens ofapplications to major development projects, the structure portrays flows of project work in wl1lch there are multiple cycles of rework. Rework typically represents the bulk of development project expenditures and time. The absence of its treatment in conventional methods and systems is a critical omission that consistently leads to project overruns. This article translates experience, using therework cycle model into practical suggestions and guidelines for use by managers of development projects. .

WHEN GAUGED BY
Expectations for cost, schedule, and planned product, the prevailing modes of performance on complex development projects are surprise and failure. Conventional methods and systems have contributed to the consistently poor track record of complex project performance.Critical path-based methods lack any consideration of the need for reworking incomplete tasks. Earned-value systems—even those endorsed or required by the government—have been likened, by our contractor clients, to driving a car by watching the rearview mirror. We have

FIGURA 1 THE ESTRUCTURE OF THE REWORK CYCLE
Developed and applied extensively a structure designed to portray and anticipate therework cycle in development projects. In Figure 1, the boxes represent pools of work (drawings lines of code feet of cable). At the start of a project or project stage, all work resides in the pool of work to be done. As the project begins and progresses, changing levels of staff (people) working at varying productivity determines the pace of work being done. But unlike all other program /projectanalysis tools and systems, the rework cycle portrays the real-world phenomenon that work is executed at varying but usually less than perfect quality. Potentially ranging from 0 to 1, the value of quality. (As well as that of productivity) depends of many variable conditions in the project and company.
The fractional value of quality determines the portion of the work being done that will enterthe pool of work molly done, which will never again need redoing. The rest will subsequently need some rework, but for a (sometimes substantial) period of time, the rework remains in a pool of what we term undiscovered rework-work that contains as-yet-undetected errors and is therefore perceived as being done. Errors are detected by downstream efforts or testing; this rework discovery may occurmonths or even years later, during which time dependent work has incorporated these errors or technical derivations thereof. Once discovered, the know rework demands the application of resources beyond those needed
Quantifying Quality

This chart shows the empirically derived value of quality
The fraction of work being executed that will not require subsequent rework—for dozens of realdevelopment projects in different arenas. Along with the range of quality for each industry segment are shown the rework cycles implied by that range. As lower quality causes more cycles of rework, more effort (cost) must be expended to complete the work—the equivalent of doing it once, and then doing it all over again and again. A quality of 0.20 will require five cycles of work and cost (four fullrework cycles) to get it right.
Development projects here are those that are dominated by design/engineering activity to develop a new product or system, and do not include the building of units to a stable design.

Quantifying Quality

This chart shows the empirically derived value of quality
The fraction of work being executed that will not require subsequent rework—for dozens of real...