Managing changes (or “change orders”) well is often one of the main factors that will decide a project’s profitability. It is not the only one, but it carries real weight. Depending on how they are handled, contract changes become either a source of risk or a source of opportunity.
The five practices we share here claim to be neither exhaustive nor original. They are lessons learned that we observe, project after project, in the organisations that manage to stay in control of their change process rather than endure it. Some will strike certain readers as obvious, others less so.
No. 1: Read the contract as early as possible, with fresh eyes
Contract awareness is a key moment in the contract lifecycle. Immersing yourself in the text that will govern several years of performance is how you discover what was not thought through at drafting stage. No experienced contract manager is surprised by this any more: thinking of everything at drafting stage remains a laudable objective, but one rarely achieved in practice, all the more so as the contract manager is not always involved at that stage (a word to the wise). The initial read, often after signature, then becomes an exercise in discovery as much as in ownership.
Attention should focus first on what are known as false friends. These mechanisms carry a familiar name but conceal specific adjustments. You have certainly been told, for example: “don’t worry, it’s a FIDIC contract”, and you will be tempted to believe that the change mechanisms hold no surprises for you. In many cases, you will in fact discover a FIDIC base fitted with a substantial number of departures. In practice, that reassuring sentence should sound like a warning: the devil is in the detail.
The classic case illustrates the point well. The change process in a contract between a main contractor and its subcontractor provides that any implementation requires the client’s prior approval. The drafter’s intention was no doubt laudable. In use, however, the result is more mixed: changes that do not concern the client end up suspended, while others that genuinely do concern it may run into review lead times incompatible with site realities. This can quickly turn into a false good idea, but one that, when spotted early, is still a false good idea you can do something about.
No. 2: Step out of the text, model the process
The contract’s various provisions rarely make a good management tool for a project team. The text is dense, organised along a legal logic that never follows the order of operations, and riddled with cross-references. To run a change process, the ideal is still to visualise it through a flow diagram, a process chart, or any kind of visual representation: the format matters little, what counts is leaving the paragraph behind and entering the flow.
This modelling also brings two benefits that are underestimated. The first is a consistency test. What holds up poorly in a diagram holds up poorly in execution. Trying to model a process you have not fully understood immediately reveals the areas you skimmed over. In that sense, the exercise protects the contract manager first of all: you can only diagram properly what you have genuinely understood in detail.
The second role is more collective. A project team that knows the change process is worth more than a lone contract manager who has mastered it. For people with no natural appetite for contracts (and there are many), a model always lands better than a stack of clauses. The flow diagram becomes a shared reference (ideally built into a PMP or a CMP), and that is where its full operational value lies.
No. 3: Clear up the grey areas as early as possible
The right moment to discuss a contractual inconsistency or ambiguity with your counterparty is not when the first change arrives. Paradoxically, it is when there is still nothing on the table.
Discussing an unclear clause in the cold light of day allows it to be handled for what it is: a question of method. No one has any particular interest in tilting the reading one way or the other, no one suspects the other of ulterior motives, no one is trying to make the text say what it does not say. The discussion can be strictly intellectual. Once a concrete case is on the table, the same exchange becomes a negotiation. And a negotiation is won or lost; it is not calmly resolved.
This approach amounts to a form of shared operational stocktake. It also has a more diffuse, but very real, effect on what follows. Clearing up the grey areas early contributes, from the first weeks of performance, to the quality of the relationship between the parties. It creates a climate of cooperation in which issues are handled as a team rather than from entrenched positions. On long contracts, that climate counts at least as much as the contract clauses.
No. 4: Equip the process from day one
In practice, two tools make the difference: a change request template, and a consolidated tracking log. There is every reason to put them in place very early, ideally before the first request arrives.
The template sets a standard. Within the contractual provisions on form, deadlines and approvers, it defines the level of detail expected: what the buyer wants to know, what the seller is prepared to provide as standard, the structuring headings, the minimum supporting evidence. Carried out in the cold light of day, this standardisation work defuses a significant share of the operational friction to come. Without it, you quickly fall into familiar situations: the supplier sending requests that are too thin, the client always asking for more, and both sides irritating each other at every exchange.
The tracking log plays a complementary role. It records, it dates, it qualifies origins, it consolidates the view. If there is to be a debate, it takes place on the basis of factual, shared (ideally in a monthly report) and up-to-date information. It is the antidote to the fog that inevitably settles over long or complex projects.
Its contribution is not limited to maintaining a document. It consists above all in orchestrating the cross-checking of perspectives. A rating produced by a single function is almost always biased. The project manager often underestimates the contractual impact, procurement may underestimate a supplier’s impact on the project as a whole, engineering may overlook cost or schedule impacts. Bringing these readings into dialogue makes it possible to refine, challenge and stabilise a shared view.
Without this tooling, everyone can lose a little time, and sometimes a little patience, in handling changes. And that loss is never free. It almost always feeds back into the substance of the handling, which is a shame.
No. 5: Never put off until tomorrow a change you can handle today
An unaddressed change can very quickly end up pending, then in silence. And a change that settles into silence changes nature: what would have been a simple management act becomes, a few months later, a (pre-)dispute matter. Time does not neutralise a badly born change, it lets it rot.
The distinction is worth drawing. You may choose to hold off on a change; sometimes that is the wisest decision. But deliberately holding off and forgetting to act are not two variants of the same behaviour, they are two different worlds. The first is management, the second is drift.
One operational failing deserves a mention, because we often encounter it within engineering teams: the search for the perfect notification. The urge to produce a flawless claim, perfectly documented, statistically unassailable, when the contract requires nothing of the sort. This quest for perfection stretches out lead times, sometimes beyond what the contract tolerates. In trying to do better than the contract requires, you expose yourself to the risk of being time-barred. Discipline, here, does not lie in the isolated excellence of a single form: it lies in meeting deadlines and in the regularity of the flow. A sound notification on time beats a perfect notification out of time.
Conclusion
The five practices shared here are neither revolutionary nor especially complex. They do, however, have one thing in common that is worth underlining: none of them concerns the handling of a change once it has arrived. All of them come before. That is probably the main lesson we draw from observing projects: what makes the difference between controlled change management and a permanent source of tension is almost never the occasional talent brought to bear on a given request. It is the maturity of the arrangements put in place upstream.
A well-handled change stops being a risk you endure. It becomes an act of (contract) management. And only on that condition does it sometimes become an opportunity.