By Artem Korsakov ·
Consider a hypothetical project. On-site, the client tells the foreman: "Add two more sockets in the conference room and move the door by a meter." The foreman agrees because the work is minimal, and maintaining client relations is important. A month later, it turns out that due to the door relocation, the ventilation duct had to be redesigned, a different door closer ordered, and finishes adjusted. These works are not in the act of acceptance nor in the contract.
Such stories rarely stem from client greed or foreman negligence. The change is calculated based on the visible part, but the full cost comprises what is not immediately apparent.
Why Small Changes Become Expensive
A change typically has three layers of cost:
- direct labor and materials, which the foreman sees immediately;
- related works affected by the change: adjacent systems, completed stages already needing rework;
- time: schedule delays, crew downtime, repeated equipment mobilization, rescheduled deliveries.
The first layer is easy to calculate. The second requires an engineer who understands the entire project. The third is rarely calculated until the deadline is missed. Therefore, a change that appeared minor may ultimately cost more than the revenue it generates.
There is also a cumulative effect. One uncalculated change is barely noticeable in project results. Ten such changes over six months create a gap difficult to explain to the client or owner. Each seemed too minor to document individually, but together they add up to a significant sum with no supporting documentation.
Who Should Calculate It
In practice, the answer to the question in the title is often: no one specifically. The foreman knows the on-site volume, the estimator knows the rates, the project manager knows the schedule and contract, and procurement knows delivery timelines. Each sees their own part.
Therefore, a change requires a unified document that passes through all parties in sequence: description, items with volumes, price for the client, internal costs, impact on timeline. Construction cost management systems treat such documents separately. Autodesk documentation describes change orders, which undergo their own approval process and subsequently alter the project cost. Thus, a change is documented as a separate item. The estimate is not retroactively corrected.
Educational Calculation: What Changes in Margin
Consider a hypothetical contract. Contract revenue is 10 million RUB, current projected costs are 8 million RUB. Margin before general expenses and taxes is 2 million RUB.
The client requests a change. According to the calculation, it adds 0.6 million RUB in revenue and 0.45 million RUB in costs.
| Indicator | Before Change | Change | After |
|---|---|---|---|
| Revenue | 10 million RUB | +0.6 million RUB | 10.6 million RUB |
| Projected Costs | 8 million RUB | +0.45 million RUB | 8.45 million RUB |
| Margin before general expenses and taxes | 2 million RUB | +0.15 million RUB | 2.15 million RUB |
The change is profitable: margin increased by 0.15 million RUB. However, this conclusion holds only if the 0.45 million RUB includes related works. If the foreman calculated only direct costs, and reworking the duct adds another 0.2 million RUB, project margin becomes lower than original. The timeline must also be checked separately: if the change delays completion and the contract imposes penalties for this, the calculation must be supplemented.
Подпись: Educational amounts in million RUB before general expenses and taxes. Unaccounted 0.2 million turns a profitable change into a loss-making one.
Calculation must be based on projected costs. The original estimate is unsuitable for this purpose. If the project has already deviated from the estimate, the old baseline yields an incorrect margin.
Formula to Verify Any Change
Before responding to the client, it is useful to complete one line:
New Margin = (Contract Revenue + Change Revenue) − (Projected Costs + Direct Change Costs + Related Costs + Time Costs)
And three questions regarding it:
- Who confirmed related costs: only the foreman or also an engineer for adjacent systems?
- Does the change delay the schedule, and is there a price for this delay in the contract?
- From which baseline is projected costs calculated, and when was it updated?
If there is no answer to at least one question, quoting a price to the client is premature.
Why Budget Versions Matter
Changes accumulate. After six months, a project may have twenty approved changes, making it difficult to determine why the budget differs from the original. Therefore, versions are needed: initial budget, approved including changes, and projected costs. In Autodesk cost management reports, these values are separated, which is a good model for any system: the initial figure does not disappear, and changes are visible individually.
If the budget is stored as a single file edited by everyone, restoring history is nearly impossible. Each edit overwrites the previous one, and after six months, no one can say where a specific figure came from. Versions solve this task simply: the old value is not erased; the new one appears next to it with a justification.
The second question: who sees which figures. The client sees contract revenue and change costs. Projected costs and margin remain internal. If both sides are mixed in one document, it cannot be sent to the client without manual cleaning, and sooner or later, an internal figure will leak externally.
What to Do Next Week
Start with a change log for one current project. For each change, record who requested it, what was included, who calculated costs, and whether the client agreed to the cost in writing. Usually, the first log reveals which changes were executed without price agreement.
In a demo scenario, you can trace the general chain: change request, items with volumes, client approval (including partial), and application to the budget exactly once.
Related article: How to Approve Extra Work Before Material Procurement and Start of Works.
Sources and Example Boundaries
Sources confirm the described features of ready-made products, not demand or return on investment for custom development. Scenarios and amounts are educational. Demonstrations use fictional data; real integrations, AI, payments, and external publishing are not included.