Rework costs the construction industry between 5 and 10 percent of total project value. On a poorly managed project it can reach 20 percent. Even at the lower end of that range, it consumes contractor margin, delays programmes, and generates exactly the kind of late-stage pressure that makes engineering decisions worse.
For structural practices specifically, rework is not primarily a quality problem. It is an information problem. The same design error that costs two hours to fix at calculation stage costs 15 to 25 hours to fix once it reaches fabrication. The difference is not the complexity of the fix. It is the number of downstream processes that have already built on the wrong information.
This guide covers what actually causes structural rework, where in the project timeline it compounds, and what changes at the practice level have the most impact on reducing it.
Why Structural Rework Is Expensive Even When It Looks Small
A 2026 ASCE study found that contractors underestimate their rework costs by approximately 300 percent. The gap exists because most rework tracking captures visible corrections: a changed drawing, a revised calculation pack, a re-ordered component. It does not capture the coordination overhead that surrounds every correction.
When a structural section size changes after the design is issued for coordination, the visible cost is the engineer updating the calculation and revising the drawing. The less visible costs are the architect checking whether the revised section affects ceiling zones, the services coordinator checking whether duct runs still fit, and the project manager reissuing the coordination pack. None of those hours appear on a rework log. All of them are caused by the same error.
For structural practices, the more useful frame is not rework as a percentage of contract value. It is rework as a function of when in the project it occurs.
A revision caught at calculation stage: 2-3 hours of engineer time.
The same revision caught at coordination issue: 6-8 hours, including updates to drawings, coordination models, and reissue to the team.
The same revision caught at fabrication stage: 15-25 hours. The fabricator may have already set up the job. Material may have been cut. The programme has to move.
This cost ratio is explored in more detail in our guide to automated structural calculations, which covers how the calculation environment itself contributes to revision cycles. Across a practice running 12 projects a year, with four revisions per project reaching fabrication before they are caught, the annual cost of late-stage rework looks like this:
4 revisions × 12 projects × 20 hours average resolution × £85/hr = £81,600/year
The same revisions caught at calculation stage:
4 × 12 × 2.5 hours × £85/hr = £10,200/year
The gap - £71,400 - does not appear anywhere as a line item. It sits inside normal engineering hours on normal projects and gets treated as the cost of doing complex work. It is not. It is the cost of an information environment that lets errors travel further than they should.
The Real Causes of Structural Rework
Most rework reduction guidance focuses on symptoms: better QA checklists, more clash detection sessions, tighter drawing review processes. These are useful. They are not, however, the root cause.
PlanRadar's 2026 survey of 811 construction professionals found that miscommunication accounts for 26 percent of rework, and bad or inaccurate information accounts for 14 to 22 percent. Nearly 80 percent of respondents reported that at least half their project documentation sat in unconsolidated channels - email threads, shared drives, messaging apps.
The same survey found that 43 percent of firms without set quality standards do not know what rework costs them. That is not complacency. It is a measurement problem created by the same information fragmentation that generates the rework in the first place.
For structural practices, four information-layer causes drive the majority of rework.
Model and calculation environment disconnection
The structural analysis model and the coordination model are almost always separate environments. ETABS or Robot produces the analysis. Revit holds the coordination geometry. When a section size changes in analysis, that change has to be manually propagated to Revit. When it is not - because the engineer updated the calculation pack but had not yet revised the Revit model when the architect issued a coordination clash report - the clash is logged against a section size that was already scheduled to change. The coordination meeting spends time on a problem that was already solved.
This is not a rare edge case. It is the standard workflow in practices that have not built an integration layer between their analysis and coordination environments. For a detailed look at how data moves between these tools and where the gaps sit, see our guide to Revit, Tekla and ETABS integration.
Change propagation gaps
Architectural changes drive structural rework more than any other single cause. When a column grid shifts, when a floor plate changes, when a facade system is revised late - the structural engineer receives updated geometry and has to assess which load paths are affected, which calculations are invalidated, and which drawings need revision.
In a connected environment, that assessment starts from a clear picture of what changed and what it touches. In a disconnected environment - where the structural model, the calculation pack, and the issued drawings are three separate documents with no automatic cross-referencing - the assessment requires the engineer to manually trace dependencies. That tracing takes time, and errors in it produce rework.
Specification version control
A structural engineer references a standard in a calculation. The standard is updated. The drawing references the original version. Nobody catches it until the contractor submits an RFI during construction.
That sequence is not a failure of expertise. The engineer knew the standard. The issue is that the reference in the drawing and the reference in the calculation pack are static text with no link to the live document. When the standard changes, neither updates automatically, and there is no flag to the engineer that the reference is now out of date.
Late information arriving without context
Architectural and mechanical information frequently arrives mid-calculation - a revised floor plate, a new plant room location, an updated facade load. The structural engineer incorporates it, updates affected calculations, and reissues revised sections of the calculation pack.
What is rarely updated at the same time is the dependency map: a record of which other calculations relied on the information that just changed. Without that map, the engineer has to reconstruct it from memory or by reviewing the full calculation pack. When the dependency map is wrong or incomplete, something gets missed.
Where QA Processes Help (and Where They Do Not)
Quality assurance processes reduce rework. The PlanRadar data is clear on this: 56 percent of firms with consistent QA keep rework under 5 percent of budget, compared with 37 percent of firms without QA standards.
What QA processes do well is catch errors before they leave the structural team. A drawing check before issue, a calculation review against the brief, a coordination model review against the latest architectural issue. These are the standard tools, and they work.
What QA processes do not do is address the information environment that generates the errors in the first place. A checklist that asks "has the section size been updated in both the calculation pack and the Revit model" is a workaround for a process gap, not a solution to it. It adds time to every issue cycle. It depends on the reviewer correctly interpreting what has changed. And it fails when the reviewer is under time pressure, which is exactly when errors are most likely.
The practices that consistently keep rework low are not running better checklists. They are running fewer disconnected environments that require checklists to bridge.
What Actually Reduces Structural Rework
The changes that have the most impact on structural rework operate at the information architecture level rather than the process level.
Connect the analysis and coordination environments
The single highest-value change most structural practices can make is building a reliable connection between the analysis model and the coordination model. When a section size changes in ETABS, the Revit model should reflect that change without a manual re-entry step.
This does not require replacing either tool. It requires building the data pathway between them - through API integration, through a shared data environment, or through a managed synchronisation process that is part of the project workflow rather than an ad hoc step someone remembers to do. The tools involved and their integration options are covered in our structural engineering software cost guide, which also covers what each tool's licensing and integration story looks like in practice.
The reduction in rework from this change comes from two places. First, the coordination model stays current with the analysis, so coordination clashes are raised against actual current information. Second, the engineer no longer carries the mental overhead of remembering which model element corresponds to which calculation, because the link is explicit and maintained.
Make change impact visible at the point of change
When an architectural update lands, the structural engineer needs to know quickly which calculations are affected. That knowledge currently lives either in the engineer's head or in a manual dependency log that may be out of date.
A change management process that traces structural dependencies - which calculations reference which model elements, which drawings reference which calculations - makes the impact of a change visible at the point it arrives, rather than discoverable through a time-consuming manual review. This does not eliminate the engineering judgment involved in assessing a change. It eliminates the clerical work of reconstructing the dependency map before the judgment can be applied.
Reduce the number of environments where project information lives
The PlanRadar finding that 80 percent of project documentation sits in unconsolidated channels is a description of the standard state of most construction projects. Email threads, shared drives, WhatsApp groups, PDF sets issued at different revisions - each is a separate version of project truth.
For structural practices, the specific consolidation that matters most is between the live calculation environment and the issued drawing set. When those are maintained as separate documents, issued drawings can lag behind live calculations without anyone noticing. When the connection between them is explicit - when a revision to a calculation automatically flags the drawings that reference it - the gap closes.
Front-load coordination before fabrication
The 8-10x cost ratio between early-stage and late-stage rework is a function of how far downstream an error travels before it is caught. The most direct lever on that ratio is earlier coordination - getting structural information into the hands of the people who will act on it sooner, so that clashes and inconsistencies surface at a stage where they cost hours rather than weeks.
This is a workflow question as much as a technology question. Practices that issue structural information for coordination at regular intervals, rather than waiting for a complete package, give the downstream team more time to identify problems while the information is still easy to change.
The Measurement Problem
One of the consistent findings in rework research is that most practices do not measure it accurately. The ASCE study's finding of 300 percent underestimation is consistent with other research showing that rework logged on project management systems captures only the most visible corrections.
For structural practices, an accurate picture of rework cost requires tracking not just the hours spent on revisions, but the downstream coordination time those revisions generate. A revised drawing takes two hours to produce. The coordination email thread, the revised clash report, and the follow-up call it generates may take another three. Only the first two hours typically appear on a rework log.
The practical starting point is a one-month audit: for every structural revision issued during the month, track not just the time to produce the revision, but the total time spent by the team on coordination activity related to it. The result is usually two to three times the number that appears in the project management system.
That figure - not the number on the log - is the true cost of rework for the practice. It is also the number that makes the case for investment in the information infrastructure that reduces it.
The Starting Point
Structural rework is expensive, underreported, and in most practices treated as an unavoidable cost of complex project work. It is not. The majority of it comes from a small number of information-layer failures: a disconnected analysis and coordination environment, no automatic change propagation, no dependency mapping, documentation spread across too many channels.
The practices that consistently run low rework rates are not staffed differently and are not doing fundamentally more complex engineering. They are running fewer places for project information to diverge.
If your practice is spending more time than expected on revisions and re-coordination, the first question to ask is not how to improve the QA process. It is how many environments your project information currently lives in - and how many of those updates manually.
If you want to map that out for your practice, get in touch. It is usually a one-hour conversation and the picture it produces is more useful than another QA checklist.
Rework cost statistics sourced from PlanRadar - Cost of Rework in Construction and ASCE Civil Engineering Source - How Much Does Field Rework Actually Cost.