Scope, Change Control, and What It Means to Move a Baseline
Scope creep is rarely a creep. It is a series of reasonable yeses, each defensible on its own, that nobody added up.
A baseline is the plan as it stood at the moment it was agreed: the dates, the effort, and the fee. Its entire purpose is to be a fixed point that later reality can be measured against. A plan that is edited freely is not a baseline, it is a current opinion, and an engagement measured against a current opinion is always on track by definition.
Change control is the process by which that fixed point is allowed to move. It exists so that movement is visible, priced, and approved by somebody entitled to approve it. When it works, an engagement that ends three weeks late and fifteen per cent over its original fee can account for every day and every pound. When it does not work, the same engagement ends in the same place and the conversation is about who is at fault.
What a change request has to carry
A change request that says what somebody wants is a note. A change request that can be decided carries four things, and a board that is asked to approve one without them is being asked to guess.
- The change itself, in enough detail that two people would implement the same thing.
- The cost impact, as a number, including the effort and any third party spend.
- The schedule impact, in days, against named milestones rather than in the abstract.
- What happens if it is refused. This is the field boards most often skip and the one that most often changes the decision.
The states a change moves through, and why they matter
A change request is not either open or closed. It moves through states, and the states exist because different people act at each one. Drafted, submitted, assessed for impact, with the board, and then approved, rejected, deferred or withdrawn. Implemented is a separate state again, because approval and delivery are different events and a firm that conflates them will report work as done that has not started.
Two of those states are commonly missing and both cost money. Deferred is not the same as rejected: a deferred change comes back to the same board on the same assessed impact, and treating it as rejected means the work is re-scoped from scratch when it returns. Withdrawn is not the same as deleted: a change the client asked for and then decided against is a fact about the engagement, and deleting it removes the evidence that the request was made.
What approval should actually move
This is where most implementations are weakest. An approved change that updates a status field and nothing else has recorded a decision without acting on it. Approval should move three things together: the approved change value on the engagement, the affected dates, and the baseline itself. If those three do not move as one action, they will diverge, and the divergence will be discovered at the point somebody tries to reconcile the fee.
One thing approval should never move is the signed contract value. The original contract is a fact about what was signed, and a system that overwrites it loses the ability to answer the most basic commercial question a firm faces: what did we agree originally, and what has been added since. Keeping the two separate, with the approved change value alongside the contract value, is what makes cumulative drift measurable at all.
Cumulative drift, and the ten small changes
The failure that ends engagements is almost never one large change. It is ten changes of two per cent each, every one of them reasonable, approved by different people over four months, none of them individually worth escalating. At the end the engagement is twenty per cent larger than it was sold and nobody made that decision.
The defence is to measure drift against the original baseline rather than the last one. If every approval re-baselines and the next change is measured against the new plan, the system will report that the engagement is on track at every point in its life, right up to the moment it is thirty per cent over. Measuring cumulative movement against the point of agreement is the only version of this number that can raise an alarm.
A threshold on that cumulative figure is worth setting explicitly. Past some percentage the engagement is no longer the one that was accepted, and the right response is a formal re-scope with a fresh commercial conversation, not another change request.
Making change control survive contact with delivery
- Keep the raising step trivial. If logging a change takes longer than doing the change, people will do the change.
- Assess impact before it reaches the board, and require the assessment to include what happens if the change is refused.
- Give the approval chain real structure: who must answer, who may abstain, and who holds a veto. A veto that can be outvoted is not a veto.
- Show the client the change and its impact at the moment it is raised, not at the end. A client who has seen a priced change cannot reasonably claim it was assumed to be included.
- Report drift cumulatively and against the original, every period, whether or not anybody asked.