Where does an overrun actually begin?

Not in week six, when the job is visibly running hot. It begins months earlier in a twenty minute conversation, when a partner described the work, the client nodded, and nobody turned that into something either side could point at later.

What follows is a fee proposal with a paragraph of description, a number, and assumptions borrowed from the last proposal that went out. The paragraph reads well. It is also silent on everything that matters: how many rounds of comment, how many sites or entities, whose data, what happens when the client is late. Nobody notices at the time, because both sides are reading it the same way, which is to say generously.

Three months in, the readings part company. The client asks for something they believe was included. The fee earner believes it was not. Neither can prove it, so the firm does the work rather than have an argument it does not want. Repeat that across a year and you have a margin problem that presents itself as a delivery problem.

Why does the firm always absorb the difference?

Because whoever holds the record wins, and in most firms nobody holds one. The scope sits in a proposal, two emails, a call that was never written up, and the memory of a person who has moved on to other work. Reassembling it costs more senior time than the disputed task.

There is a less comfortable reason too. Raising a change is socially expensive. It means telling a client you want to keep that what they just asked for is not free. Fee earners dodge that by quietly doing the work and hoping to make it back somewhere. The firm never learns, because the time surfaces as ordinary write-off rather than as a change that went uncharged.

So the leak runs one way. Work moves into the scope and never out of it. That is not a pricing fault. It is a record keeping fault, and it worsens as a firm grows and the person who had the original conversation is no longer the person delivering.

Doesn't a tighter contract solve this?

Terms help in a dispute and do nothing on a Tuesday. Engagement letters are written once, in language built to protect the firm, and the delivery team never opens them. When a client asks for one more scenario or one more consultee response, nobody checks the contract.

What the team needs is a working document in plain operational terms, visible to everyone on the job. The contract protects you in an argument. The scope document stops the argument starting.

Sharper estimating has the same limit. Better fee estimating prices the job you mean to do. It says nothing about work added later that nobody logged. Two different leaks, and firms routinely fix the first while the second runs on.

What belongs in a scope document?

The test is simple: could a new team member read it and know, without asking anyone, whether a given request is included?

  • Deliverables, counted. Not "a report", but how many, in what format, to whom.
  • Rounds of comment. How many are included and what the next one costs.
  • Inputs the client owes you, named and dated. Much of what looks like scope creep is waiting, chasing and rework caused by late or poor client information.
  • Explicit exclusions. The things a reasonable client would assume are in and are not. This is the section firms skip and the one that earns its keep.
  • Assumptions with consequences. An assumption that does not say what happens when it fails is decoration.
  • Who may authorise a change, on both sides.

None of this is novel. It goes undone because writing it properly takes an hour of senior attention at precisely the moment that person is trying to win the work and move on. So it gets typed from memory, fast, and thins out with every reuse, which is the decay described in why templates rot.

Why does the change log matter more than the scope?

A scope document fixes one moment. A change log keeps it honest. Without one the scope is accurate on day one and fiction by day thirty, and you are back to arguing from memory.

In a firm of 20 to 200 people this is not a formal variation procedure. It is a running list: what was asked, when, by whom, what it adds, whether it was accepted, whether it was charged. One line, one minute.

It also transforms the end of the job. A client who has had eleven short notes along the way, each saying this sits outside what we agreed and here is what it adds, is not startled by the final invoice. A client who gets one unexplained uplift feels ambushed, and that feeling is what turns an overrun into a billing delay and then a write-off.

How does the process keep the record instead of the people?

Asking busy fee earners to be more rigorous has been tried everywhere and holds for about a quarter of them. The alternative is to make the record fall out of work that already happens.

The scoping conversation happens anyway. Capture it, structure it, and the deliverables, exclusions, assumptions and client inputs arrive as a draft in the firm's own format for a partner to correct and approve rather than compose. That is the logic behind scope documents and meeting notes and follow-ups.

Mid-engagement, requests arrive by email or on calls. A process that reads each one against the agreed scope, flags what sits outside it and drafts the change note is doing in seconds the thing a fee earner would rather not do at all. A named person still decides whether to charge. The difference is that the decision gets made in daylight.

Firms pricing by stage feel this hardest. Architecture practices and engineering consultancies both agree a fee and then absorb round after round nobody logged. The vocabulary differs by sector; the leak is identical.

Where should a firm start?

Take your last twenty fixed fee engagements. Write down the quoted fee and the recorded time. For every one that went over, answer a single question: had you written that extra work down as excluded? If you cannot tell, that is your finding.

Then read three recent scope sections aloud and ask whether a junior could use them to decline a request. If not, you have a marketing paragraph, not an operational document.

Finally, choose. Short engagements? Fix the scope. Long ones that change constantly? Fix the log. Either way it is one process rebuilt properly, not a programme. If you are unsure which leaks most, the audit will point at it, and the guide to documenting a process covers capturing what your best people already do before you change a thing.