In Step with Projects

In Pace with Progress

Project Rework Series (3)


Author: Walt Lipke     Source: PMR

Rework has been a common problem, especially in the construction projects, resulting in problems such as higher costs and longer duration. Recently, PMR magazine collected opinions about causes of and solutions to rework across the globe. The following is Walt Lipke's contribution in the form of an interview:

Q1. Based on your observation, what is the present situation of rework in projects? (e.g., the rework rate; rework in different industries)

Walt Lipke: First, thank you for contacting me. As well, a ‘thank you’ to David Pells, the editor of Project Management World Journal, for giving you my name. My supposition is David referenced me due to an article of mine he recently published, “Project Duration Increase from Rework.”

Your question, “What is the present situation of rework in projects?”, is one for which I can only speculate. I have been retired for 15 years and don’t possess direct current knowledge. However, from my speaking at conferences and email exchanges with project managers and consultants, globally, my impression is rework is recognized as a problem, but there is little focus on doing something about it.

A few years ago, I proposed to a project manager (PM) that rework data should be captured. The PM’s response was, “no one wants that information.” I was shocked. My response to him was, “How can you improve and minimize rework, if you have no understanding of your performance.” He just shrugged, and indicated most project managers don’t care. Sadly, my guess is this attitude is pervasive and prevails today.

Part of your question concerns rework and its rate in different industries. I have some knowledge of the software industry and its efforts to improve. The organization I once managed worked with the Software Engineering Institute (SEI) to improve our development and maintenance processes. If you are not aware of the SEI, they were established nearly 40 years ago by the US government to address the problem of software project failures. They are located at Carnegie Mellon University in Pittsburgh, Pennsylvania.

The SEI developed a process maturity model, and over time collected and tabulated relational statistics. My assumption is the statistics shown in the table below, associating rework and process maturity for software projects, remains valid.


Process Maturity

Rework (% of Total Effort)


> 50

Project Controlled

25 Û 50

Defined Organizational Process

15 Û 25

Quantitatively Managed

5 Û 15

Continuous Improvement - Optimizing

< 5


The stages of increasing maturity flow from top to bottom in the table. This is obvious from the rework rates provided in the right column. The identifying words, in the Process Maturity column, are a fairly good characterization of each maturity stage. The emphasis is placed on defining the work process, and measuring performance. Ultimately, the measures are used for managing performance and optimizing the process.

The numbers in this table closely represent what my former organization experienced. As an immature organization we performed erratically and had a floundering effort which generated 72% rework. Even now, it is awful to admit. However, after a decade of effort to improve, our projects had rework rates of between 2 and 3 percent! I think you will agree, this is a remarkable change in performance.

Although the rework percentages may be different, the application of the stages of maturity shown in the table could be applied to every industry. That is, to improve we must understand our process and have measures of performance. We cannot improve rework rate if it is not measured.

I’ll close this discussion with a quote from Lord Kelvin regarding the importance of measurement:

“In physical science the first essential step in the direction of learning any subject is to find principles of numerical reckoning and practicable methods for measuring some quality connected with it. I often say that when you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of Science, whatever the matter may be.”


Q2. What are the impacts of rework in projects? How much does rework contribute to project failure?

Walt Lipke: As you may know, I am the creator of the extension to Earned Value Management (EVM) known as Earned Schedule (ES). The application of ES provides project managers using EVM a method of performing schedule control. Among the various capabilities of ES, it may be determined how closely the project schedule is being followed. Specifically, tasks performed out of sequence are identified. Furthermore, constraints in the schedule become known as well as the future possibility of rework. Significantly, project managers know where to focus their attention. Concentrating management efforts on alleviating impediments and constraints has an immense positive impact on project performance. Additionally, the future rework is calculable, thereby providing advance planning information.

With the research I have performed recently, my estimate of the maximum impact of rework from out of sequence execution is approximately 18 to 20 percent of the planned project budget. However, this is so extreme the probability of occurrence is very low. Nevertheless, you can see the importance of planning, estimating, and scheduling well and executing in a disciplined way.

Along with the cost of rework, there is also a schedule component. As you should expect, there is a corresponding duration increase. From my research, project duration increase appears to be linear with the rework rate. That is, project duration increases proportionally to an increase in rework rate.

In my opinion, the impact of rework to the schedule is a significant challenge to the project manager. It is difficult to accommodate due to its effects rippling through the schedule; lengthening a task causes movement in subsequent dependent tasks. These effects may cause more out of sequence work, in turn, causing more rework; i.e., a negative cycle.

To this point, I have only discussed the impact of undisciplined schedule performance. There are many more causes of rework. There may be omissions, but here are some:

§ poor planning stemming from requirements misinterpretation, incorrect task sequencing, and poor estimation

§ defective work

§ poor requirements management

§ schedule compression during execution

§ overzealous quality assurance

 All of these sources of rework cause increases to project cost and duration. If unchecked, the project may be abandoned, a complete failure. Even when complete failure is avoided, most likely the product is delivered late at increased cost. Oftentimes, the need for more funding and delivery extension becomes clearly obvious during execution. When this occurs, the customer is disappointed and most likely irritated. He understands, full well, that to receive the product it will cost more and not be delivered at the time needed. The impact of irritating customers, in turn, creates a negative reputation. Furthermore, it propagates a perception of the company that reduces business opportunity, and may ultimately cause extinction. It is apparent: paying attention to rework is worthwhile.

Q3. What are your suggested strategies to reduce rework rate?

Walt Lipke: I believe it is common knowledge that correcting problems early minimizes their impact. We know this from our everyday lives. Let’s say we are working on an old building and while removing rusty nails get scratched. We then have a choice. Do we wash, disinfect, and dress the wound or just continue working? If we take a little time and pay attention to the scratch, chances are it will heal in a few days. However, should we do nothing, the wound may become infected. Should that occur, a doctor’s visit is needed. This takes time and has an associated cost. We may need antibiotics, requiring more time and expense; we must go to the pharmacy and pay for the drug. Recovery takes longer. And, although remote, there is a possibility of a much worse outcome. I had a friend who did not pay attention. He died in a hospital.

Well, how should we ‘pay attention’, so that small problems don’t propagate and become much larger and more difficult to resolve

Reflecting on the discussion of the first two questions, it is readily seen that the sources of rework are closely related to process maturity. My suggested strategy for reducing rework is to improve your company’s process maturity level. It is worthy to note that defining, implementing, and refining your production process likewise includes the quality process. The common goals are to minimize defects and, upon identification, correct them as early as possible.

The downside of this strategy is there is no easy path to improving maturity level of your operation. It will take time. You will need to be introspective. It requires truthful self-examination of your organization. That is, you will need to understand how you perform today and, throughout your organization, make a commitment to improving. At first, it may be painful. You will need patience and perseverance.

On the positive side, staying the course has benefits – potentially, significant ones. The organization I once managed invested $6 million, spanning 10 years, on process and quality improvement. From the improvement efforts, a cost avoidance of $50.5 million was achieved. Inflated to today, the investment would be $8.7 M with the associated cost benefit of $73.2 M. This equated to a savings in labor of 565 thousand man-hours. Essentially, my former organization increased the capacity to perform work by approximately 50 people. The organization had a return on investment of 8.4 to 1. As well, this achievement is evidence that Phil Crosby’s famous book title, “Quality is Free,” is true.

Fundamental to making improvement is having measures of performance. Without data there is no basis for improvement. Therefore, one of the measures you must have for the objective of reducing rework is the rework generated. A struggle you may have is defining the rework measure. If you don’t have a common, understood definition, then the reported data will not be consistent, and consequently, improvement efforts will be erratic.

As a suggestion, I offer how my former organization defined rework. We considered rework to be added production effort coming from defects determined from internal reviews, customer reviews, or acceptance testing. Thus, correction for errors made during the development process prior to reviews and acceptance are not considered rework; for example, a production worker recognizing and correcting his own mistake. As you might expect, the correction effort for these mistakes is reflected by inefficiency of performance.

Having the rework definition and capturing rework data, provides information about performance and process. Consequently, it must be analyzed with the objective of making changes for reducing rework.

There is so much more that could be said. Assuredly, reduction of rework is a topic that needs attention from all project managers. Hopefully, I have alerted everyone to become more aware of the problem in their management efforts. More directly, my objective in this interview is to have heightened your interest to take action for reducing rework and its impacts. 

Follow Us


Scan the qr code to pay attention to our official WeChat.


Click on the left image to enter our linkedin page.

京公网安备 11010202007990号