Part IV After launch: operations, further development, independence
Chapter 22: Maintenance and further development
Software ages even if you do not change anything in it. As a rough guide, plan for 10–20% of the purchase price per year for operations and maintenance. Plan further development separately, based on the roadmap. Make sure that comparable modifications do not gradually get more expensive.
Maintenance is not just fixing bugs
Software is like a car in a garage: even if you do not drive it, the tires age and the inspection certificate expires. The system does not change, but the world around it does. New versions of browsers and operating systems come out, vulnerabilities are discovered in libraries, and legislation changes. For each component, also keep an eye on its end of life, after which it no longer receives security patches.
Maintenance therefore includes:
- bug fixes and security patches,
- updates of libraries, platforms, and databases,
- adapting to new versions of browsers and operating systems and to legislation,
- paying down technical debt (chapter 23).
Update in small steps, every month or quarter. If you put off updates for years, small modifications turn into a separate and expensive project. Ask for a list of components and their versions (SBOM) with end-of-life dates, and agree in the contract on an obligation to keep the system on supported versions.
A warranty does not replace maintenance. It covers defects in the work, not the move to a new version of the platform. And most of the money after launch does not go into fixes: maintenance accounts for 40–80% of the cost of software over its whole lifecycle, and roughly 60% of it is enhancements Glass, 2002. A budget “just for fixes” is therefore not enough. The statistics count enhancements as maintenance; in the budget below, we separate them out as further development.
How much per year, and how to split it
The baseline estimate from chapter 4 applies: 10–20% of the purchase price per year for operations and maintenance, without new features. It is an indicative estimate derived from several audits by the Supreme Audit Office (NKÚ), not from a representative sample. Operating the basic registers comes to about 12% of the purchase price per year NKÚ, audit conclusion KZ 23/05, and support for the new travel document system of the Ministry of Foreign Affairs (MZV) to about 8% NKÚ, audit conclusion KZ 24/26. Further development cannot be estimated as a percentage; calculate it from the roadmap: the number of person-days times the rate.
Keep the money in three separate envelopes: operations and support, maintenance including technical debt, and further development. When everything is in one pot, maintenance always loses out to new features. But a percentage for technical debt alone is not enough; the reserved capacity must go to the parts of the debt that hold the system back the most McKinsey, 2023.
Once a year, also review licenses and servers. The State Agricultural Interventional Fund (SZIF) paid almost CZK 417 million for SAP licenses in 2016–2019 and did not track how they were used NKÚ, audit conclusion KZ 20/07. Paying for unused licenses is like paying rent for a warehouse that nobody goes into.
Fixed monthly fee or orders?
| Fixed monthly fee | Fixed-price orders | Combination | |
|---|---|---|---|
| How it works | X person-days per month, priorities change along the way | each change is priced and ordered separately | a fixed monthly fee for support and small modifications, larger changes by order |
| When it fits | small, frequent changes | clearly defined changes | most systems after launch |
| Risk | without a timesheet, you do not know what you got | risk markups, disputes over “what counts as a change” | an unclear line between the fixed monthly fee and an order |
| What to watch | a monthly timesheet | effort breakdown, rates by role | a list of what the fixed monthly fee covers |
A summary of common practice. For most systems, a combination works.
To keep the cost of comparable modifications from gradually rising:
- fix or index the rates by role,
- ask for an effort breakdown by activity and role with every proposal,
- track how much comparable changes cost over time,
- insist on automated tests, which make every further change cheaper,
- compare the total price of a change with the market, not just the rate per person-day.
By comparing unit prices at SZIF, NKÚ found that the fund was paying its main vendor many times more than comparable services from other vendors in the ministry’s sector cost NKÚ, audit conclusion KZ 20/07. Rising effort without an explanation is a measurable symptom of technical debt or vendor dependency (chapter 24).
A system needs an owner and a roadmap
After launch, the project team leaves, and the system often ends up without a clear owner. Appoint a product owner on your side who decides on priorities and is responsible for the system. The owner maintains a roadmap for 12–24 months with priorities based on benefit, not on who pushes their requirements the loudest. Once a year, go through the roadmap, the end-of-life dates of components, licenses, and infrastructure utilization with the vendor.
Think about the end of the old system, too. The MZV case in chapter 4 shows how expensive parallel running is when nobody switches off the old system.
The system is quietly aging
- It runs on versions past their end of life, and “it works for now.”
- The vendor cannot tell you which libraries and versions it uses.
- Every update breaks something else.
- Proposals for changes come without an effort breakdown.
- The support proposal is well below 10% of the purchase price, and it is not clear what is missing from it.
| How it goes wrong | How to do it right |
|---|---|
| How it goes wrong“The system is finished”; there is no budget for maintenance. | How to do it rightAn annual budget for operations and maintenance, with a baseline estimate of 10–20% of the purchase price. |
| How it goes wrongUpdates are put off until the jump between versions becomes a separate project. | How to do it rightSmall updates monthly or quarterly, an SBOM with end-of-life dates. |
| How it goes wrongThe warranty is confused with maintenance. | How to do it rightThe contract states what the warranty covers, what the fixed monthly fee covers, and what is ordered. |
| How it goes wrongA single “support and development” package. | How to do it rightThree envelopes: operations and support, maintenance and debt, further development. |
| How it goes wrongProposals for changes without a breakdown, compared only by the rate per person-day. | How to do it rightA mandatory effort breakdown and tracking of the price of comparable changes. |
| How it goes wrongA wish list with no order. | How to do it rightA roadmap for 12–24 months with priorities based on benefit, which you are responsible for. |
- Put support and maintenance out to tender in advance, together with development, and for a sufficiently long period. Awarding them later in a negotiated procedure without prior publication (JŘBU), citing the vendor’s exclusive rights, is a major risk (chapters 12 and 24).
- Further development needs a framework agreement or a contract with a volume tendered in advance. Amendments that were not tendered and negotiated procedures for new modules are high risk (chapter 18).
- The public-authority equivalent of a roadmap is the authority’s information strategy (informační koncepce) Decree No. 360/2023 Coll.. Include the plan for renewing and further developing the system in it.
- Operating costs over the whole lifecycle belong in the budget and in the request for an opinion from the Office of the Chief Architect of eGovernment (OHA); see chapter 5.
- If you fall under the Cybersecurity Act, a system that is not kept up to date can also mean failing to meet statutory requirements.