Design change impact: How to assess cost, schedule and risk

The search term is also crowded with organizational change management material: HR templates, stakeholder readiness, change fatigue. This article is about the other meaning, the engineering one, where a revised duct route, a changed pile length or a substituted material sets off a chain of consequences across a live project.

TL;DR

• A design change, also called a variation, alters the scope originally specified in the contract. Its impact is the combined effect on cost, schedule and the ability to manage and operate the work.
• Impacts ripple across disciplines and are hard to predict, so the assessment belongs to the affected teams, not to whoever raised the change.
• A sound review checks calculations, coordination, specified requirements, constructability and compliance, and ends in a written, approved and recorded decision.
• Change control is agreed in the contract and enforced before work starts. Late paperwork is where most disputes begin.
• Document-heavy impact checks are the part of the process that software can take over, provided every assumption and source stays visible.

What a design change is, and what it is not

A design change, often called a variation, is an alteration to the scope of work originally specified in a contract. It may add, omit or substitute elements of the works, or change the way they are performed, as Morris and Gupta describe in the RICS Construction Journal (2023).

The same source draws a distinction that saves a great deal of argument. Design development is the process of turning high-level requirements into detailed documents. Filling in blanks in the requirements is generally not a compensable design change. A structural engineer who sizes a beam that the concept design only indicated has developed the design; an owner who later asks for a longer span has changed it.

Changes come from three directions, and the direction shapes who pays:

• Owners, who revise the brief, the program or the budget.
• Design teams, who correct errors, coordinate disciplines or respond to authority comments.
• Contractors, who meet interferences or constructability problems on site and ask for a different solution.

Depending on the contract provisions, each of these can entitle the contractor to additional time or money, according to RICS (2023) and the Construction Industry Institute (1991). The entitlement question is contractual, and it is separate from the technical question of what the change does to the work. Both need answers, and the technical one should come first.

What design change impact actually measures

The Construction Industry Institute defines the impact as the net effect on work cost and schedule and on the participants’ ability to manage and operate. Interruptions can reduce productivity and raise overhead, and multiple changes can compound cost and time. That last point matters: ten small changes are not ten small problems. Each one reopens the sequence that the previous one disturbed.

During detailed design, changes usually hit the design program first. They require additional resources and raise cost and duration, and the consequences may spread across disciplines and be difficult to predict, according to a PMI-published study of a construction design change management tool (2010). Once construction is under way, the same change also carries demolition, rework, remobilization and procurement effects, which the design-stage estimate rarely captures.

Which parts of a project a design change can affect

A useful assessment looks beyond the sheet that was revised. The categories below are the ones an engineering report on a change typically has to cover: technical, financial, safety, environmental and schedule aspects, as the Houston Public Works construction management manual frames them. The examples are illustrations of how the ripple runs, not data from a specific project.

The left column is also a checklist for who must be in the room. Every row without a named reviewer is a place where the impact will be discovered later, on site, at a higher price.

How to assess the impact of a proposed change

The PMI-published study recommends assessing a proposed change with the affected discipline team rather than from a central desk. Its approach combines a design structure matrix and a process map to identify where rework will occur, has affected practitioners assess the impact on their own tasks, and takes into account resource constraints and data from similar past changes.

In practice that becomes a sequence of steps.

1. Describe the change precisely. State what is changing, from which revision, and why. A change request that says “revise layout” cannot be priced.
2. Identify the affected deliverables. Use the model, the drawing register and the dependency between disciplines to list every document that must change. This is where a design structure matrix earns its place: it shows which tasks feed which.
3. Ask each affected team for its own estimate. The mechanical lead knows what a duct reroute costs; the planner does not.
4. Test against resources. A change that is cheap on paper but needs the one senior engineer who is already committed elsewhere is not cheap.
5. Compare with history. Previous changes of similar type give a reality check on the estimates, and a warning where the team has been optimistic before.
6. Quantify cost and schedule, with assumptions written down. The ranges and the basis for them matter as much as the central figure.
7. Decide, record and communicate. Approval, rejection or revision, with the rationale.

The weakest link is step 2. Teams that search folders by hand, or rely on memory of what refers to what, miss the cross-references. Structured document control and a clear drawing revision control practice make this step reliable instead of heroic.

Checks every design change review should include

The impact assessment tells the team what a change costs. The review tells it whether the changed design is still correct. Authorities that publish design quality procedures agree on the core. The Port Authority of New York and New Jersey’s consultant design quality management guidance expects reviews to verify calculation accuracy, coordinate the overall design and confirm that completed designs meet established criteria and specified requirements, and notes that complex or unusual projects may receive an independent constructability review.

A change review therefore covers at least:

• Calculation integrity. Were loads, capacities and quantities recalculated, not just the drawing edited?
• Coordination. Does the revised element still fit with every other discipline’s model?
• Requirements. Does it still satisfy the owner’s criteria, the specification and the applicable code?
• Constructability. Can it be built in the available sequence, with the access and tolerances on site? The Indiana DOT’s constructability guide credits multidisciplinary teamwork from the beginning with preventing problems and reducing construction issues and change orders.
• Safety information. ISO 19650-6:2025 provides a framework for sharing health and safety information collaboratively through a project’s lifecycle, which means a change should update the safety information it affects, not only the geometry.

Layered checking, with automatic checks first and engineering judgment on what remains, is described in more detail in our piece on design error checking. For the compliance dimension specifically, see engineering compliance checks with BIM and AI.

Documenting, approving and tracking changes

The contract is where change control either exists or does not. A FIDIC paper on contractual changes recommends agreeing a change-control procedure in the contract, requiring written and properly executed change orders before the work proceeds, recording all changes, and defining the steps for proposal, approval, notice and dispute.

Internal engineering procedures follow the same logic. A South African utility’s project engineering change management procedure requires that changes be traced, motivated, reviewed, approved, authorized, controlled and recorded before implementation so that design integrity and the baseline are preserved. The word “before” carries the weight. A change that is built first and papered afterwards has already escaped control.

A complete change record usually contains:

1. An introduction stating the reason and origin of the change.
2. The affected baselines: which revisions of which documents it supersedes.
3. A detailed analysis of technical, financial, safety, environmental and schedule impact, as in the Houston Public Works manual.
4. The decision, the approver and the date.
5. The link to the resulting change order or instruction.

Teams that treat maintenance and operations as part of the picture can borrow from the discipline of management of change used in asset-heavy operations. In management of change procedures, formal authorization steps keep modifications traceable after handover too.

The commercial side of the record deserves its own treatment. Our guide to change order analysis sets out the three outputs contractors and project managers need first, and why cost overruns are born before the first shovel.

Why impact assessments go wrong

Four failure patterns recur, and none of them is a mathematical problem.

The assessment is done by one person. A single estimator pricing a change across five disciplines will price what is visible. The hidden consequences sit with the people who were not asked.

The baseline is unclear. If nobody can say which revision the change departs from, the impact cannot be measured, and the dispute that follows turns on documents rather than engineering.

Cumulative effects are ignored. Each change is assessed alone, approved alone and forgotten. The research above is plain that multiple changes compound, so the tracking register has to show the running total on cost, time and affected areas.

Clashes are discovered late. A coordination problem found in a model costs an afternoon; found in the trench it costs a crew and a delay. A disciplined BIM clash detection workflow moves that discovery earlier.

Perspective

We build Yesper as an AI civil engineer, and design changes are where we see the case for it most clearly. The assessment of a change is mostly reading work: find every document that mentions the element, compare revisions, check the new value against the code, recompute the quantity, and write down what was assumed. It is demanding, it is repetitive, and it is exactly the kind of work that gets compressed when a deadline is near.

Our position is that an AI built for engineering should do that work end-to-end and show its reasoning. Yesper writes down its assumptions so that an engineer can review them the way they would review a colleague’s work, and it keeps sources attached to its findings, so the traceability that change control demands is a by-product and not an extra task. Customers tell us they save 50 to 95 percent of the time on projects, and that errors human reviewers had missed were caught along the way. Those are their reports, and the reason we describe them is the mechanism: the reading, comparing and checking is done in full each time, not sampled.

The engineer remains the decision-maker. What changes is that the decision rests on a complete picture of what the change touches, produced in hours rather than assembled over weeks, while the change can still be cheap.

Benjamin

Where Yesper fits in the change process

Yesper works inside your projects as an AI civil engineer: it searches project documents, checks them against regulations, detects errors, performs quantity takeoff from BIM models and drawings, and produces deliverables such as reports and spreadsheets, with sources and assumptions visible for review. For design changes, that means the document-heavy steps of an impact assessment, from finding affected deliverables to comparing revisions and drafting the change record, can run as a workflow instead of a manual hunt. See how design review automation works in practice, or book a demo.