Part III Development: keeping the project on track
Chapter 18: Changes and scope creep
Scope grows on every project. The problem arises when it grows through small verbal agreements, without the costs being quantified. Every change therefore needs a written request, a quantification of its impact on price and schedule, and a decision by a person with a mandate, ideally following the rule “something in, something out.”
This chapter is not legal advice. It describes the state of legislation as of October 2026; Section 222 of the Public Procurement Act (ZZVZ) does not change even with the amendment effective from January 1, 2027. Have a lawyer check the contract, the change control process, and every amendment in a public contract.
Scope grows, even when nobody wants it to
Scope creep usually has ordinary causes:
- an unfinished analysis and unclear scope boundaries,
- several people with different requirements on the customer’s side and no product owner,
- a change in legislation during the project,
- shifting management priorities. DORA research has shown that unstable priorities reduce team productivity and increase the risk of burnout DORA, 2024.
Changes in themselves are not a mistake. Something new always comes up during development. The mistake is uncontrolled changes: agreed in the hallway, not priced, and not written down anywhere. Each one on its own is a trifle; together they add up to a stage that nobody ordered. You can prevent most of the causes with an analysis that includes a list of what is out of scope (chapter 14) and with a single product owner (chapter 16).
Change control: five steps instead of “just add that in too”
Change control sounds bureaucratic, but it is just a procedure agreed in advance. It applies to companies and public authorities alike, and it fits on one page of the contract.
- Submission
Anyone can submit a change request: a user, the product owner, or the vendor. In writing, with a description, a reason, and the author’s name.
- Pricing
Within 5 business days (rule of thumb), the vendor estimates the price, the impact on the schedule, the risks, and the effect on other features. At the same time, it proposes what to remove from the backlog or postpone.
- Decision
The product owner decides within the limits of their mandate, for example up to 5% of the stage budget (a suggestion; set the limit yourself). Above the limit, the steering committee decides.
- Record
An approved change is recorded in a change order signed by both parties and reflected in the backlog and the plan. A public authority also classifies it legally under Section 222 of ZZVZ and publishes it.
- Review
Once a month, the steering committee receives a summary of all changes and of the contingency used. That way, even ten small changes that would not alarm anyone individually become visible.
Follow two more rules. First, a defect fix is not a change: the vendor fixes a defect free of charge under warranty, but charges for a change, and the contract must clearly separate the two (chapter 11). Second, additional work without a signed change order is not paid for. Agree on this in the contract; then approval by email or “verbally at the demo” is not enough.
The process pays off with every pricing model (chapter 10). With a fixed price, it protects the budget from additional work. With payment for time worked, a change is not invoiced separately, but it draws on the agreed budget cap and pushes back the deadline, so the same person should decide on it with the same information. Be alert when:
- there are many change orders and each one is small,
- additional work is approved by email or phone,
- nobody can say how much of the contingency is left.
Something in, something out
With a fixed budget, the main tool is trading requirements. For every change request, ask what will drop out of the backlog so that the new item fits. It works like a suitcase for a flight: if you pack extra shoes, something else stays at home.
How do you say no? The product owner needs a mandate and a criterion for making decisions: the project goal and the scope of the MVP. They do not reject what does not belong in the MVP forever, but postpone it to the backlog for the next stage. Be alert when the vendor itself pushes to expand the scope before the MVP is finished. More work for the vendor does not necessarily mean more value for you.
A contingency is necessary; short stages are stronger
A contingency is not an admission of incompetence, but insurance. As a rough guide, plan for these values:
- a well-prepared project: 10–15% of the budget and 15–20% of the time,
- a new system with unclear integrations with other systems: 20–30% of the budget.
The customer holds the contingency, not the vendor, and decides on every use of it the same way as on a change. For a multi-year project, even a large contingency may not be enough. Large IT projects exceed their budget by 45% on average, and each additional year of duration increases the cost overrun by 15% McKinsey and Oxford, 2012. Short stages, after which you can adjust the plan or end the project, are therefore stronger insurance. A public authority must also think about the contractual possibility of using the contingency: it must reserve it as an option or a change in the tender documentation.
e-Sbírka and e-Legislativa (MV, NKÚ 2025)
The system for the electronic Collection of Laws (e-Sbírka) was supposed to be built in 3 years. In the end, implementation dragged on for 9 years, the budget rose from CZK 482.1 million to CZK 903.2 million, and the project went through 22 change requests NKÚ, audit conclusion KZ 24/04.
The Supreme Audit Office (NKÚ) classified CZK 581 million as spent without authorization. This is not the price of the amendments, but everything the ministry paid under a contract that it changed through amendments concluded in breach of the Public Procurement Act NKÚ, audit conclusion KZ 24/04. The Ministry of the Interior (MV) disagrees with the conclusions and states that the amendments themselves amounted to CZK 173 million ČTK, April 28, 2025.
The lesson: an amendment without a basis in Section 222 of ZZVZ is the most expensive way to make a change. An audit then calls into question the payments for the whole contract, not just for the change.
Source: NKÚ, audit conclusion KZ 24/04, ČTK, April 28, 2025 (MV statement)
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrongA change agreed verbally at the demo. | How to do it rightA written change request, pricing within 5 business days, a signed decision. |
| How it goes wrongAdditional work priced only after delivery. | How to do it rightThe price and the impact on the schedule known before the decision. |
| How it goes wrongLots of small “trifles” that nobody records. | How to do it rightEvery change in a change order and in the backlog; a monthly summary of the contingency used. |
| How it goes wrongThings only get added to a fixed budget. | How to do it right“Something in, something out.” |
| How it goes wrongA 10% contingency for a three-year project. | How to do it rightShort stages and a contingency based on how new the system is (10–30%). |
| How it goes wrongA defect fix is invoiced as “further development.” | How to do it rightA defect is fixed free of charge under warranty, a change is paid for, and the contract distinguishes between them. |
Contract modification under § 222 ZZVZ
- Every change to a contract after signing is a contract modification. You must not make a substantial modification, meaning one that would have allowed other vendors to participate or affected the selection, would shift the economic balance in favor of the vendor, or would significantly expand the scope, without a new procurement procedure, unless a statutory exception applies to it § 222 ZZVZ.
- The main tool for agile contracts is changes reserved in the tender documentation (subsection 2 and Section 100(1)): options for further stages, rules for backlog changes, and shifting milestones when legislation changes. What you do not reserve, you will have a hard time defending later (chapter 12).
- A minor modification (subsection 4) must be below the EU threshold and at the same time below 10% of the original value for services and supplies; what counts is the sum of all such modifications. For additional deliveries and unforeseeable circumstances (subsections 5 and 6), the net price increase, meaning after deducting the work that will not be carried out because of the change, must not exceed 30% of the original value in total (subsection 9). A change of vendor is a substantial modification; the only exceptions are a reserved change of vendor (Section 100(2)) and legal succession (subsection 10).
- Even a shift in a deadline is a contract modification. The Office for the Protection of Competition (ÚOHS) imposed a final fine of CZK 122,000 on the Ministry of Regional Development (MMR) for two amendments that pushed back the deadline of the e-Turista system by 2 and then by 5 months, because the ministry did not prove unforeseeability ÚOHS, August 20, 2026. A realistic schedule is the contracting authority’s risk.
- For every amendment, justify in writing which subsection of Section 222 it is based on, and publish it. A contract in the Register of Contracts takes effect no earlier than its publication Act No. 340/2015 Coll..