Cost of Rework in Construction 2026: Industry Data and Cross-Sector Context
Updated 17 April 2026
Note on focus
This site focuses primarily on software engineering rework. This page provides construction industry context. For the primary software content, see the software page.
Construction rework has been studied extensively by civil engineering researchers, particularly in Australia (CII), the UK (CIOB), and the US. The figures are surprisingly consistent with software: rework consumes 5-15% of project cost in well-managed construction projects and up to 30% in poorly managed ones.
The parallel with software rework is instructive. Construction rework's most expensive source is design changes that propagate into physical work already completed -- the construction equivalent of a requirements change after implementation has started. The 1-10-100 rule applies: a change to a building's structural design costs less in the design phase than after concrete has been poured.
Construction Rework Cost Benchmarks
5-15%
Of project cost in well-managed projects
Construction Industry Institute (CII)
10-30%
In poorly managed projects
CIOB research, UK
52%
Caused by design errors/changes
Love et al., 2004
Root Causes in Construction vs. Software
| Root Cause | Construction | Software Equivalent |
|---|---|---|
| Design errors | Structural errors, clash detection misses | Requirements defects, architecture errors |
| Design changes | Client-driven scope changes after work begins | Requirement changes after implementation starts |
| Coordination failures | Subcontractor interface errors | API contract failures between teams |
| Unclear specifications | Ambiguous drawings, missing tolerances | Ambiguous acceptance criteria |
| Quality control failures | Work not inspected before it is covered | Code merged without review or tests |
The parallel is exact: both industries find that unclear specifications and coordination failures are the primary rework drivers. The cost-of-change curve applies in both: a structural change in design costs 1x; the same change after the building is partially constructed costs 100x. The IBM 1-10-100 rule was not invented for software -- it was already well-understood in engineering and manufacturing before Boehm applied it to code.
The key difference: construction rework is highly visible (you can see the torn-out wall). Software rework is invisible in sprint velocity metrics. This invisibility is one reason software rework is systematically underestimated and underreported relative to construction.
Sources
- Construction Industry Institute (CII). Best Practices Guide: Improving Project Performance. University of Texas at Austin, 2012.
- Love, P., Edwards, D., Irani, Z. Rework in Civil and Building Engineering Projects. Construction Management and Economics, 2004.
- Chartered Institute of Building (CIOB). Rework in Construction: An Overview. CIOB, 2013.