The rework cycle game

learning complex project change impacts in a game setting

Project managers operate within a realm of swift technological, economic, and environmental change coupled with a heightened visibility of large project failures. To make smart management decisions under these conditions requires the ability to assess and apply intuition gained from years of experience across varied conditions. Successful companies have realized that it is not practical for managers to slowly hone their intuition solely through years of apprenticeship on smaller projects, nor on a variety of larger projects that include both successes and failures. The challenge is all the more daunting when companies’ projects—be they new product development, IT, construction …—are riddled with varying degrees of change, and the far flung, often poorly understood and underestimated disruption impacts of changes. Quantifying and distinguishing among the external and managerial contributions to varying project performance outcomes, therefore, becomes vital to learning the right lessons before too much damage is done to company performance. How can these complex lessons be made clearer and more transferable? How can project managers learn more quickly?

We have devised the Rework Cycle Game, a simple board game and accompanying simulation system, as a forum for disseminating transferable project management insights. We have found these simulated game plays and discussion forums to be very effective for the participants’ managers. In this paper, we will describe the outcomes from hundreds of exercises of this project simulation game: variation in amounts of project rework; causal diagnosis of the variance; the range of outcomes achieved as managers strive for on-time on-budget project performance; and the range of “disruption” impacts as projects are subjected to different types and amounts of scope/design changes. We will distill simple lessons from these outcomes, such as the tradeoffs of working to different cost, schedule, and quality objectives, and the ripple effects of accepting customer scope and design changes.

So Why Did It Go Wrong?

We typically employ simulation models of real multi-$100M development projects to diagnose good/bad management policies and the full project impacts of external changes. Our clients range from major defense contractors to software developers to construction firms. Although we individually customize each model to the particular characteristics of its respective project, we apply the Rework Cycle structure at the core of every model.

In employing these simulation models across hundreds of projects in numerous industries, we have over the years framed some general lessons. Projects are composed of flows of work, not individual discrete tasks, much of which will be reworked again and again. It is the pace of rework discovery and correction that dictates the ultimate schedule and cost. This is true despite the belief held firmly by many managers that the trouble was attributable to the tricky design on that critical part, or the slow progress by that one vendor. The amount of rework performed is far-and-away greater than is normally understood. And management policies have a strong influence upon rework performance, and therefore progress, cost and schedule.

And yet, we found that many project managers have difficulty discerning which conditions and what actions have what degree of impact on project performance. And even when they have successfully appropriated cause to consequence, they have difficulty sharing and convincing others of this relation. To address this challenge, we used our project simulation model as a basis to devise a simple board game and accompanying simulation system as a forum for clients to cross-transfer project management insights.

The Rework Cycle Game

The Rework Cycle Game, a training system delivered via a facilitated workshop, enables client managers to gain years of simulated experience within a safe environment. The board game, accompanying computer simulation system, and in-depth experiential debrief reinforce and bring the key lessons to life.

In playing the game, participants work as teams to manage a typical design-and-build development project from start to finish. Four teams play concurrently under different conditions in order to produce comparative results. Game pieces represent work at various stages of progress, as well as staff hired, applied, and fired. Players receive periodic reports summarizing the progress of work on their project, accrued costs, and estimated completion dates. Each period, players use the progress reports to decide how to reallocate limited labor resources. The staff decisions are updated to the computer simulation system, which determines how much work the staff accomplishes given the current work conditions, until the project is perceived as completed. The simulation system is a simplified version of the same project model used to simulate real $MM client projects, and incorporates various impacts of tight schedules and budgets, competitive labor markets, compounding impacts of delay and disruption, increased scope of original work, and other industry-tailored conditions of real-world projects. Exhibit 3 illustrates how these key underlying dynamics of projects impact staff productivity and work quality, and hence project cost, schedule, and quality.

Exhibit 1. The Rework Cycle

The Rework Cycle

Exhibit 2. The Rework Cycle Game

The Rework Cycle Game

Exhibit 3. Underlying Dynamics of Projects

Underlying Dynamics of Projects

Exhibit 4. Team 1 Cost and Schedule Tradeoffs

Team 1 Cost and Schedule Tradeoffs

Debriefing the players’ experience creates dialogue around management's mental models—illuminating exactly how different management styles can lead to different outcomes. Playing the game trains managers to understand the underlying drivers of project dynamics, and permits managers to put their hand to both succeeding and failing at complex project management in order to subsequently analyze why certain actions contributed toward particular consequences. All of this ultimately leads to more experienced project managers, better managed, more profitable projects, and greater company value.

Firms have used the Rework Cycle Game as a training vehicle to communicate insights for dealing with their own greatest challenges. In this paper, the presenters recount the successful dissemination of two very different lessons in which the game played a critical role.

Managers Can and Do Achieve Objectives

For senior managers and executives at a major defense contractor, the exercise was designed to demonstrate different management priorities and their tradeoff effects on project performance.

Exhibit 5. Team 2 Schedule and Cost Tradeoffs

Team 2 Schedule and Cost Tradeoffs

Exhibit 6. Team 3 Design Revisions

Team 3 Design Revisions

The four teams were charged with managing toward different high-priority objectives: Team 1 was to seek the lowest cost and be less concerned about schedule and quality; Team 2 was to finish in the shortest possible time; Team 3 was to achieve the highest delivered quality; and Team 4 was asked to pursue a company-typical management style for balancing the cost, schedule, and quality objectives. As in all variations of the game, the sole management levers provided to the players were the scheduling and staffing of Design and Build. The results were that the teams did manage to meet their objectives, despite the limited levers.

Team 1 achieved the low cost they sought, but the comparatively longest schedule.

Team 2 finished soonest, as intended, but their project cost was more than any of the other teams'.

Team 3 achieved the highest quality, but at a relatively high cost and long schedule.

Team 4 followed a balanced approach and achieved moderate success in controlling both cost and schedule.

As we've seen in our analysis of major projects, so too in the game, rework (quality) is a major driver of cost and schedule growth. Although on average rework represents about 50% of total labor. Significant variations can occur when management priorities are put in place. Team 2 (with schedule priority) experienced by far the largest amount of project rework. This correlation tends to be true regardless of the particular game players.

That Change Will Cost 4x the Original Estimate

Change management is one of the biggest challenges facing companies that run large projects. Changes in complex, tightly scheduled projects are thought to be disruptive, but the extent of this disruption and the paths by which it ripples through a project are typically unknown for project managers. Proper change management requires better understanding and tighter control over the disruption.

For a major contractor, we employed the Rework Cycle Game to illuminate the disruptive impact of changes. Four teams simultaneously managed the same project with only the following important differences: Team 1 managed a challenging, tightly scheduled project—but with no changes; Team 2 managed the same project but received one major change shortly after project start; Team 3 received many small changes throughout the project; and Team 4 received the identical multiple small changes plus were ordered to complete as quickly as possible! Teams 2, 3, and 4 all received changes summing to approximately 10% of the total work scope.

The teams employed a wide variety of staffing strategies to mitigate the disruption. Some of these strategies are better than others—we'll see why later on. But first, to illustrate the possibilities, example strategies are as follows:

Exhibit 7. Team 3 Cost and Schedule Tradeoffs

Team 3 Cost and Schedule Tradeoffs

Exhibit 8. Team 4 Schedule and Cost Tradeoffs

Team 4 Schedule and Cost Tradeoffs

•  Ramp-up Design staffing early and massively to get Design out to Build sooner (regardless of the consequences in a tight labor market).

•  Delay the start of Build to work with a more mature design (but at the cost of a more compressed Build schedule).

•  Start Build sooner, to get a jump on the schedule, and work with Design to mature the design.

•  Set aside staffing budget in both Design and Build to deal with later rework effort.

In this case, Teams 2 and 3 chose to ramp Design staff dramatically in response to design changes. All teams added late staff to cope with unexpected rework.

Under extra schedule pressure, Team 4 started Build the earliest.

Can you guess how well these different change management strategies were able to mitigate disruption? Not surprisingly, the authors and the client found the following results to be insightful.

As can be seen in Exhibit 11, Team 1 (no changes) served as an effective control group, finishing on time and close to budget. Team 2 (single large change) cost significantly more. And Team 3 (many small changes) cost the most, by a considerable margin. In fact, although Team 2's project costs overran by nearly twice the direct added cost, Team 3's project cost overrun was an alarming four times the direct added cost. All of this excess cost was directly traceable to disruption stemming from changes.

Exhibit 9. Resource Allocations in Design by Quarter

Resource Allocations in Design by Quarter

Exhibit 10. Resource Allocations in Build by Quarter

Resource Allocations in Build by Quarter

As stated earlier, the only difference in conditions was the type of change input. In all cases, except Team 1, the amount of change was a 10% increase in scope. By comparing Team 2 to Team 1 we see the effect of a single large change—the 10% direct growth resulted in a further 17% growth in the unchanged work (for a 1.7 ratio in Exhibit 12). This further growth was due to disruption (i.e., reduced productivity and increased rework) of unchanged work.

Similarly comparing the results for Teams 3 and 4 demonstrates how different types of changes cause different amounts of disruption. For Teams 3 and 4, the many small changes led to reduced productivity and increased rework on unchanged work such that growth from disruption was 3–4 times the 10% direct scope growth. Additionally, Team 4 finished their project with a very low delivered quality, apparently with a large obligation for additional costs under warranty!

Exhibit 11. Cumulative Cost

Cumulative Cost

Exhibit 12. Disruption Relative to Direct Impacts

Disruption Relative to Direct Impacts

So where did all the lost productivity and increased rework come from? The game illuminated the root causes of the disruption: skill dilution, availability and quality of design, and quality of work to date.

By rapidly increasing staff in a tight labor market in response to the change order, the project managers were forced to employ on average people of lesser experience and skill. The resulting dilution in the average skill of project staff hurt productivity. Additional skilled resources were needed to train and supervise the new hires, thus limiting their productive hours. Teams 2 and 3 had the steepest ramp-ups in Design and thus the most severe effect of skill on Design staff productivity (refer to Exhibit 3).

The reduced Design productivity then led to late design releases, thus impairing Build's productivity and ability to stay on schedule. Build managers had to contend with not just the increase in work scope but also an unstable design and hence a less productive workforce. Build managers had already expected to increase staffing to deal with the increase in scope. This rapid increase in Build staffing within a tight labor market lead to skill dilution and consequent reduction in Build productivity. And as before, the lower productivity implied that they needed even more staff to finish Build on time.

The same things that influence productivity tend to influence work quality and rework creation as well. So not surprisingly, Build work quality suffered. The lower work quality lead to more rework creation. And so the Build managers not only had to finish the initial work scope with lower productivity, but they also had to at the same time accomplish the rework that had been generated, all within the same schedule. And so, they yet again needed to increase staffing yet some more. Unfortunately, rework was not discovered immediately, leading to overly optimistic perceptions of progress. Meanwhile, dependent Build work incorporated these unknown errors. This is the effect on productivity and quality from “quality of work to date”—yet another compounding factor.

Sound like a vicious circle? It is—but managers can and do mitigate this.


The Rework Cycle Game has provided participants with key insights with major bearing on project performance. The “management priorities” application of the game illustrates program impacts from prioritizing cost, schedule, and quality, as well as the tradeoffs that can be made amongst these in seeking a more balanced approach. Where participants’ particular corporate management styles are represented the game illuminates the potential effects on corporate performance.

Disruption from changes is larger than typically understood or compensated for. The “change management” application brings this home for participants in a powerful way. Participants learn that many small changes can be much more disruptive than one large change (“how can just one more little change hurt?”). And of equal importance for managers is diagnosing the root causes of disruption and how their scheduling, staffing and other decisions can exacerbate or mitigate this disruption.

By experiencing and sharing these insights firsthand via an interactive game environment, firms are able to bring hard-to-communicate lessons to life. Even in its pared-down simplicity, the Rework Cycle Game, encourages experimentation and dialogue, and helps to codify the illusive knowledge of senior project managers.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA



Related Content