Small Requests, Large Consequences: A Change-Control Routine for UK Project Teams

A request lands on a Tuesday afternoon: could we just add one extra field to the reporting screen? It is an hour's work, perhaps two. The project lead says yes, because refusing something so small feels disproportionate. Six weeks later that field has passed through design, build, test, release notes, a training update and a support handover, and go-live has slipped a fortnight.

That is the while-we're-at-it tax. It rarely arrives as dramatic scope creep. It arrives as a series of modest indulgences, each individually defensible, which between them consume the margin the project was priced on and the goodwill the team had banked.

The cost sits away from the work

The estimate attached to a small change usually covers only what is visible: the code, the document, the extra line on the drawing. Everything else is carried by the wider programme.

• Coordination. Another conversation between two teams, another decision to record, another meeting to schedule.
• Assurance. Regression testing, user acceptance, re-approval, a fresh entry in the audit trail.
• Communication. Updated guidance, briefings, a revised training script.
• Sequence. Work that waits behind the change, and dependencies that were settled now unsettled.
• Support. Runbooks, handover notes, the person on the service desk who fields the first questions.
• Contingency. Drawn down quietly, so nobody notices until the month it is genuinely needed.

None of this appears on the request. All of it appears in the outturn.

Five questions before you answer

The screen below is not designed to produce a refusal. It is designed to produce a number, or at least an honest sense of one, so the decision is made with the same discipline as any other call on resources.

1. Who has to agree? Count the approvers, including those whose sign-off is informal but real. Time-to-yes is itself a cost.
2. What stops while this is done? Named people, named tasks. If the answer is genuinely nothing, ask again.
3. What must be retested or re-approved? Components that have already been signed off are the most expensive kind of small change.
4. Who must be told, trained or supported afterwards? An addition users do not know about is not an addition; it is a defect waiting to be reported.
5. Where does it fall against the next milestone? Before the gate is a different decision from after it.

A request that survives all five is usually worth doing, and often worth doing now. One that fails two or three has told you something useful.

Worked example: the fixed-price installation

A UK manufacturer was midway through installing a warehouse management system on a fixed price. The client asked for three additional pick-face label formats and a tweak to the returns screen. Neither request was unreasonable. Neither was quoted.

The visible work came to roughly three days. The real figure was closer to nine once integration testing, two supervisor briefings and a revised set of operating instructions were counted, and the milestone moved by eight working days. Three requests of similar character followed that quarter. Between them they absorbed more than half the project's contingency, and the argument about the overrun happened in month five rather than in month two, when it might still have been avoided.

On a fixed-price contract the money is not the only exposure. The closing conversation is.

Worked example: the internal project

Internal projects hide the same tax behind a different mechanism. A finance team replacing an expenses process agreed four small additions at the request of two other departments. There was no invoice, so there was no argument, and nobody had to approve anything.

The cost surfaced as borrowed analyst time: three weeks of a management accountant's availability, taken straight out of month-end close. It also surfaced as dual running, because the change pushed decommissioning of the old system into a second quarter. By the time anyone added it up, the project had a sponsor who felt ambushed and a team that felt unappreciated. Neither reaction was fair. Both were predictable.

A change log that fits on one page

The instrument that makes this manageable is unglamorous. Keep a single-page log, updated at the point of request, with the following columns:

• Date received, and who asked
• The request, in one sentence
• Who benefits, and how they would notice
• Estimated effort in days, with a name attached
• Systems, teams and dependencies touched
• Test and assurance impact
• Communication and training impact
• Milestone affected
• Decision, decision-maker and date

Review it for ten minutes in the weekly delivery meeting. The value is not in the record-keeping; it is in the visibility of accumulation. One small change is a small change. Eleven small changes are a re-plan that nobody scheduled.

The threshold that triggers a formal re-plan

Set the tripwire before the requests arrive, when nobody is invested in a particular answer. A workable rule for most UK project teams is that any single change, or the cumulative flow of changes, triggers a formal re-plan when one of the following holds:

• Effort exceeds two days of a named resource.
• A committed milestone date moves, even by a single day.
• A component already signed off must be retested.
• Cumulative accepted changes exceed 5 per cent of contingency on a commercial project, or 3 per cent of budget on an internal one.

Below the line, the project lead decides and records. Above it, the sponsor decides with the log in front of them. The distinction matters: it protects the lead's authority on small matters and the organisation's money on large ones.

Declining without stalling

Outright refusal is rarely necessary. Three responses cover most situations. Defer to a named later phase, with a date attached. Trade rather than add, swapping the new request for something of similar size already in the plan. Or time-box the investigation, so the requester receives an answer within a week rather than an open-ended yes. Each keeps the relationship intact and the plan honest.

The discipline is not about saying no to small requests. It is about pricing them properly, so that accepting one becomes a decision rather than a reflex.