Table of contents5 sections
The project has been quoted, the scope accepted, the schedule set. Delivery goes to plan until the client starts submitting more “small” requests.
A new filter in the panel. An extra field in a form. One more view variant. A change to a previously accepted process. A small integration that “surely shouldn’t take long”.
Each of these requests on its own seems too small to start a formal scope change procedure. The team wants to keep a good relationship with the client, so it does the task within the project.
After a few weeks, however, it turns out that the additional work took dozens of hours, the time budget has been exceeded, and the planned margin has almost disappeared.
We know what it is like when a project loses profitability not because of one big mistake, but because of a series of small decisions made every day.
Scope creep in an IT project begins precisely when the scope grows without the price, deadline and budget being updated at the same time. To limit it, you need to tell a correction from a new feature, record every change and show its total impact on the project cost.
The project has been quoted, the scope accepted, the schedule set. Delivery goes to plan until the client starts submitting more “small” requests.
Why do free corrections lower an IT project’s margin so quickly?
The client does not always knowingly try to widen the scope without an extra charge. Often it is only during delivery that they understand the product better, notice new needs or change earlier assumptions.
The change itself is not the problem. The problem appears when the team carries it out without assessing the impact on the budget.
“It’s only two hours” is repeated many times
A single request may indeed take two hours. But you also have to account for:
- analysing the requirement,
- consulting the team,
- changing the UX or UI design,
- development,
- testing,
- code review,
- deployment,
- communicating with the client,
- updating documentation,
- possible corrections after acceptance.
A task that looks like a quick change from the client’s perspective may involve several people and generate a much higher cost.
If similar requests appear every week, their total value stops being insignificant.
The team wants to help the client
Specialists usually concentrate on solving the problem. If the client asks for a change, the developer or designer often starts looking for a way to do it, instead of first analysing the impact on the scope of the contract.
In service companies there is also a strong psychological mechanism at work:
- we don’t want to make the collaboration difficult,
- the client may think we are not flexible enough,
- preparing a quote will take longer than the correction itself,
- we’ll make up those hours in the next stage,
- this is an important client, so let’s make an exception.
As a result, the financial decision is made by someone who does not always know the project’s budget and current margin.
There is no clear definition of a correction
One of the biggest sources of conflict is the lack of a distinction between a bug and a scope change.
A bug fix is bringing the solution into line with the approved specification.
A scope change, on the other hand, can be:
- a new feature,
- a change to a previously accepted solution,
- an additional integration,
- another view variant,
- an increase in the number of users or processes,
- a new technical requirement,
- an additional migration stage,
- a change resulting from a new business decision by the client.
If the contract and the project process do not define this difference, the client may treat every change as a correction covered by the price.
Additional hours disappear into the general project time
Even when the team reports time, additional work often ends up in ordinary project tasks.
After a few months the company sees that the budget has been exceeded, but cannot answer:
- how many hours came from a wrong estimate,
- how many were spent on bug fixes,
- how many the client’s new requirements took,
- what the value of work done for free was,
- which changes were accepted,
- what impact they had on the margin.
Without such a breakdown it is hard to draw conclusions and prepare a fact-based conversation with the client.
How to limit scope creep in an IT project?
Effective change management does not mean refusing the client every additional request. The point is that every change should be a conscious business decision.
1. Define the scope and acceptance criteria before work starts
The more general the scope, the more room for different interpretations.
The documentation should specify:
- which features will be built,
- which processes the project covers,
- which integrations are part of the quote,
- how many design variants are planned,
- how many rounds of corrections the price includes,
- what completing a stage means,
- what the acceptance criteria are,
- what the project does not cover.
It is also worth describing the procedure to follow when new requirements arise.
2. Introduce a simple process for submitting changes
The procedure cannot be so elaborate that the team bypasses it for every smaller request.
Every change should have:
- a short description,
- the person who submitted it,
- the submission date,
- the project and stage,
- an assessment of whether it falls within the scope,
- the estimated number of hours,
- the cost,
- the impact on the schedule,
- the acceptance status.
This way even small requests do not vanish into messages, conversations and task comments.
3. Separate bugs, in-scope corrections and additional work
Each request is worth classifying into one of the categories:
Contractor’s bug
The solution does not work according to the accepted specification. The cost of the fix is borne by the contractor.
Correction within the agreed scope
The change fits within the agreed number of rounds or the project buffer.
New scope
The client changes a requirement or adds an element that was not included in the quote. The work requires separate acceptance.
This breakdown organises communication and reduces discussions about who should cover the cost.
4. Show the total impact of changes on the budget
A single change may be small, but the client should see their sum.
Example:
- form change: 4 hours,
- additional view: 10 hours,
- new report: 12 hours,
- integration extension: 16 hours,
- further consultations: 6 hours.
In total that is 48 additional hours.
If the company shows the client only the latest change, it may seem insignificant. A summary of the whole additional scope shows the real scale of the effort.
How did we solve scope creep at Administy?
While running agencies and delivering digital projects, we ourselves repeatedly did additional work without a formal scope change.
Most often this was not down to one big order. The problem was the client’s small requests:
- one more version of the design,
- an additional subpage,
- a new form variant,
- another integration,
- a change to a previously accepted view,
- an extra meeting,
- a correction resulting from a new business decision.
Each one on its own seemed small. The team did it because it did not want to stop the project or complicate the relationship with the client.
The mistake was that the additional hours went into the general project time. We saw budget use growing, but could not always say clearly what part of the cost came from the wider scope.
That is why we started recording additional work as separate items.
Each change receives:
- a description of the additional requirement,
- the estimated number of hours,
- the people needed to deliver it,
- the individual labour cost of the specialists,
- the impact on the deadline,
- the acceptance status,
- additional revenue or information about work done for free.
Then hours are assigned directly to a given change, and not only to the whole project.
At Administy we link:
- contract value,
- the base hours budget,
- actual working time,
- the cost of each specialist,
- additional work,
- external costs,
- current margin,
- forecast final margin.
Thanks to this we see not only that a project has used more hours. We can also check why this happened.
For example, a project may show 120 hours over plan, of which:
- 25 hours came from a wrong estimate,
- 15 hours were spent on fixing bugs,
- 80 hours related to the client’s additional requirements.
Such information changes the way you manage.
In the first case the quoting process needs improving. In the second, the quality of delivery. In the third, the procedure for change management and billing additional work.
Recording changes systematically also lets you notice earlier that:
- the number of additional requests is growing,
- the client has already used up the whole buffer,
- additional hours are lowering the forecast margin,
- some of the work has not been priced,
- the team is carrying out tasks before acceptance is obtained,
- the project needs the scope or deadline renegotiated.
The most important change is that scope creep stops being an invisible cost.
Instead of telling the client:
“We have far more work than we assumed”
we can show:
“Since the start of the project we have accepted 12 additional changes, which increased the scope by 86 hours and lowered the forecast margin by a specific amount”.
This gives a basis for a fact-based conversation about an additional quote, a deadline shift or limiting further changes.
Flexibility should not mean free work
Good collaboration requires flexibility, but every change has a cost.
Scope creep in an IT project can be limited if the company defines the scope clearly, tells bugs from new requirements, records additional work and shows its total impact on the budget.
The lack of such a process leads to a situation in which the client receives an ever wider scope while the contractor gradually loses margin.
Check how much clients’ additional requests cost
Administy helps bring working time, the team’s individual costs, additional items and the project’s forecast margin together in one place.
Book an Administy demo and see how to record additional work and react before small corrections use up the whole project budget.
