When the Brief Moves: Keeping Mid-Project Adjustments on the Record

Most consultancy projects do not drift because someone makes a dramatic request. They drift because a series of reasonable-sounding additions arrives after the brief has been agreed. A colleague asks for one more interview. A director wonders whether the adviser could also look at a second site. Someone suggests a short implementation plan while the consultant is already close to the subject. Each request may be small. Taken together, they change the shape of the work.

The discipline of scoping down is usually discussed at commissioning stage. It is equally important once the project is live. At that point, the question is not only whether the work is worthwhile, but whether it has been formally accepted as a change. A short written record — a change note — gives UK clients a calm way to make that decision visible.

Why verbal adjustments become invisible overruns

Mid-project changes often feel too minor to document. That is precisely why they accumulate. A request made in a corridor or on a video call may be remembered differently by the client and the consultant. One party thinks it was a suggestion. The other treats it as an instruction. By the time the invoice or final report arrives, the disagreement is no longer about the work itself but about what was agreed.

A change note does not prevent sensible adjustments. It prevents them from becoming invisible. It records that a choice was made, who made it, and what it displaced. That is useful for the client, the consultant and anyone who later has to review the project.

The note also protects the original brief. If every new idea is absorbed without comment, the project can lose its centre of gravity. The client may end up paying for breadth rather than depth, while the consultant may end up delivering more activity but less value.

A one-page record, not a change-control bureaucracy

The phrase change control can sound heavy. It brings to mind committees, numbered forms and long approval chains. For many UK engagements, that would be disproportionate. A change note should be a one-page working document, not a parallel project.

Its purpose is simple: to capture a proposed adjustment in enough detail that a reasonable person can decide whether to accept it. It should be written in plain language and kept with the project papers. It does not need to be legalistic. It does need to be clear.

A practical template can be kept to four short sections.

1. The request

State what has been asked for in one or two sentences. Include the date, the person making the request and the part of the project it affects. For example: 'Additional interviews with two regional operations managers, requested by the client sponsor on 3 March, to test the draft findings.'

2. The displacement

This is the field that does most of the work. Every additional request takes the place of something else: time, budget, attention or a deliverable. The note should say what will move, shrink or stop if the change is approved. If nothing is displaced, say so explicitly. That may be a sign that the change is genuinely small, or that the original brief contained unused contingency.

3. The cost and timing effect

Record any effect on fees, expenses, deadlines or dependencies. If there is no cost, write 'no change to fee or timetable'. If the effect is uncertain, say what needs to be checked before approval. Avoid leaving this section blank; a blank field is easily read as 'no impact' when that may not be true.

4. The decision

Name the person who approved, deferred or declined the change, with the date. Include a short reason if the decision needs context. If the change is approved, note any conditions, such as a revised deadline or a corresponding reduction elsewhere. If it is deferred, say when it will be reconsidered.

A short reference line at the top — project name, note number and date — is enough for filing. There is no need for a separate system unless the project already has one.

When a change note is proportionate

A change note is most useful when the request affects one of four things: the agreed deliverables, the fee, the timetable or the risk profile of the work. It is also useful when a request comes from someone who is not the named client owner, or when the same small request has been made more than once.

Typical examples include an extra workshop, a second market or site, additional interviews beyond the agreed sample, rework after a deliverable has been signed off, or a request to add implementation planning to a diagnostic brief. In each case, the client is not simply asking for a little more time. They are changing the bargain.

A change note is usually unnecessary for administrative adjustments that sit inside the agreed scope: moving a meeting, correcting a name, clarifying a sentence in a draft, or swapping one interviewee for another within the agreed sample. These can be recorded in the ordinary project log or meeting notes. The test is not whether the request is small in absolute terms, but whether it alters what was promised.

If in doubt, a short note is usually the safer choice. It can be closed in a few lines. An undocumented change, by contrast, can take far longer to resolve later.

Keeping the habit light

The change note should not become a bottleneck. At the kick-off, agree who on the client side can approve changes and what level of adjustment that person can authorise. A single named owner is better than a committee. If the owner is unavailable, agree an interim route rather than letting requests sit unresolved.

Review open change notes at the regular project check-in. At close-out, include a short summary of approved changes alongside the final report. That summary helps explain why the project looks different from the original brief, and it gives the invoice a clearer context.

The note should live with the project record, not in someone's inbox. A shared folder or a short appendix to the project file is sufficient for most engagements.

A written choice, not a written warning

A change note is sometimes mistaken for a sign of distrust. It should not be. It is a sign that the client values the project enough to make its adjustments deliberately. Consultants should welcome the clarity, because it protects them from unpaid extra work and from later disagreement about what was in scope.

Mid-project drift is rarely dramatic. It is usually a collection of small, well-meant requests. A one-page note turns those requests into decisions. That is not bureaucracy. It is the ordinary discipline of keeping a project honest.