The delivery date has moved twice, the backlog is larger than when work started, and every status meeting produces new requirements. Adding people at this stage typically makes it worse. Before deciding anything, separate what genuinely grew from what was always required but was never written down clearly enough to estimate.
01Distinguish additions from discoveries
New scope is a stakeholder asking for something that was not previously requested. Discovered scope is work that was always necessary but invisible at estimation - a data migration nobody accounted for, an integration whose complexity was unknown, a compliance requirement surfaced late.
These need different responses. Additions are a prioritisation conversation with the person requesting them. Discoveries are an estimation problem, and treating them as scope creep produces a blame dynamic that makes people stop reporting them early.
| Type | Example | Response |
|---|---|---|
| Genuine addition | A new report nobody asked for before | Prioritise against existing scope |
| Discovery | Legacy data needs cleansing first | Re-estimate and communicate |
| Ambiguity resolved | 'Reporting' turned out to mean twelve reports | Write acceptance criteria |
| Gold plating | Configurability nobody requested | Cut it |
| Rework | Built the wrong thing | Fix the feedback loop |
02Vague requirements expand silently
A requirement stated as a feature name rather than as observable behaviour will be interpreted differently by everyone who reads it. 'User management' can mean a list of users or a complete permissions system with delegated administration, and the estimate was made against the smallest reading.
Write acceptance criteria before estimating. If a requirement cannot be expressed as specific behaviour a person could verify, it is not ready to be estimated, and estimating it anyway is where most overruns originate.
03Make the trade-off explicit every time
Scope grows when additions are accepted without anything being removed. The mechanism that prevents this is simple and mostly social: every addition comes with a stated cost and a decision about what moves out of the release to accommodate it.
That conversation is easier with a prioritised list. When a stakeholder can see exactly which item their request displaces, the discussion becomes a genuine business trade-off rather than a request that gets absorbed silently by the delivery team.
| Option | Effect | Risk |
|---|---|---|
| Cut scope to the deadline | Ships on time, less included | Requires honest prioritisation |
| Move the deadline | Full scope delivered | Downstream commitments affected |
| Phase the delivery | Core value ships first | Needs a coherent first phase |
| Add people | Rarely helps in the short term | Onboarding slows the existing team |
| Reduce quality | Appears faster briefly | Repaid with interest, usually soon |
04Re-forecast from measured progress
A plan that has slipped twice will slip again if re-planned with the same assumptions. Use the delivery rate actually observed over recent weeks rather than the rate originally assumed, and be explicit that this is what the evidence supports.
Present a range rather than a date. A single date implies a precision that does not exist and gets treated as a commitment; a range with the assumptions behind it invites the trade-off discussion that produces a realistic plan.
05Ship something valuable early
Long projects with a single delivery at the end concentrate all risk at the point where there is least time to respond. Sequencing so that a usable subset ships early produces feedback while it can still change direction, and it protects some value if the schedule fails entirely.
This also changes the conversation with stakeholders. Working software in production is a far better basis for discussing what to build next than a document, and it tends to reduce speculative requests because people can see what exists.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer