Rework impacts the productivity of a project at least three times over. The logic is simple: First you spend time to do the task, and then you have to redo the task, wasting the time that you could have spent doing something else. In the end, rework has 300% negative impact on the productivity of that task. So, for example, if your rework is an average of 10% of the total work completed on the job, then its impact on the job is wasting 30% of the labor.
Perhaps the most inefficient thing that can happen on any job site is rework or punch list activities. Their effects can be felt across the board on a project — from scheduling and completion dates to the financial well-being of the project and the company as a whole. Project managers should maintain vigilance on efforts to continually minimize these activities and monitor the systems in place for identifying and tracking them. On average, rework can affect anywhere between 2% to 20% of the total contract value. Combine that with the ever-thinning margins of today’s market, and this can spell disaster for any contractor.
Causes and effects of rework
By definition, rework is redoing any work already completed, which can have many causes. Rework in any shape (either during the project or at the end as a punch list activity) can be caused by design issues, incomplete drawings, misinterpretation, or error by field labor. When any of these types of rework are recognized on the job site, they have an exponential effect on the timing and financial well-being of the project. The further along in the project’s life cycle rework is discovered, obviously the more costly the outcome can be.
Design-sourced rework — be it changes in scope from the original design or errors/omissions left undiscovered in the design phase from the architects or engineers — is the cheapest and easiest to correct, if the issues are discovered early. Historically, this is where contractors could make up for a lower bid on a project in the form of change orders. However, with the advances in software, such as CAD/BIM, technical design errors are being greatly reduced with engineering and code requirements already being taken into account as design changes are made.
Design errors due to unrecognized integration risk on the job site are still problematic, even with the use of BIM. These are not typically recognized as engineering errors because there is not a “technical” issue with the design. However, the design can lead to rework in the field if the designer did not take into account how the conduit would actually fit around the ductwork, for example. Or maybe he or she didn’t consider the stairwell being too narrow for a piece of equipment to move through. These types of integration risks can cause rework later on once installers recognize the problem. If the field is involved in breaking down the work using a “work breakdown structure” (WBS) process (see the July 2012 EC&M article “Mastering a Mega Project”), including plans for logistics and handling as well as reference to the BIM model, some of this risk can be reduced early on.
On the other end of the spectrum is field-sourced rework, which is the result of mistakes or errors from the boots on the ground. Field-sourced rework can impact a project’s productivity up to 300% when taking into account the time to install, remove, and reinstall — not to mention the time lost that could have been spent doing something else. This, in turn, can lead to project delays and cost overruns — and in almost all cases, this comes at the contractor’s expense. (The customer is typically not willing to pay for field-sourced rework.) Then there is the emotional impact rework can have on labor, causing stress and humiliation from wasting good trade talent.
One primary cause for the field-sourced rework is lack of or incomplete planning and layout. From the top to bottom of the crew, the information about “correctness” of installation and working to the plans and specs needs to be 100% accurately passed on in order for errors to be avoided. Figuring things out on the fly is a recipe for mistakes, and very often the field supervisors assume their crew members have the technical knowledge and experience to “get it right” or “figure it out.”
Regardless of the trade or job site, aside from random acts of nature, most often the root cause behind field-sourced rework is “wrong or lack of information,” which leads to various outcomes, such as:
• Damage from other trades or trade interference.
• Incorrect assembly from the prefab shop.
• Incorrect material delivered to the job site.
• Untimely drawing changes.
• Untimely schedule changes.
Regardless of the reason listed, the root cause of rework comes down to a lack of planning and communication on the job site. Oftentimes, toward the end of a project, the schedule gets compressed, resulting in the trades stepping over one another in a mad dash to try and get their work done. This just sets the stage for the problems listed above to manifest. By having the foreman and supervisors break down the work into cost codes using WBS and then working with the project manager to show them the project from their perspective, project managers are better able to understand the needs of their crews and how to work with the general contractor in terms of scheduling different trades while the project is underway.
Making rework visible
A fundamental key to reducing your field-sourced rework is to have a means of monitoring feedback from the source — from the point of where the rework occurs to the field level supervision to the project management team and back to the office and potentially to the customer, depending on the cause. It is here where project managers can identify and address issues as they occur on the project, such as damage from other trades. Making sure the correct information is fed back to the office and the owners as soon as rework occurs is fundamental to minimizing the impact. What prevents this from happening? Any of the following:
• The labor doesn’t recognize they are doing rework.
• The labor doesn’t want to report and expose their mistake.
• The labor recognizes the rework, and corrects the error without passing it on, therefore masking it altogether.
• There is no mechanism (or “easy” mechanism) for them to record or report the rework.
• There is no feedback or support for the field, even if they do report it, so why bother?
The only way to capture rework is to counteract the above obstacles and concerns with a method that is easy for the labor to use and encourages their input, as well as to see rework’s impact on the daily progress and productivity throughout the project. ASTM E2691, the Standard Practice for Job Productivity Measurement (JPM) accomplishes all of the above (for more information, see the EC&M articles “Measuring Productivity in Construction” in the March 2011 issue and “The Secret to Short Interval Scheduling,” which appeared in the February 2009 issue). When rework happens, the job’s productivity will suffer, because the field is burning hours with no progress reported for their effort, which leads to a signal for the project manager or the organization to react to. In other words, JPM does not require a “separate rework tracking” to make the rework visible. A signal of rework occurrence will go up the same day and same week it occurs, leading to root cause analysis. It does not need to rely on the field to report it separately.
For instance, Fig. 1 shows the productivity differential trend of a job and its “conduit” cost code (which happens to represent 48% of the work on the job). There are three points where rework was made visible through the E2691 method, by capturing project notes during the weekly review of the job productivity assurance and control (JPAC®) and short interval scheduling (SIS®) results:
• Rework #1: “Some rework on some coils and main rack in auditorium had to be lowered (was missed in the drawings and had to make room for mechanical).”
• Rework #2: Changes added for BIM rework.
• Rework #3: “Rework for 150 seat conduit, fire alarm conduit and communication duct.”
As mentioned above, anomalies in productivity are made visible anytime hours are charged to the conduit cost code, but there is nothing in the WBS for the field to observe percentage of completion of work toward final completion. The cause for this could be change orders, contracted scope that was missed in the WBS, or because the foreman on a large job is not getting to every nook and cranny to see the work.
In the case of Fig. 1, as part of the review process in E2691, “rework” was identified by the foreman, and a note was made to capture it. The labor does not get chastised; rather, the field supervisor and/or PM work with the labor to understand the root cause. In the case of Rework #3, the SIS results for the same time frame (week ending July 25, 2015) show a reason code of “worker error,” causing 9 hours not worked as scheduled (Fig. 2). The detail listed behind the reason code states “Floor box conduit missed during initial rough in. [Electrician] piped the power/data feeds into floor box.” So, by using both the special cause and common cause analysis methods of the E2691 standard, the rework is made visible without any extra need for tracking and measurement, and can be quantified, which is explained next.
Quantifying rework and its impact
To account for rework, the hours needed to do the rework cannot be added to the project budget, since they were not as part of the original planned work, and the contractor is not going to get a change order to be paid extra for mistakes. However, the work needs to be tracked to understand the impact on the productivity and cost. The suggested approach by ASTM E2691 is to track the rework as part of the task and not as a separate part of the project to allow the negative impact of the rework to be seen in the run charts of JPM. When rework is tracked separately, the two major pitfalls include:
• The labor will now have to separately recognize, and charge their time to yet another cost code on the job. This can be a hassle for the field, and potentially lead to lack of tracking and visibility.
• The feedback to the project, and ultimately estimating about productivity on a given cost code, will not be all inclusive of the work on that cost code, since the rework itself was tracked separately.
To track the rework using JPM, making it visible and at the same time measuring its impact, the following approach should be taken:
1. Recognize the rework as it happens in the trends of the JPM run charts.
2. Quantify how much rework was done, or needs to be done as follows:
a. If the scope of work to be redone is large, the field needs to develop a mini WBS for the work, including cost codes impacted and budgeted hours.
b. If the scope of work to be redone is small, the field should describe the task, which cost code it falls in, and budgeted hours for the work.
3. Add the tasks into the WBS so that their percentage of complete can be tracked as progress is made on the work (even though it is “rework”).
4. At the same time the rework tasks are added to the cost code so their progress can be tracked, the original work needs to be “punished” because the budgeted hours for the rework have to come from somewhere. To account for this:
a. Remove/deduct the budgeted hours that were defined in step 2 from the original planned task that was done in error.
b. Add the new line item(s) to be reported on with the associated budgeted hours. For example, if the line item for “Rework #2” listed in the example above originally had 50 hours associated with it — and the budgeted hours for the rework was 35 hours — then the 35 hours is removed from the original task and allocated to the new “rework” task.
c. If there is more rework associated with a task than the original budgeted hours for that task, then no budgeted hours can be assigned for the rework itself, and the line item is entered with 0 budgeted hours. Figure 3 shows this case for the rework associated with “Rework #3” in the above example. The new tasks were added, and marked 100% complete, but there are 0 “BLHB” (baseline labor hours budgeted) for this work. However, the budgeted hours established in step 2 above are still noted as well as the task flagged “rework,” so the work is still identified and quantified as rework. This allows the project manager to sum up, on this particular project, all activities tagged as rework, which amounts to approximately 1.4% of the entire project’s budgeted work. The SIS results for the project tell us that the “worker error” reason code accounts for 2.4% of all the hours not worked as scheduled on the job, which indicates that field-sourced rework is probably not the main contributing cause to the amount of rework on the job.
Putting it all into perspective
Like everything else, any value that is not transferred to the customer as part of the project delivery system can be considered a waste of resources. Rework is no exception. It is an economic waste no matter who pays for it.
By conducting project reviews or audits at key phases during the project life cycle, the project team has an opportunity to assess not only the financial well-being of the project, but they also have a chance to address if any additional action should be taken to ensure a profitable outcome. This allows the owners, project managers, supervisors, and foremen a chance to review the source of any rework that has manifested itself on the project, and be able to verify its status.
This makes visible to everyone whether it is billable or not and whether it has been submitted to the owner or general contractor and is pending approval or if it has been approved. However, this level of analysis can only happen if the rework information has been collected, reported without burden to the hard-working field crew, recorded through the correct avenues for measurement of productivity and rework impact on scheduled tasks, and made visible through project tracking output so the labor can explain and be supported for mitigating recurrence of the rework’s true cause.
The root cause of lack of information needs to be tackled at a higher level than any individual crew member or foreman. The entire project team is responsible for timely and accurate drawings, design, and installation information, which starts with the WBS as part of the project-planning phase.
Daneshgari is president and CEO of MCA, Inc., Grand Blanc, Mich. Moore is vice president of operations. They can be reached at [email protected] and [email protected].
