The rework cycle

Kenneth G. Cooper is director of the Management Simulation Group and senior vice president of Pugh-Roberts Associates, a division of PA Consulting Group. His management consulting career spans 20 years, specializing in the development and application of computer simulation models to a variety of strategic business issues. His clients include AT&T, Aetna, Arizona Public Service, Hughes Aircraft, IBM, Litton, MasterCard, McDonnell-Douglas, Northrop, Rockwell, and several law firms. Mr. Cooper has directed over a 100 consulting engagements, among them analyses of 60 major commercial and defense development projects. He is an original author of the program management model introduced in this article. His group's offices are in Cambridge, Massachusetts, and Oxford, England. Mr. Cooper received his bachelor's and master's degrees from M.I.T. and Boston University, respectively.

The project was slated to design and build an exciting first-of-a-kind product. But during the development effort, unexpected problems emerged—changes in the design specifications, shortages of qualified people, material supply delays. Costs escalated, and work fell far behind schedule. The project's future was threatened, and the work was interrupted. Eventually, project objectives were scaled back and the work was completed—years late and at more than double the original budget.

If this tale of development project woes sounds all too familiar, perhaps it is from personal experience, or because others like it are being lamented so frequently in company boardrooms, and reported in business publications with disturbing regularity. It might be a construction firm's experience in building a power plant, or a software company's troubles in bringing new systems to market, or the most recently-reported defense program problems, or the automobile industry's struggle to cut product development time.

But it isn't. The product sponsor in this tale was George Washington; Paul Revere supplied the required copper and brass fittings. The special timber that delayed the work's progress eventually provided the project's product with its nickname, “Old Ironsides.” The U.S.S. Constitution inaugurated the U.S. Navy and was, in 1794, a new nation's introduction to the challenge of large development project management. Today the challenge remains largely unanswered.

The simple fact is that the traditional art/science of complex development project management is a failure. The consequences of this failure are enormous. Contractors and other businesses lose vast sums of money on the development efforts themselves. The costs of the nation's defense soar. Legal disputes over contracted project cost responsibility drag on for years. Other projects are denied scarce resources. Products are late to market, at higher prices, and with fewer features than planned and promised. Market shares, jobs, and profits are lost. Our competitiveness as companies and as a nation suffers.

Why have we made so little progress in learning how to manage large projects? Why, with all the project management systems and tools-computerized and otherwise-do we keep getting “surprised”? Is every large project just “too unique” to extract and transfer lessons from one to another? Or is there enough commonality among such projects that we may learn, improve our tools, and perform to higher standards?

Imagine that you have contracted for your house to be built, and that the standard tape measure used by all the contractors has long segments—half the tape, in fact—that are uncalibrated. What sort of product would you expect from their efforts?

We are, in effect, equipping project managers with half-blank tape measures as the standard tools for planning, monitoring, and managing large projects. With my colleagues, I have analyzed in depth over sixty major development projects and programs in aerospace, large construction, software systems, shipbuilding, defense electronics, and telecommunications. When we began doing so over ten years ago, we were asked by our contractor client to build a computer-based model capable of accurately simulating the performance of a large project from the start of design through the completion of construction. Large portions of the project effort simply could not be described or explained by applying the standard available tools. How could this be?

The Critical Path Method (CPM) has long dominated among techniques for project planning. This method provides a framework in which the duration of, and linkages between, individual tasks can be planned. From this, the sequence of tasks may be identified which, if one element on the path were to be delayed, would translate to a delay in the entire project. It is an accepted, often required, technique for planning projects and for testing schedule impacts. It is the basis for virtually every piece of popular project management software offered. Properly constructed and updated, it is an extremely useful planning tool. And yet CPM is an inadequate model for managing complex development projects.

The typical means for monitoring project progress and ongoing cost and schedule performance are variations of earned value systems. These provide for setting work and budget standards for individual tasks. Progress on the tasks, and cost and schedule variations, are assessed by comparing actual effort and cost with the task budgets. The earned value system for project monitoring is, like CPM, an accepted and often contractually required project management technique. Truthfully and faithfully employed, it is a highly disciplined monitoring method. And, like CPM, earned value is an inadequate model for managing complex development projects.

For decades there has been a stagnation in the prevailing theory and practice of large project management. “Advances” have been largely confined to the computerization of fundamentally inadequate methods. So what's missing?

THE MISSING MEASURE

What is missing, as any experienced project or program manager knows, is rework. For all their utility, conventional methods treat a project as being composed of a set of individual, discrete tasks. Each task is portrayed as having a definable beginning and end, with the work content either “to be done” or “in process” or “done.” No account is taken of the quality of the work done, the release of incomplete or imperfect task products, or the amount of rework which will be required. This is particularly inappropriate for development projects, in which there is a naturally iterative process of design/engineering.

Indeed, our analyses have shown that rework can account for the majority of work content (and cost) on complex development projects! While this varies significantly among projects and project types, it is hardly ever a matter of a single re-visiting of a particular task. Instead, several iterations are typical, often far removed in time from the scheduled and actual conduct of the first round of work on the task. This is readily seen in, for example, the release of initial engineering drawings, “A” revisions, “B” revisions, “C” revisions (for those companies or projects which actually monitor such information). Companies experienced in complex projects know to expect this, and have developed rules of thumb to count on 2 (or 3 or 4 …) revisions per engineering product. Even so, this expectation rarely is incorporated explicitly in work planning and management systems—because the techniques don't allow it. Worse are the cases where this rework cycle is not explicitly anticipated or monitored. Here they are not only working with half a tape measure—they're reading it with their eyes closed! These are not unintelligent people nor project-naive companies; on the contrary, they include the most technically sophisticated individuals conducting and managing complex developments in firms whose very existence depends on successful project performance.

What we need, then, is a different
view of development projects, one
which recognizes the rework cycle,
plans for it, monitors it, and helps
managers reduce its magnitude and
duration.

What we need, then, is a different view of development projects, one which recognizes the rework cycle, plans for it, monitors it, and helps managers reduce its magnitude and duration. We need a method that reflects a more strategic view of projects, one which accounts for the quality of work done and the causes of productivity and rework variations. We need to be able to see more clearly than is allowed by “traditional” methods how changing external conditions and our own management actions alter staff productivity and the rework cycle—and how the consequences spread through an entire project. We need a new framework applicable across a range of projects, reflecting that which is common and that which is unique among projects. Only thus may we more consistently and rigorously extract, learn and apply lessons that will yield sustained improvement in project management and performance.

Such a new framework has emerged from the application of System Dynamics simulation methods to a wide range of development projects. In a manner quite dissimilar to CPM/PERT models, it treats a project not merely as a sum or a sequence of discrete tasks, but as flows of work in which there are multiple rework cycles. Because of the significant rework content of development projects, this framework is able to reconcile with one another a project's person-hours spent, tasks/items performed, elapsed time, and much mom. Not only can the Rework Cycle model structure accurately simulate the actual recorded history of projects, but it can provide powerful forecasting and “What if” managerial capabilities!

First built for a ship design project at Litton*, the Rework Cycle model has since been applied accurately and successfully to over sixty different projects—software system developments at AT&T, defense electronics systems at Hughes Aircraft, the Cross-Channel Tunnel (constructed by the Transmanche-Link consortium of contractors), aircraft design and production at Northrop, electric utilities 'power plant engineering and construction, and dozens of other programs and projects.

At the core of the structure is a different but straightforward view of project work accomplishment-one which recognizes the rework cycle. That simple addition to the traditional view has, however, provided an extremely powerful diagnostic and management capability for project managers in the many organizations with which we've tested its application.

*Naval Ship Production: A Claim Settled and a Framework Built. Cooper, K.G. Interfaces, a publication of The Institute of Management Sciences, December 1980.