The Rework Cycle
| Viewing project work as a flow, executed by people working at a variable productivity, and performing work that may need subsequent rework…the need for which may go undetected for some time. |
 |
 |
 |
 |
 |
 |
The Rework Cycle -- A Better Way to Understand Projects
The conventional view of a project is a collection of many discrete tasks, each task with a clear start and
end. If only it were that simple…start each task as planned, and finish it as scheduled with the budgeted
resources. But on many projects, things happen that drive work items to be done out of sequence…to be
just partly finished when first issued…to be worked at productivities other than as planned…and to be
reworked.
Therefore, on engineering-intensive projects, it’s helpful instead to think of not just individual tasks, but a
flow of work. That flow of work depletes a pool of work “to be done”; the work flow is executed by people
working at some level of productivity. Now, suppose that the executed work products (drawings /
documents / software code, …) are not simply done once-through—never to be touched again—but are
instead subject to rework…some degree of revision and refinement. And the engineering rework needed
may not be recognized until weeks or months later, when it is discovered by checking, testing, or the
attempt to build to that design. Until then, the rework remains undiscovered. Until the rework need is
detected, project management understandably views that part of the work as finished. Meanwhile, other
design work proceeds, and if it is dependent on the to-be-revised information, it could end up needing
reworking as well. And so the rework cycle continues; in complex engineering projects, many rounds of
revisions are needed to reach completion.
The conventional view of a project is a collection of many discrete tasks, each task with a clear start and
end. If only it were that simple…start each task as planned, and finish it as scheduled with the budgeted
resources. But on many projects, things happen that drive work items to be done out of sequence…to be
just partly finished when first issued…to be worked at productivities other than as planned…and to be
reworked.
Therefore, on engineering-intensive projects, it’s helpful instead to think of not just individual tasks, but a
flow of work. That flow of work depletes a pool of work “to be done”; the work flow is executed by people
working at some level of productivity. Now, suppose that the executed work products (drawings /
documents / software code, …) are not simply done once-through—never to be touched again—but are
instead subject to rework…some degree of revision and refinement. And the engineering rework needed
may not be recognized until weeks or months later, when it is discovered by checking, testing, or the
attempt to build to that design. Until then, the rework remains undiscovered. Until the rework need is
detected, project management understandably views that part of the work as finished. Meanwhile, other
design work proceeds, and if it is dependent on the to-be-revised information, it could end up needing
reworking as well. And so the rework cycle continues; in complex engineering projects, many rounds of
revisions are needed to reach completion.
'The Rework Cycle'…--explaining the basic structure and phenomena of rework that drive project performance. This rework cycle is at the core of the simulation model developed by Kenneth Cooper and applied to hundreds of projects and programs worldwide. Grand Prize Winner of a global Thought Leadership Award competition. Published in Project Management Journal, PMNet, and re-published as a “best” article in Engineering Management Journal |
|
All rights reserved
2011 Cooper Associates
2011 Cooper Associates
