The rework cycle

Editor's Note: It is the editor's opinion that the concepts presented in “The Rework Cycle” are of such significance to understanding the nature of development projects that it is being presented in three articles, two in this issue of the PMNETwork and one in the March issue of the Project Management Journal. In “From the Executive Suite” the concept is introduced. In this article the conceptual model is presented. In the PMJ article, a more detailed discussion of the rework phenomenon provides insights which lead to more realistic planning of developmental projects in particular, and substantially enhances the normative model of Projects as presented to date in the PMBOK (Project Management Body of Knowledge) and other sources.

In order to achieve a more strategic view of projects, more effective management, and consistently better performance, the rework cycle must be apart of our understanding of development projects, and recognized in the systems used to help manage those projects. Like bricks without mortar methods and systems which fail to do so cannot stand soundly, and project-based businesses will continue to fail consistently in meeting their competitive goals in cost, schedule, and quality performance.

Based on the experience of analyzing dozens of complex development projects, we have developed a structure for significantly enhancing the traditional view of a project. Repeated applications of this more realistic “model” have proven it to be logically correct and, when codified as a working simulation model, numerically accurate. Its uses have brought benefits (as in dollars) that are large (as in billions) to the businesses that have adopted it. The important core of the model structure is “the rework cycle.”

First, re-casting the traditional view of a project's (or project stage's) tasks to be done, tasks in process, and tasks done as a more continuous stream of work…

1. The Traditional View, as a Flow of work

The pool of tasks in work to be done is depleted over the course of time, such that at the end of the project, nothing is left there, and all the tasks fill the pool of work done.

Taking this diagramed “model” a small step further by recognizing that it is people working at some (varying) level of productivity that causes the work to get done …

2. Explicit Productivity Affects the Pace of Work Flow

Changing the number of people along the way, or somehow influencing their productivity, alters the pace of work getting done.

Let us look at the shape of some key measures of project performance that would occur under this traditional view. Plotted below are graphs of “Work To Be Done,” project (stage) staff, and percentage complete, as computed by a simulation model using the diagramed structure …

3. Simulated Performance of a Project, Using the Traditional View

These may show the way we plan the effort to go; this maybe the way we hope things will go. But let's be honest—how many of us have seen even a remotely ambitious development project actually perform this way?

A BETTER VIEW

A better view recognizes the existence of rework cycles. Below, what is termed the quality of work executed should be thought of as a “valve” controlling the portion of the work flow being done that will or will not require rework …

View the diagramed structure as physical pools in which work resides and pipes through which work flows. It's easy to see that a “quality” measure that could vary (over time) in the range of 0 to l.0 diverts more or less of the work being done into the rework cycle. So long as this measure of quality is less than 1.0, some work being done-even rework itself—will continue to move into and through the rework cycle.

4. Explicit Rework Demonstrates the Cycle

The distinction drawn between productivity and quality is important. Staff may exhibit high “productivity,” but be putting out work of low “quality” that requires later re-working. In this condition, the net throughput to the pool of work really done is low¹.

The pool of rework requires staff to expend effort to execute it—to alter/correct/complete the work items needing revision. With this addition to the model, different project performance would occur. As shown in the plots below, somewhat more familiar and realistic patterns are simulated when rework is generated and executed …

Recognizing the allocation of additional staff effort to execute rework, and the resulting slowdown in the pace of final completion, provides an accurate description of work on a project … almost.

5. Simulated Performance of a Project, With Explicit Rework

THE REALITY

In reality there is a critical “way station” in which elements of rework linger until identified as needing rework. We have termed this way station undiscovered rework …

6. The Rework Cycle, Complete With Undiscovered Rework

Undiscovered rework consists of those tasks or work products that contain as-yet-undetected errors of commission or omission, and are therefore perceived, and reported by all traditional systems, a s being done.

The completed model of the rework cycle yields simulation-generated behavior that is characteristic of all development projects …

7. Simulated Performance of a Project, With the Full Rework Cycle

The precise quantities and timing obviously differ among projects, but the behavior is common: as the initial round of work nears conclusion, previously undiscovered errors become apparent, requiring more staff for a longer time; the perceived and reported progress significantly slows as the magnitude of recognized rework grows, and an extended completion effort ensues as the last elements of. undiscovered rework emerge.

Most rework is discovered by “downstream” efforts or testing, but months (or even years) may pass before this discovery occurs! During this time dependent work will have incorporated these errors, or technical derivations thereof, and enter its own rework cycle. The more tightly-scheduled and parallel the project tasks, the more of a “multiplier effect” on subsequent rework cycles.

This final element of the rework cycle, undiscovered rework, plays a pivotal role in the propagation of problems through a project. Lurking undetected—as a software “bug,” or design miscalculation, or wrongly-placed bulkhead—it causes productivity loss, delays, and more rework on dependent tasks. Undiscovered rework is the single most important source of project cost and schedule crises. It is the great killer of projects (and of new products and of careers), and no traditional systems even acknowledge its existence. Even more important, most projects seem to be planned and managed as though it does not exist.

The specific technical content of undiscovered rework is by definition unknown at any point in the program. But it is imperative to program management success that it be:

(a) Acknowledged (and plans and schedules set accordingly so as to reduce the disruption of the “surprise”);

(b) Actively sought out (while earlier discovery may feel unpleasant at the time, it is important not to “kill the messenger”—rather, to encourage early technical problem identification. Here, it is what you don't know that hurts you most.);

(c) Prevented as much as possible, i.e., improving “quality” as defined here (easier said than done, since managers cannot mandate by edict the achievement of higher quality).

Since the approach advocated here is not common practice, and most companies and managers do not have the benefit of historical data for reference, what should be expected of a project's work “quality,” rework detection times, the magnitude of undiscovered rework? What is “good”? Is more rework found early helpful, or the harbinger of a disaster to come?

In the upcoming (March) issue of the Project Management Journal, the final installment of this article series will draw upon dozens of large development project analyses to present our findings on …

• How to measure your development projects’ “quality” (it's easy if you measure the right stuff,)
• What values of quality are “good” among different project types (you'll see how it varies-one type's ceiling is another type's floor)
• The project cost and schedule effects of achieving different “quality” levels (they're big)
• How to estimate your “rework cycle time” (again, “easy”)
• The value achieved by accelerating the detection of undiscovered rework (it's non-linear)
• How to attain much more accurate assessments of real project progress (forewarned is forearmed)
• Some implications for project management process improvement (and cost and quality and schedule improvement)
• And some specific lessons from a couple of project “war stories.”

CONCLUSIONS

Nothing short of a fundamental change in the way managers view development projects is required. To avoid the persistent cost and schedule performance problems so closely associated with complex developments, we must take a more strategic and realistic view of project work content and processes. We must recognize that while the products and technical steps may indeed be unique, there are common structures and processes, and common problem causes. From these, it is possible to extract lessons and to implement changes that achieve radical improvements in project performance and business success.

A development project is not merely a sum or a sequence of discrete tasks, but contains flows of work in which there are multiple rework cycles. Executing these rework cycles often requires the bulk of the project effort, rendering conventional systems that ignore rework deficient and misleading.

Of all the aspects of the rework cycle, the most malignant is undiscovered rework. Not only does it have its own cost in time and resources, but it is responsible for spreading problems through dependent later (usually more expensive) project stages. We must acknowledge, measure, actively seek out, and where possible prevent undiscovered rework, and the rework cycle, through management initiatives. Successful initiatives will combine changes in the “culture” of the organization, the management support systems, the work practices, the monitoring and scheduling logic, and the way we relate to superiors and customers. We cannot control by mandate the “levers” of quality and rework detection. Instead we need to influence them indirectly through that which we can control, or more directly influence-interim schedule targets, staffing, monitoring systems, testing practices.

The more proactive managers will achieve the greater impact and success. With more accurate information and expectations, they will have the most advance warning, the most time in which to pose and examine “What if” scenarios, the most considered and carefully-crafted actions, the most highly-leveraged improvements achieved.

Our analyses show the range of possible values for work “quality” and rework discovery times within each project type to be sufficiently broad that dramatic improvement is achievable. For globally-competitive businesses in technology-intensive industries, such improvement in project management and performance is vital. The alternatives are unacceptable—unforeseen costs, unexpected delays, unfulfilled promises—all products of the rework cycle.

NOTE

1. This distinction between productivity, quality, and rework has the added benefit of making all of these factors measurable and monitorable. Total throughput of work items in a project stage (lines of code, tons of steel, drawings, numbers of units, tests conducted, or …) can be measured over time much as in traditional systems, and compared to the number of hours spent in the same time frames, so as to monitor a legitimate measure of productivity. Numbers of revisions and rounds of revisions, can be monitored over time so as to derive a tangible measure of quality, as described in the companion article in the March 1993 issue of the Project Management Journal.