Three Scope Addendums in Four Months, All After the First Escalation

A change to a signed contract arrives looking like housekeeping. Two parties have agreed something, both have put it in writing, and the document that lands in the shared drive is evidence of a relationship that still works. That reading is ordinary, it is usually correct, and it is why the sequence in this piece stayed unread for as long as it did.

I worked on an independent post-mortem review of a failed offshore build for a European banking group's IT services subsidiary. The subsidiary had outsourced the first phase of a customer-facing securities advisory application to an offshore development partner, hit quality and schedule trouble, granted a last-chance grace period, and eventually terminated the statement of work and took the build back in house. Part of the review was a chronological fact base assembled from the contract documents and the email record, each beat labelled in plain language: change of vendors, offshoring, issues from the start, issues continue, grace period, terminate contract.

Three of those beats are scope-change addendums to the outsourced contract. On their own they are unremarkable. Placed against their own dates they stop being administration.

The order the documents actually arrived in

The subsidiary entered the contract effectively at the start of the engagement, and the completed outsourced contract was signed about nine weeks later. That gap matters, because delivery issues were visible from the beginning and were first flagged roughly eight weeks in, which puts the first flag about a week before the paperwork was finished. The completed contract was signed against a build that was already showing problems.

Roughly eleven weeks after the effective date, code quality was raised as a formal escalation in the steering committee. A second escalation, this one on data context, followed about four weeks after that.

Addendum one was shared about six weeks after the completed contract was signed, which is about four weeks after the first formal steering escalation and roughly concurrent with the second. Addendum two came about nine weeks after addendum one. Addendum three came about seven weeks after that, a little over five months after signature. All three sit inside a window of under four months, and each is referenced in the review record to a source email, which is how the reviewer was able to date them at all.

After the third addendum, delivery quality kept falling, timelines kept slipping, and the application was crashing and behaving erratically rather than approaching user acceptance testing. A ten-week grace period was granted and produced no application stable enough to enter UAT. The statement of work was terminated about eleven weeks after the third addendum. The source gives the grace period its length but not its dates, so I cannot place it precisely inside that gap. What the gap itself says is plain enough: a contract was still being amended within about eleven weeks of the decision to end it.

Why nobody counts them

A change request is designed to close something. It names a delta, prices it, and gets a signature, and the signature is the point at which the item stops being open. Filing systems are built around that assumption: the change log records what was agreed, and a well-maintained change log with three closed entries looks like a well-governed project.

The rate is a different object entirely, and it has no owner. Scope changes are approved one at a time, often by different people, each against the merits of that change. A delivery manager sees an addendum. A commercial lead sees an addendum. The steering committee sees a delivery escalation on one agenda item and a contract amendment on another, and there is no line on any report that reads scope changes per quarter, still less scope changes since the escalation opened. The instrument was never assembled, which is a different failure from having an instrument and ignoring it.

An addendum is written as a resolution and filed as one. Three of them inside four months is not three resolutions, it is a rate, and nothing in the governance structure was responsible for reading it.

That distinction is worth holding, because the same review has already been read the other way round. A published finding from this engagement, The Revised Plan Forecast 471 Extra Person-Days and the Team Stayed on the Old One, records a case where the measurement existed, was written down while the build was still running, and triggered nothing. That is a missing trigger on a live instrument. The addendum sequence is the layer underneath: three readings taken, each filed as a closed transaction, with no instrument in existence for them to be readings of.

Timestamp the change log against the escalation log

The practical version of this is small enough to do on a Tuesday afternoon, and it needs no new tooling.

Take your change register and your escalation or issue register, and put them on one timeline. For every approved scope change, record whether an escalation was open on the day it was agreed. That single flag separates two things that look identical in a change log and mean opposite things.

A scope change agreed with no escalation open is usually learning. Somebody understood the problem better, the specification moved, and the contract caught up. That is what change control is for and it is a sign of a functioning engagement.

A scope change agreed while an escalation is open is a different animal. It may still be the right change. But it is being negotiated by two parties who are already in dispute about delivery, under time pressure, with at least one of them motivated to convert a performance conversation into a scope conversation. Three of those in a row, with the escalation still open at the end of them, is a pattern with one honest description: the contract is absorbing a delivery problem rather than the delivery problem being fixed.

Nobody needs to adjudicate intent to use this. The flag is mechanical, both registers already exist in any governed programme, and the count is the finding. If your last four scope changes all post-date an open escalation, the change log has stopped describing scope and started describing pressure.

What agentic delivery does to the rate

This gets more useful, not less, as delivery becomes agentic, and for a reason that runs against intuition.

Scope on an AI programme moves for legitimate reasons far more often than scope on a conventional build. The capability boundary of the model shifts, evaluation results send you at a different problem, retrieval turns out to work on one document class and not another, and a use case that looked like classification turns out to need a human in the loop. Change is the normal condition. Meanwhile the cost of absorbing a change is collapsing: a spec revision that used to mean a re-planning cycle can now be turned around inside a sprint, so the friction that used to make scope movement visible is disappearing.

Both of those push the addendum rate up and the salience of any individual addendum down. The raw count therefore becomes a worse indicator every year, which is exactly why the escalation flag is the part worth keeping. Scope moving while nothing is escalated is the healthy signature of a programme that is learning in public. Scope moving while an escalation is open is the same warning it was on this build, and the shorter the delivery loop, the faster the pattern accumulates.

There is a governance consequence that follows directly. If the flag is going to mean anything, the escalation register has to be something other than a document one party maintains about itself. The state of an escalation on a given date needs to be recorded as it happens, from the delivery record rather than from a status summary, or the timeline you eventually build will show every change request arriving on a clear day.

3

Scope-change addendums, all inside a window under four months

0

Addendums that predate the first formal steering escalation

~11 weeks

From contract effective date to that first escalation

10 weeks

Grace period, which ended with no application fit for UAT

Drawn from the chronology page of an independent post-mortem review of a failed offshore application build at a European banking group's IT services subsidiary, work I led at a consulting firm and which is that firm's engagement. The addendum count, the escalation beats, the grace period and the termination are the page's own, dated in the source and reported here only as intervals. The review produced findings and recommendations after the statement of work had already been terminated, not a recovered project. Reading the addendum sequence as a rate rather than as three agreements is ours, and the source does not draw that conclusion.