Change management starts in the field, not the boardroom.
On a major project, change does not announce itself in a steering committee. It arrives as a revised condition, an informal request from the principal, or a method the crew worked out on night shift. Whoever catches it first decides what it costs.
Change management has a reputation problem on construction projects. Say the words and people picture a corporate program: communication plans, town halls, a curve with a dip in it. All real, all useful, all a long way from a pipeline right-of-way at two in the morning.
On major infrastructure, the change that costs money is more specific. An approval condition is revised. A management plan comes back from the regulator with new requirements. The principal asks, in an email that is not quite an instruction, whether the team could also do this one extra thing. A construction method evolves because the ground disagreed with the design. Each one changes what the project must deliver. Almost none of them arrive through a change process.
Change is a field phenomenon
Here is the uncomfortable pattern: the field always knows first. The crew knows the method changed because they changed it. The site engineer knows the new condition exists because they are the one trying to comply with it. The environment advisor knows about the extra scope because they were cc'd on the request. The commercial team, who are supposed to price change, find out last — sometimes months later, during a dispute about who pays.
So a change system that starts in the boardroom is pointed the wrong way. It needs to start where change actually enters the project: on site, in the inbox, and in every revision of the condition set.
Every informal request is a change wearing someone else's hi-vis. Log it before it starts work.
Three mechanisms that catch it
- A scope gate. One simple rule: every informal request from a principal or owner is logged and assessed before work proceeds. Not refused, not escalated into a fight — logged and assessed. Most turn out to be nothing. The ones that are something get agreed under the contract instead of absorbed.
- Condition-set comparisons. When an approval or a plan is revised, someone has to read old against new and say exactly what changed. Not a summary — a line by line comparison, with each new requirement assessed for its effect on plans, method, programme and cost. Approval revisions are contract events. Treat them like it.
- A management of change procedure the field can use. If raising a change takes a form the crew has never seen, they will not raise it. Ours fits on a page: what changed, who spotted it, what it touches, who decides. The sophistication lives in the registers behind it, not in the doorway.
And then the people part
The formal discipline only works if the people carrying it believe in it, which is where the boardroom version of change management earns its keep after all. Crews adopt a change they understand. A revised condition lands better as a two-minute explanation at prestart — what changed, why, what it means for today — than as a revision number in a document register. The methodology is sound. It just has to walk onto site.
On a major interconnector we track every revision of the condition set across two states, and assess each new requirement for its effect on plans, methods and cost before it reaches the works. The discipline is unglamorous: read the revision, compare it, log it, brief it. The payoff is that change gets agreed while there is still time to agree it — which is the entire difference between a variation and a loss.
The test
Ask one question of your project: when a condition changed last, who found out first, and how long did it take to reach the person who prices change? If the answer is measured in weeks, the change system is decorative. The fix does not start with a framework. It starts with a register, a gate, and someone in the field whose job it is to notice.