Why Web Development Projects Go Over Budget, and How to Control Scope Creep
Why web and app projects overrun, and how to control change during delivery: a scope-baseline checklist, change-request template, change log and triage table.
Why do web development projects go over budget?
Most overruns are not one big mistake. They are many small, unpriced additions to a scope that was never pinned down: "quick" requests, extra stakeholders, slow decisions, late content and integration surprises, each reasonable at the time. You control them by fixing a dated scope baseline before work starts, sending every change through a short written process with a named approver, and tracking approved changes against a budget you hold. Change is not the problem; change that nobody priced is.
This guide covers change control during delivery, for websites, web apps and mobile apps. What goes into the baseline before you sign is covered in the website requirements document guide, and choosing a contract model in fixed price vs time and materials.
Key takeaways
- Separate scope creep, controlled change and clarification. Only the first is a problem.
- Fix a versioned baseline with numbered requirements and an out-of-scope list before kickoff.
- Send every request through one channel, and triage it as a defect, a clarification or a change.
- Name one approver with budget authority. No work starts before a written decision.
- Keep a change log and a change budget separate from the build budget.
- If you are already over budget, freeze new scope and re-baseline before spending more.
Scope creep, controlled change and clarification
Scope creep is change that enters the project without anyone assessing and agreeing its effect on time, cost and other work. Controlled change is a new, modified or removed requirement that has been assessed, approved by the right person and reflected in the plan and budget. Clarification (project managers sometimes call it progressive elaboration) adds detail to something already agreed, such as the wording of an error message or which fields a filter uses, without changing its intent.
The distinction matters because the cure is different. You should not try to prevent change: the GOV.UK Service Manual says plainly that "In agile, you change your plans as you do more work and learn more about your users" (Planning in agile). What you prevent is change that nobody assessed. The UK government's Contracting for Agile guidance note makes the same point from the buyer's side: the buyer keeps control of scope, including moving user stories up and down the backlog, and the contract structure "should not allow, for example, scope creep" (paras 6.4 and 6.5).
Where overruns come from
| Cause | Who mostly controls it | Early sign |
|---|---|---|
| No clear baseline: scope agreed in calls and emails | Both sides, before signing | Client and supplier describe the same feature differently |
| "Quick" requests sent straight to developers | Client | Work appears in demos that nobody approved |
| Stakeholders outside the process, such as a director, sales lead or investor | Client | Late feedback reopens approved designs |
| Slow decisions and late content | Client | Tasks blocked waiting for answers, copy or images |
| Gold plating: unrequested polish or features | Supplier | Time logged against items not in the backlog |
| Under-estimated integrations or data migration | Both; discovery reduces it | Spikes and workarounds on third-party APIs |
| Defects relabelled as changes, or changes disguised as defects | Both | Arguments about who pays for a ticket |
| Learning from real users | Client | Legitimate, but still needs funding or a trade |
Worth noting
Many causes sit on the client side. That is not a criticism: founders are busy, and a good process makes the cost of a request visible before it is made. Integration and data surprises shrink with proper technical discovery before estimating.
Scope-baseline checklist (before kickoff)
Change control only works against something fixed. The requirements document guide covers what to write; this checklist confirms the baseline is complete enough to judge changes against.
- Requirements document version and date, with every requirement numbered.
- An out-of-scope list agreed by both sides.
- Assumptions written down, such as who supplies content and by what date.
- Client dependencies and named decision owners, with an agreed turnaround for decisions (for example, a set number of working days).
- Acceptance criteria for each requirement or user story. GOV.UK describes these as "a list of outcomes that you use as a checklist" (writing user stories).
- Each integration listed with the owner of the third-party account or API.
- The design sign-off point, after which design changes go through change control.
- Who writes, supplies and loads content.
- Environments, browsers, devices and OS versions in scope.
- A change budget held by the client, separate from the build budget.
- Who may raise changes and who may approve them, by name.
- The contract model and what it says about changes.
The change process in six steps
1. Capture. Every request goes into one place, such as a form, a ticket type or a shared log, not into chats with individual developers. Developers point requests politely to that channel.
2. Triage. Within an agreed time, the supplier's lead and your product owner label the request a defect, a clarification or a change, using the table in the next section. Defects and clarifications go into normal delivery; only changes continue.
3. Assess impact. The supplier estimates effort, the effect on the timeline and other features, new risks, and which tests and acceptance criteria change. Keep it proportionate: a small change needs a short note, not a report.
4. Decide. The named approver chooses one of four options: do it now, swap it for an item of similar size, defer it to a later phase, or reject it. No work starts before a written decision.
5. Update the baseline. Approved changes update the requirements document version, the backlog, the plan and the budget forecast.
6. Communicate. Record the decision in the change log and tell everyone affected, including whoever raised the request.
The UK DDaT Playbook calls "clear and agreed reporting, change management and dispute resolution mechanisms" a critical success factor in supplier relationships, and the GOV.UK guidance on deciding on priorities says priority decisions "should be made regularly". In practice, batch routine change requests into a weekly or per-sprint review and keep a fast path for urgent ones.
Is it a defect, a clarification or a change?
Use this table at the triage step. It is about classifying requests during delivery; handling defects found in acceptance testing, and linking sign-off to the contract, is covered in the user acceptance testing guide.
| Situation | Usually | Why |
|---|---|---|
| It does not meet a written acceptance criterion | Defect | It fails something already agreed |
| Something that worked before has stopped working | Defect | A regression; fix it before new work |
| It misses a written non-functional requirement, such as page speed, accessibility or security | Defect | Measurable requirements are part of the scope |
| The requirement is silent on a detail, and the team needs an answer that fits its intent | Clarification | Adds detail, not scope; answer quickly to avoid delay |
| The request adds a screen, user role, integration, report, rule or data field | Change | Not in the baseline |
| It works as specified, but you now want it to work differently | Change | The baseline was met; the requirement moved |
| A third-party API or platform changed its behaviour | Change, unless the contract gives this risk to the supplier | Neither side caused it, so the contract decides |
| It fails on a browser, device or OS version outside the agreed list | Change | Coverage is part of the baseline |
| Content looks wrong because it arrived late or incomplete | Client dependency | Fix the content and record any delay it caused |
Pro tip
When the label is genuinely disputed, record the disagreement in the log, agree a provisional label so work can continue, and settle it at the next review. Do not let one argument block the whole backlog.
Copyable change-request template
Copy this into a document, form or ticket template. The requirement IDs and baseline version tie each change to the requirements document, so nobody has to argue later about what was originally agreed.
CHANGE REQUEST
CR ID: CR-___
Date raised:
Raised by:
Requirement IDs affected: (from requirements document v__)
Type: [ ] New scope [ ] Modified scope [ ] Removed scope
Description: What should change, in one or two sentences
Reason and value: Why it matters now (users, revenue, compliance, risk)
IMPACT (completed by the delivery team)
Effort estimate: (range, with assumptions)
Timeline effect: (none / release date moves by __)
Other features affected:
Risks introduced:
Tests and acceptance criteria to add or change:
OPTIONS
[ ] Do now, from the change budget
[ ] Swap for item(s) of similar size: ____
[ ] Defer to phase __
[ ] Reject
DECISION
Decision:
Approved by: Date:
Baseline updated to: requirements document v__Keep a change log
The log is the single view of every change, its decision and its effect on the baseline. A spreadsheet is enough. The entries below are hypothetical, for illustration only.
| CR ID | Requirement | Summary | Type | Effort estimate | Decision | Approver and when | Baseline |
|---|---|---|---|---|---|---|---|
| CR-01 | R-14 | Add CSV export to the orders report | New | 2 to 3 days | Do now, from change budget | Product owner, week 3 | v1.1 |
| CR-02 | R-22 | Replace map search with postcode search | Modified | 4 to 6 days | Swap: R-31 (saved searches) moved to phase 2 | Product owner, week 5 | v1.2 |
| CR-03 | New | Second language | New | More than 10 days | Deferred to phase 2 | Founder, week 5 | v1.2 |
| CR-04 | R-08 | Remove social login | Removed | Saves 1 to 2 days | Do now | Product owner, week 6 | v1.3 |
Key takeaway
The swap rule: under a fixed price per phase or a capped budget, a change can often be absorbed without new money by removing an unstarted item of similar size. Both sides must agree the sizes are comparable, and the swap is logged like any other change. Swaps only work for work not yet built, so make them early.
Early warning signs to track
- Budget used against scope accepted: at every milestone or sprint review, compare the share of budget spent with the share of scope accepted.
- Change budget used: the total of approved changes against the change budget you set aside.
- Open requests: how many changes are waiting for a decision, and for how long.
- Decision time on your side: how long clarifications and approvals take.
- Unplanned work: time spent on items not in the backlog.
Worth noting
These are prompts for a conversation, not benchmarks. There is no reliable universal figure for a healthy number of changes; compare against your own plan.
If the project is already over budget
Re-baselining is not an admission of failure. It turns an argument about the past into a decision about the future.
- Freeze new scope until the position is clear. Defect fixing and approved work continue.
- Re-baseline: list what is accepted, what is in progress and what is left, with fresh estimates for the remainder.
- Re-prioritise what is left using MoSCoW. GOV.UK defines must haves as "essential things that your product cannot function without" and will not haves as "low priority things that the team has agreed not to do".
- Cut to the release goal: the smallest version that achieves the outcome you need now.
- Agree the remaining budget or cap in writing, and restart change control from the new baseline.
- If trust has broken down, get an independent review of the code and plan before committing more money, and check what your contract allows at the next break point.
Hypothetical example: a request that bypassed the process
Hypothetical example: a training company is building a course-booking web app with a capped budget for the first release. In week four, the sales director emails a developer asking for corporate invoicing. Under the new process, the developer logs the request instead of starting work. Triage marks it a change: it adds a payment method and an accounting integration that are not in the baseline.
The impact note gives an effort range, a two-week delay to the release and new tests for refunds. The founder, as approver, defers full invoicing to phase two and approves a smaller change instead: a "request an invoice" form that the team handles manually for now. The change log, baseline version and budget forecast are updated the same day, and the sales director gets a written answer with the reason.
Limits: when change control gets in the way
Change control has costs. A process that needs a form and a meeting for every wording tweak slows a small team and encourages people to work around it. Set a threshold so clarifications are agreed in the ticket and only real scope changes use the full template.
A supplier can also use change control defensively, labelling every clarification as a paid change. If most requests end up priced, review the baseline quality and the triage rules together rather than arguing ticket by ticket.
On very early products where the goal is learning, a time-boxed budget with a backlog you own may work better than detailed change requests; the discipline moves to prioritisation rather than approval. And the contractual effect of variations differs between countries, so take local legal advice before a disagreement turns into a dispute.
Sources
GOV.UK: Contracting for Agile guidance note (updated 20 June 2023).
GOV.UK: The Digital, Data and Technology Playbook (updated 20 June 2023).
GOV.UK Service Manual: Planning in agile (updated 31 March 2026); Deciding on priorities (updated 6 December 2018); Writing user stories.
Accessed 15 October 2026. Guidance may be revised; check the current versions.
Conclusion and next steps
Budgets rarely blow up in one go. Before kickoff, fix a versioned baseline with an out-of-scope list and named approvers. During delivery, run every request through capture, triage, impact, decision, baseline update and communication, and keep the change log and change budget visible. If you are already over, freeze, re-baseline and re-prioritise before spending more. For help planning or rescuing a build, see our web application development services.
Project drifting, or about to start one?
ZSpace Labs is a remote-first technology studio that works with clients globally on web applications and mobile apps. If useful, we can review your scope baseline and change process, or talk through a project that has drifted.
Common questions.
Scope creep is change that enters a project without anyone assessing and agreeing its effect on time, cost and other work. Approved, priced changes are not scope creep, and nor is clarifying detail within a requirement that was already agreed.