TGFR Consulting LLC Whenever a project fails to meet its objectives, a deep dive tries to explain the source of the failure. Too often this failure traces to a plan that creates “undiscovered rework”. This “undiscovered rework” results in chaos, with project execution moving from a proactive to reactive process.
Undiscovered Rework results in Reactive Execution
In 1981, G P Richardson and A L Pugh II published the book “Introduction to System Dynamics Modeling with DYNAMO”. Within this book, the learning project described a model that represented the progress of a project. This model demonstrated that the concept of “undiscovered rework”, that is, the gap between actual and perceived project was the key factor in project delays. Specifically, this gap between perceived progress and actual project created a range of inner “failure loops” as shown in the following figure
These “failure loops” transform a project a proactive to reactive posture. Rework and impacts cascade will beyond the initial issue. Consider the following example.
- Subsystem integration reveals interfaces that were not fully developed and tested.
- The team diverts resources from other tasks, causing delays in those tasks due to lack of resources.
- Delays impact downstream tasks depending upon the integration.
- Further delays cascade other project tasks.
- Soon the delays and reactions cascade throughout the project.
Distribute this scenario over an entire project and the reaction to the “undiscovered rework” consumes the project’s proactive progress.
Project Planning and Undiscovered Rework
Establishing the timelines, cost and scope of a project depends upon balancing the four basic parameters for a project.
| Parameter | Description |
| Time | When will the project deliver the completed product? |
| Scope | What product features will the product deliver? |
| Resources | What people and funding will be applied to the project? |
| Quality | What will be the project’s and product’s level of quality? |
The “Pick 3” axiom states that planning can set and adjust three of these parameters, but the fourth parameter will float depending on the other parameters.
Consider the following examples of this axiom.
- The project sets the time, quality, and resources for the development. In this case the scope will need to float.
- The project sets the time, resources, and scope for the development. In this case the quality will need to float.
The last scenario is the scenario that creates the “undiscovered rework”.
Floating quality driving “Undiscovered rework”
The common scenario of floating quality in a project stems from the setting of objectives. Here is the sequence of events.
| Project Phase | Event | Project Team Response |
| Initiation | The leadership team sets the scope, resources and timing for the project based upon a market and business needs. | The project team develops a “best case” scenario that inherently means less time will be allocated to each task. |
| Execution | Tasks fail to meet the “best case” scenario during development. | The project team chooses to declare tasks done, even though the tasks do not meet the quality requirements. A perceived versus actual progress gap is created. |
| Integration | The perceived versus actual progress gap is detected. This is the “undiscovered rework.” | The project team reacts, creating the rework loops that cause even more delays and issues. |
As the scenarios become more frequent, the project team replans. In some cases, the project team successfully resets, adjusting the scope, resources, quality, and timing. in some the failures from the above behavior continue to create a gap in perceived progress and this continues until cancellation.
Final Thoughts – Minimizing “Undiscovered Rework”
In “Undiscovered Rework” represents the gap of perceived versus actual work. Project teams set the perceived progress and can make this gap smaller. Be careful of such statements such as “best case” and “we can fix that later”. The following guidance can minimize the perceived versus action progress gap.
- Avoid developing best case schedules. Setting unachievable expectations naturally drives behaviors creating perceived versus actual progress gaps. This gap feeds the transition to reactive program execution.
- Remember the “Pick 3” axiom. Whenever a team accepts scope, timing and resources as dictated by leadership, the team sets up the scenario for “Undiscovered Rework”. Prioritization of the feature set can go a long way towards eliminating the scenario.
- “Pay me now or pay me later”. Creating a gap between perceived and actual progress will naturally require resolution later, ensuring a reactive response.
Further Reading
| Topic | |
| Undiscovered Rework | Richardson, G. P., & Pugh, A. L. (1997). Introduction to System Dynamics Modeling with DYNAMO. Journal of the Operational Research Society, 48(11), 1146. https://doi.org/10.1057/palgrave.jors.2600961 |
| The Rework Cycle | Lecture 07: The Rework Cycle – MIT OpenCourseWare ESD.36 System Project Management Lecture 7 |