Why federal IT mega-projects keep failing repeatedly

Those receiving social assistance in Zurich get a monthly budget: a certain amount for rent, a certain amount for living expenses. With the new software of the Social Services, this budget could not be generated in a traceable way until February 2026, as the city ombudsman notes in areport. Money that had been wrongly received could not be reclaimed by the city in 2025and could not be recovered. The system had no recovery mechanism.

The requirements for this software were gathered by experts from Bern, Basel and Zurich in workshops in 2013collected. In January 2018 the joint association of the three cities awarded the contract. Bern switched in 2023, Zurich in January 2025, Basel is expected early 2027. More than eleven years passed between the first workshop and the first Zurich case. The ombudsman draws a brief conclusion in itsannual report: The implementation must unfortunately also be described as a failure in Zurich.

On October 20, 2026 the federal government announced a cloud contract for up to 7 billion francstendered. The contracts run for a total of 14 years.

A social assistance software and a cloud have little in common. Their problem is nevertheless the same. The state fails at software not despite its diligence, but because of it. It plans it like a tunnel, contracts it in one piece and finances it as a project with an end. Software, however, has no end.

No glitches, but a pattern

Citysoftnet, the Zurich software, is not an isolated case. The list of large IT projects that have gone off the rails is long enough for a table:

The projects come from different departments and decades, yet they are similar. At the start there is a comprehensive system intended to replace many old systems at once. Requirements are created years before the first user sees the system. The switch happens on a set date when the old system is taken offline. And the key roles are filled by external experts who leave after the project. In INSIEME they were, according to the parliamentary investigation report, "mostly staffed with external experts".

This is not bad luck. The Federal Finance Control Office evaluated itsaudits of large IT projectsfrom two years, 24 reports covering a volume of 3 to 5 billion francs. Its finding: the major deficiencies identified already in 2016 still exist. One chapter of the report is titled "The organization does not learn systematically".

The Federal Chancellery counters in its statement. Of the roughly 200 projects completed each year, the vast majority are successful. I believe that, and it actually supports the argument rather than contradicts it. Small projects succeed. It is the large ones that fail.

A tunnel gets finished, software never does

Switzerland can build a57‑kilometre long railway tunnelthrough the Gotthard. The procedure for that is proven: plan, calculate costs, tender, build, accept. In the software industry this approach is called waterfall because each phase flows into the next and none flow back. That works for a tunnel. It should connect two portals, and nothing changes in the 17‑year construction time.

With software it is the opposite. At the start you know the least. What a social worker really needs often becomes clear only when working with the system. And technology changes faster than a tender process lasts. Whoever ordered a cloud for 14 years in 2012 could not have known tools like Kubernetes or large AI models. Today they are everyday.

The size itself is the risk, as the numbers also show. Astudy by McKinsey and the University of Oxfordof more than 5,400 IT projects concluded that large projects over $15 million on average exceed their budget by 45 percent and deliver 56 percent less benefit than promised. Big orders therefore deliver on average less than half the benefit for almost one‑and‑a‑half times the money. Each additional project year increased the overrun by 15 percent. Bent Flyvbjerg and Alexander Budzierfound in 1,471 IT projectsthat one in six cost on average three times the planned amount.

In the last 25 years I have helped build several companies whose core product is software, including an online retailer and a digital asset manager. None of them was created from a specification document. We started small, tested every step immediately with real customers and only expanded what worked. There were no project budgets. There were teams permanently responsible for a topic area, each with one person deciding what to build next, in the industry term the Product Owner. We were fast, but every step was so small that a mistake cost little. That is the real difference. Not speed versus diligence, but many small risks instead of one big one.

The system rewards the big package

First of all: I do not claim that the wrong people sit in the offices. That accusation would be convenient and wrong. Whoever reads the rules by which the state orders software sees something different. The big project there is the sensible choice.

It starts with the money. A federal IT project needs a commitment credit. The Financial Budget Act describes it as a "maximum amount" up to which the Federal Council can incur obligations "for a specific purpose". It is measured "on the basis of careful calculations prepared according to professional rules". Whoever wants money must therefore define at the beginning what they are building and how much it costs. Exactly when they know the least. When learning on the way, a supplemental credit is needed, and that is publicly acknowledged as an admission of error. It is no different in the cities: Bern has had to apply for several follow‑up credits for Citysoftnet since 2023 multiple follow‑up credits .

Then it is tendered as a contract to a supplier. In the case of Citysoftnet, the procurement law at the time prohibited any dialogue with the vendors. Offers and prices therefore "partially relied on false assumptions", wrote the Bern City Council later. Once the award is granted, any change becomes expensive. The Procurement Act even allows follow‑up contracts to be awarded to the existing supplier without a new tender if a change would cause "substantial additional costs". The Federal Council explained in 2025 why it extended the existing cloud contracts without competition: a vendor change for the transition period "would involve significant outage and security risks as well as disproportionate additional costs". That is what lock‑in looks like, a dependency from which one cannot easily get out.

And every project has an end. The federal project method, HERMES, has known agile projects since 2022. But even these are concluded. The financial audit sums up the contradiction in one sentence that could hang in any office: "Projects develop increasingly product‑oriented and iteratively, while governance remains project‑based." Software is therefore built like a product and managed like a tunnel.

Therefore it helps little if teams work agile, i.e., in short cycles with continuous feedback. In Citysoftnet the supplier worked according to a report for the Bern city parliament agile, while the projects themselves followed HERMES. In the army telecommunications project, worth about 1.9 billion francs, a sub‑project was only in 2025, after the award, decided to proceed agile. That now has to be reflected retroactively "in the contract structures", and according to the financial audit "further delays" have arisen. I call this a waterfall with sprints: agile teams within a framework that defines everything at the start.

The question remains, who holds the knowledge. The financial audit states that there is already a "high proportion of external specialists in IT projects" today. External procurement is "relatively expensive" and increases "the risk of knowledge loss". Those who do not build themselves can only order. And those who order must write everything down in advance.

The cloud follows the same blueprint

A cloud is not a case‑management system. It is infrastructure: data centres, storage, network. You buy something like that; you do not invent it yourself. And the new tender is better built than INSIEME. The federal government awards three lots to five different providers, pays only for what it uses, and reopens the market after seven years. The 7 billion francs are a ceiling, not an expense, spread over 14 years up to 500 million francs per year. How far the ceiling and consumption can diverge is shown by the existing cloud contracts: of a cost cap of 110 million francs the government had drawn down about 61 million francs by September 2025 around 61 million drawn.

Nevertheless the cloud is being built according to the old blueprint. The federal cloud strategy dates from December 2020. The first services are to be procured in late autumn 2027, provided no complaints arise in the meantime. From strategy to first drawdown, seven years pass. The framework contracts run until 2034, individual contracts until 2041.

Whether this pays off, no one knows today. The Federal Council's message noted in 2024 that there is "only a cost framework, not a cost‑benefit analysis". The financial audit wrote in 2025 that the economic benefit has "not yet been demonstrated". Use is not mandatory, and the offices have "so far not committed themselves". The risk of further delays and procurement complaints is assessed as high in the same report. Here too, only when the tunnel is opened will it become clear whether it was worthwhile.

What occupies me most is something else. Parliament decided that, for the cloud, "where possible" open source and companies based in Switzerland should be preferred. The tender however does not allow consortia, i.e., joint ventures of several firms, and each provider can only bid for one lot. A Swiss provider that is too small on its own may not team up with others. As a subcontractor to a large supplier it may participate, but not as an equal partner. If one wants to promote Swiss providers, they must be allowed to form alliances. The tender does the opposite.

I write this as an entrepreneur who has personally benefited from a strong Swiss technology location. One should know that when evaluating the argument. In the plural I have presented the problem as a problem statement in an initiative idea for a federal technology department, to which I will return at the end:

I am not saying the cloud will fail. I am saying it will be built according to the same blueprint as the projects that have failed: large, long, and the benefit only becomes apparent at the end.

Small, independent, lasting

The best counterexample comes from the same tax administration that had to shut down INSIEME. The follow‑up project FISCAL‑IT also ran into trouble in 2016, a major release had to be cancelled because of critical bugs. Afterwards the administration switched to agile teams together with the Federal Office of Informatics, delivering a software demo at the end of every two‑week development cycle. In 2020 the "Financial Control", noted that agile development and the joint teams had "proved themselves". Since then the tax administration wants to "avoid comprehensive solutions" for its systems as much as possible.

The same Federal Office was commissioned in May 2021 for the Covid Certificate. Three weeks later the first people in Switzerland were holding a certificate in their hands. The source code is open, Austria built its app on it. So it works, even within the same administration.

Other countries have turned their debacles into rules. The United Kingdom decided in 2014 not to award any IT contract worth more than £100 million, except for exceptional reasons. Automatic renewals have not existed since, and hosting contracts now last at most two years. In France small state teams develop their own digital services. The Court of Auditors counted over 450 products that were either trialed or developed this way. In a sample one of them cost on average €290,000 per year for development and design. That is a fraction of what a large project costs per year.

From this a four‑part proposal emerges. First, the state funds products instead of projects: permanent teams for a thematic area, such as social assistance or taxes, with an annual budget. Parliament measures them by what citizens and the administration actually use, not by a deliverable scope. Second, a ceiling for size and duration of IT contracts is introduced, following the British model. Third, the state builds the core with its own developers and brings in external specialists for peaks. According to Financial Control the federal government can pay market salaries, only not always for highly specialised functions. Fourth, the code is open, as the Law has required since 2024 for software the federal government develops or commissions.

The fourth point is more than a technical issue. When the state spends billions on IT, it decides which companies will exist in ten years. If it buys large packages from the biggest global providers, it finances their growth. If it buys in small lots, allows consolidations and keeps its code open, Swiss companies that can do this work will emerge and later sell it to other customers. That creates jobs and tax revenue. Large technology firms often arise with long‑term state support. The chip maker TSMC was founded in 1987 as a joint venture of the Taiwanese government, the electronics group Philips and private investors. Today it claims to be the world’s leading contract manufacturer of computer chips. If you do not invest in the foundation, you should not be surprised when it is missing.

I have also submitted a solution proposal that goes in this direction:

Is agile just a label?

One could stop here. It is not that simple, and the strongest objections come from the Financial Control itself. It cannot deduce from its audits that agile projects keep budgets and timelines better than classic ones. And it warns that agile methods are often regarded "as per se promising".

There are examples of that. The new case‑management system of the Canton of Bern was deliberately meant to start as a small first version, developed together with the first municipalities and expanded in operation. It is still in crisis. The CHF 52 million credit is, according to the responsible department head, "probably not enough", and he says: "In hindsight the rollout was too early." The customs programme DaziT works agile, the Financial Control praised its governance in 2022, yet the import transition was delayed by about a year.

There is also a fundamental objection that I take seriously. It roughly states: Agile means you do not know the cost, nor when it will be finished. A parliament has the right to know both before it approves. Fixed rules also protect against abuse. In INSIEME the requirements were introduced gradually from 2009 onward by the federal council, instead of being fully defined at the start. In the same years the tax administration awarded dozens of contracts each year just below the threshold without tendering. And anyone demanding industrial policy must be asked whether the state can select winners. For every TSMC there are state‑supported firms that no one talks about anymore. Preferencing national providers is already prohibited by Swiss and international procurement law, as the Federal Council notes.

On one point the opposition is right: the label helps nothing. A system for 85 organisations with a CHF 52 million credit remains a large project, even if it starts with a small first version. What matters is not the method on paper, but how large each step is, how early real users see it, and whether the knowledge stays in‑house.

This objection contains a genuine dilemma and one that only appears to be one. The real conflict is between cost transparency up front and learning on the way. No one can maximise both. The apparent contrast is between control and small steps. A parliament that sees each year what a team delivered knows more than one that approves a seven‑year credit and only receives a final account. If you want cost control, you should demand small tranches, not bindings of 14 years.

INSIEME also does not oppose small steps. The free‑hand awards were a large project that was broken into small contracts to circumvent tendering. And the state does not have to pick winners. It must be a good customer: buy in small lots, allow consolidations, demand open code. That favours no one by origin, but providers that deliver good work in small steps. That many Swiss firms would be among them is a consequence, not a condition.

The financial control also writes that the argument that laws prevented the collaboration that agile methods need often turns out to be an excuse. I read that as good news. If the law already allows dialogue with providers, quality competition and framework contracts, the problem lies in practice and incentives. Both can be changed faster than a law.

Whether the federal government finds the people, I don't know. In 2023 its IT departments could not fill a quarter of the advertised positions. The financial control estimates the build‑up of competencies and structures for agile work at three to four years. That is not a reason to wait. It is the reason to start now and not only after the next 14‑year binding.

Good for tunnels, bad for software

For the Gotthard tunnel the procedure was correct. One knew where the tunnel started and where it ended. With software you never know, and therefore the financial control arrives at the same finding after ten years. The federal government does not have to learn to run large IT projects. It has to stop making them.

At Plural the association CH++ has put forward an initiative that starts with the federal government: a dedicated department that bundles IT, data, cybersecurity and AI. I have added some aspects myself, including the two embedded above.

My position on this: a new department alone is a reorganisation, and reorganisations carry the same risk as large projects. It only pays off if it changes how the state builds and pays for software, and not just bundles responsibilities. Whether a department is the right lever or whether it is enough to restructure budgeting and procurement can be debated with good reasons.

You now know both sides. What is your view?

Oliver Herren is co‑founder of Plural, Digitec Galaxus and True Wealth. He writes his personal opinion here, not Plural's.