Warum IT-Grossprojekte des Bundes immer wieder scheitern

Wer in Zürich Sozialhilfe bezieht, erhält jeden Monat ein Budget: so viel für die Miete, so viel für den Lebensunterhalt. Mit der neuen Software der Sozialen Dienste liess sich dieses Budget bis im Februar 2026 nicht nachvollziehbar erstellen, wie der Ombudsmann der Stadt in einem Bericht festhält. Geld, das jemand zu Unrecht bezogen hatte, konnte die Stadt 2025 nicht zurückfordern. Das System kannte keine Rückforderung.

Die Anforderungen an diese Software haben Fachleute aus Bern, Basel und Zürich 2013 in Workshops erhoben. Im Januar 2018 vergab der gemeinsame Verein der drei Städte den Auftrag. Bern stellte 2023 um, Zürich im Januar 2025, Basel voraussichtlich Anfang 2027. Zwischen dem ersten Workshop und dem ersten Zürcher Fall lagen mehr als elf Jahre. Die Ombudsstelle zieht in ihrem Jahresbericht ein knappes Fazit: Die Einführung müsse «leider auch in Zürich als misslungen bezeichnet werden».

Am 20. Oktober 2026 hat der Bund eine Cloud für bis zu 7 Mrd. Franken ausgeschrieben. Die Verträge laufen insgesamt 14 Jahre.

Eine Sozialhilfe-Software und eine Cloud haben wenig gemeinsam. Ihr Problem ist trotzdem dasselbe. Der Staat scheitert an Software nicht trotz seiner Sorgfalt, sondern wegen ihr. Er plant sie wie einen Tunnel, vergibt sie in einem Stück und finanziert sie als Projekt mit einem Ende. Software hat aber kein Ende.

Keine Pannen, sondern ein Muster

Citysoftnet, so heisst die Zürcher Software, ist kein Einzelfall. Die Liste der grossen IT-Vorhaben, die aus dem Ruder gelaufen sind, ist lang genug für eine Tabelle:

Die Vorhaben stammen aus verschiedenen Ämtern und Jahrzehnten, und doch gleichen sie sich. Am Anfang steht ein Gesamtsystem, das viele alte Systeme auf einmal ablösen soll. Die Anforderungen entstehen Jahre, bevor der erste Nutzer das System sieht. Umgestellt wird an einem Stichtag, an dem das alte System vom Netz geht. Und die Schlüsselrollen besetzen Externe, die nach dem Projekt wieder gehen. Bei INSIEME waren sie laut dem Untersuchungsbericht des Parlaments «mehrheitlich mit externen Experten besetzt».

Das ist kein Pech. Die Eidgenössische Finanzkontrolle hat 2026 ihre Prüfungen der grossen IT-Vorhaben aus zwei Jahren ausgewertet, 24 Berichte über ein Volumen von 3 bis 5 Mrd. Franken. Ihr Befund: Die wesentlichen Defizite, die sie schon 2016 benannt hatte, bestehen weiter. Ein Kapitel des Berichts trägt den Titel «Die Organisation lernt nicht systematisch dazu».

Die Bundeskanzlei hält in ihrer Stellungnahme dagegen. Von den rund 200 Projekten, die jedes Jahr abgeschlossen werden, sei die grosse Mehrheit erfolgreich. Ich glaube das, und es stützt das Argument eher, als dass es ihm widerspricht. Die kleinen Projekte gelingen. Es sind die grossen, die scheitern.

Ein Tunnel wird fertig, Software nie

Die Schweiz kann einen 57 Kilometer langen Eisenbahntunnel durch den Gotthard bauen. Das Verfahren dafür ist bewährt: planen, Kosten berechnen, ausschreiben, bauen, abnehmen. In der Softwarebranche heisst dieses Vorgehen Wasserfall, weil jede Phase in die nächste fliesst und keine zurück. Für einen Tunnel passt es. Er soll zwei Portale verbinden, und daran ändert sich in 17 Jahren Bauzeit nichts.

Bei Software ist es umgekehrt. Am Anfang weiss man am wenigsten. Was ein Sozialarbeiter wirklich braucht, merkt er oft erst, wenn er mit dem System arbeitet. Und die Technik ändert sich schneller, als eine Ausschreibung dauert. Wer 2012 eine Cloud für 14 Jahre bestellt hätte, hätte Werkzeuge wie Kubernetes oder die grossen KI-Modelle nicht kennen können. Heute sind sie Alltag.

Dass die Grösse selbst das Risiko ist, zeigen auch die Zahlen. Eine Studie von McKinsey und der Universität Oxford über mehr als 5'400 IT-Projekte kam zum Schluss, dass grosse Projekte ab 15 Mio. Dollar ihr Budget im Schnitt um 45 Prozent überschreiten und 56 Prozent weniger Nutzen bringen als versprochen. Wer gross bestellt, erhält also im Schnitt weniger als die Hälfte des Nutzens für fast anderthalbmal so viel Geld. Jedes zusätzliche Projektjahr erhöhte die Überschreitung um 15 Prozent. Bent Flyvbjerg und Alexander Budzier fanden unter 1'471 IT-Projekten jedes sechste, das im Schnitt dreimal so viel kostete wie geplant.

Ich habe in den letzten 25 Jahren mehrere Firmen mitaufgebaut, deren Kern Software ist, darunter einen Onlinehändler und einen digitalen Vermögensverwalter. Keine davon ist nach einem Pflichtenheft entstanden. Wir haben klein angefangen, jeden Schritt sofort an echten Kunden geprüft und nur ausgebaut, was funktionierte. Projektbudgets gab es nicht. Es gab Teams, die dauerhaft für einen Themenbereich zuständig waren, jedes mit einer Person, die entscheidet, was als Nächstes gebaut wird, in der Fachsprache dem Product Owner. Wir waren schnell, aber jeder Schritt war so klein, dass ein Fehler wenig kostete. Das ist der eigentliche Unterschied. Nicht Tempo gegen Sorgfalt, sondern viele kleine Risiken statt eines grossen.

Das System belohnt das grosse Paket

Eins vorneweg: Ich behaupte nicht, dass in den Ämtern die falschen Leute sitzen. Der Vorwurf wäre bequem und falsch. Wer die Regeln liest, nach denen der Staat Software bestellt, sieht etwas anderes. Das grosse Projekt ist dort die vernünftige Wahl.

Es beginnt beim Geld. Ein IT-Vorhaben des Bundes braucht einen Verpflichtungskredit. Das Finanzhaushaltgesetz beschreibt ihn als «Höchstbetrag», bis zu dem der Bundesrat «für einen bestimmten Zweck» Verpflichtungen eingehen kann. Bemessen wird er «auf Grund sorgfältiger, nach fachmännischen Regeln erstellter Berechnungen». Wer Geld will, muss also zu Beginn festlegen, was er baut und was es kostet. Genau dann, wenn er am wenigsten weiss. Wer unterwegs etwas lernt, braucht einen Zusatzkredit, und der gilt öffentlich als Eingeständnis eines Fehlers. In den Städten ist es nicht anders: Bern hat für Citysoftnet seit 2023 mehrere Nachkredite beantragen müssen.

Dann wird ausgeschrieben, als ein Auftrag an einen Lieferanten. Bei Citysoftnet untersagte das damalige Beschaffungsrecht jeden Dialog mit den Anbietern. Angebote und Preise hätten deshalb «teilweise auf falschen Annahmen» beruht, schrieb der Berner Gemeinderat später. Ist der Zuschlag erteilt, wird jeder Wechsel teuer. Das Beschaffungsgesetz erlaubt dann sogar, Folgeaufträge ohne Ausschreibung an den bisherigen Lieferanten zu vergeben, wenn ein Wechsel «substanzielle Mehrkosten» brächte. Der Bundesrat begründete 2025, warum er die bestehenden Cloud-Verträge freihändig verlängert hat: Ein Anbieterwechsel für die Übergangszeit «wäre mit erheblichen Ausfall- und Sicherheitsrisiken sowie unverhältnismässigen Mehrkosten verbunden». So sieht ein Lock-in aus, eine Abhängigkeit, aus der man nicht mehr ohne Weiteres herauskommt.

Und jedes Vorhaben hat ein Ende. Die Projektmethode des Bundes, HERMES, kennt seit 2022 auch agile Projekte. Aber auch diese werden abgeschlossen. Die Finanzkontrolle fasst den Widerspruch in einen Satz, der in jedem Amt hängen könnte: «Vorhaben entwickeln sich zunehmend produktorientiert und iterativ weiter, während die Governance projektbasiert bleibt.» Software wird also wie ein Produkt gebaut und wie ein Tunnel verwaltet.

Darum hilft es wenig, wenn die Teams agil arbeiten, also in kurzen Zyklen mit laufender Rückmeldung. Bei Citysoftnet arbeitete der Lieferant laut einem Gutachten für das Berner Stadtparlament agil, die Projekte selbst liefen nach HERMES. Bei der Telekommunikation der Armee, einem Vorhaben von rund 1.9 Mrd. Franken, wurde für ein Teilprojekt erst 2025, nach dem Zuschlag, entschieden, agil vorzugehen. Das muss nun nachträglich «in den Vertragsstrukturen» abgebildet werden, und dabei sind laut Finanzkontrolle «weitere Verzögerungen» entstanden. Ich nenne das einen Wasserfall mit Sprints: agile Teams in einem Rahmen, der am Anfang alles festlegt.

Bleibt die Frage, wer das Wissen hat. Die Finanzkontrolle spricht vom «bereits heute hohe[n] Anteil externer Fachkräfte in IT-Projekten». Die externe Beschaffung sei «relativ teuer» und erhöhe «das Risiko von Wissensverlusten». Wer nicht selbst baut, kann nur bestellen. Und wer bestellt, muss alles im Voraus aufschreiben.

Die Cloud folgt demselben Bauplan

Eine Cloud ist kein Fallführungssystem. Sie ist Infrastruktur: Rechenzentren, Speicher, Netz. So etwas kauft man ein, man erfindet es nicht selbst. Und die neue Ausschreibung ist besser gebaut als INSIEME. Der Bund vergibt drei Lose an fünf verschiedene Anbieter, bezahlt nur, was er nutzt, und öffnet den Markt nach sieben Jahren neu. Die 7 Mrd. Franken sind eine Obergrenze und keine Ausgabe, verteilt auf 14 Jahre bis zu 500 Mio. Franken pro Jahr. Wie weit Obergrenze und Verbrauch auseinanderliegen können, zeigen die bisherigen Cloud-Verträge: Von einem Kostendach von 110 Mio. Franken hatte der Bund bis im September 2025 rund 61 Mio. abgerufen.

Trotzdem entsteht die Cloud nach dem alten Bauplan. Die Cloud-Strategie des Bundes stammt vom Dezember 2020. Die ersten Leistungen sollen im Spätherbst 2027 bezogen werden, sofern keine Beschwerden dazwischenkommen. Von der Strategie bis zum ersten Abruf vergehen damit sieben Jahre. Die Rahmenverträge laufen bis 2034, einzelne Verträge bis 2041.

Ob sich das lohnt, weiss heute niemand. Die Botschaft des Bundesrats hielt 2024 fest, es gebe «nur einen Kostenrahmen, nicht jedoch eine Kosten-Nutzen-Analyse». Die Finanzkontrolle schrieb 2025, der wirtschaftliche Nutzen sei «noch nicht aufgezeigt». Die Nutzung ist nicht obligatorisch, und die Ämter haben sich «bislang nicht fest verpflichtet». Das Risiko weiterer Verzögerungen und Beschwerden bei der Beschaffung gilt im selben Bericht als hoch. Auch hier zeigt sich erst bei der Eröffnung, ob sich der Tunnel lohnt.

Am meisten beschäftigt mich etwas anderes. Das Parlament hat beschlossen, bei der Cloud «wenn möglich» Open Source und Unternehmen mit Sitz in der Schweiz zu bevorzugen. Die Ausschreibung lässt aber keine Konsortien zu, also keine Zusammenschlüsse mehrerer Firmen, und jeder Anbieter kann nur für ein Los antreten. Ein Schweizer Anbieter, der allein zu klein ist, darf sich nicht mit anderen zusammentun. Als Unterlieferant eines Grossen darf er mitmachen, als Partner auf Augenhöhe nicht. Wer Schweizer Anbieter fördern will, müsste ihnen erlauben, sich zusammenzuschliessen. Die Ausschreibung tut das Gegenteil.

Ich schreibe das als Unternehmer, der selbst von einem starken Technologiestandort Schweiz profitiert. Das soll man wissen, wenn man das Argument prüft. Auf Plural habe ich das Problem als Problemstellung eingebracht, in einer Initiatividee für ein eidgenössisches Technologiedepartement, auf die ich am Schluss zurückkomme:

Ich sage nicht, dass die Cloud scheitern wird. Ich sage, dass sie nach demselben Bauplan entsteht wie die Projekte, die gescheitert sind: gross, lang, und der Nutzen zeigt sich erst am Schluss.

Klein, eigen, dauerhaft

Das beste Gegenbeispiel kommt aus derselben Steuerverwaltung, die INSIEME abbrechen musste. Auch das Nachfolgeprojekt FISCAL-IT geriet 2016 in Schwierigkeiten, ein grosser Release musste wegen kritischer Fehler abgesagt werden. Danach stellte die Verwaltung um: agile Teams zusammen mit dem Bundesamt für Informatik, am Ende jedes 14-tägigen Entwicklungszyklus eine Vorführung der Software. 2020 schrieb die Finanzkontrolle, die agile Entwicklung und die gemeinsamen Teams hätten sich «bewährt». Die Steuerverwaltung will Gesamtablösungen ihrer Systeme seither «möglichst vermeiden».

Dasselbe Bundesamt erhielt im Mai 2021 den Auftrag für das Covid-Zertifikat. Drei Wochen später hielten die ersten Menschen in der Schweiz ein Zertifikat in der Hand. Der Quellcode ist offen, Österreich hat seine App darauf aufgebaut. Es geht also, sogar in derselben Verwaltung.

Andere Länder haben aus ihren Debakeln Regeln gemacht. Grossbritannien beschloss 2014, keinen IT-Vertrag über 100 Mio. Pfund mehr abzuschliessen, ausser aus aussergewöhnlichem Grund. Automatische Verlängerungen gibt es seither nicht mehr, Hosting-Verträge laufen höchstens zwei Jahre. In Frankreich entwickeln kleine Teams des Staates eigene digitale Dienste. Der Rechnungshof zählte über 450 Produkte, die so erprobt oder entwickelt wurden. In einer Stichprobe kostete eines im Schnitt 290'000 Euro pro Jahr für Entwicklung und Design. Das ist ein Bruchteil dessen, was ein Grossprojekt pro Jahr kostet.

Daraus ergibt sich ein Vorschlag in vier Teilen. Erstens finanziert der Staat Produkte statt Projekte: dauerhafte Teams für einen Themenbereich, etwa die Sozialhilfe oder die Steuern, mit einem Jahresbudget. Das Parlament misst sie an dem, was Bürger und Verwaltung tatsächlich nutzen, nicht an einem Lieferumfang. Zweitens gilt eine Obergrenze für Grösse und Laufzeit von IT-Verträgen, nach britischem Vorbild. Drittens baut der Staat den Kern mit eigenen Entwicklern und holt Externe für Spitzen. Laut Finanzkontrolle kann der Bund branchenübliche Löhne zahlen, nur bei hochspezialisierten Funktionen nicht immer. Viertens ist der Code offen, wie es das Gesetz seit 2024 für Software, die der Bund entwickelt oder entwickeln lässt, ohnehin verlangt.

Der vierte Punkt ist mehr als Technik. Wenn der Staat Milliarden für Informatik ausgibt, entscheidet er mit, welche Firmen es in zehn Jahren gibt. Kauft er grosse Pakete bei den grössten Anbietern der Welt, finanziert er deren Wachstum. Kauft er in kleinen Losen, lässt Zusammenschlüsse zu und legt seinen Code offen, entstehen Firmen in der Schweiz, die diese Arbeit können und sie später auch anderen Kunden verkaufen. Daraus werden Arbeitsplätze und Steuereinnahmen. Grosse Technologiefirmen entstehen oft mit langfristiger Hilfe des Staates. Der Chiphersteller TSMC wurde 1987 als Gemeinschaftsunternehmen der taiwanischen Regierung, des Elektronikkonzerns Philips und privater Investoren gegründet. Heute ist er nach eigenen Angaben der führende Auftragsfertiger von Computerchips der Welt. Wer nicht ins Fundament investiert, muss sich nicht wundern, wenn es fehlt.

Zur selben Initiatividee habe ich auch einen Lösungsvorschlag eingebracht, der in diese Richtung geht:

Ist agil nicht bloss ein Etikett?

Man könnte hier aufhören. So einfach ist es aber nicht, und die stärksten Einwände kommen von der Finanzkontrolle selbst. Sie kann aus ihren Prüfungen nicht ableiten, dass agile Vorhaben Budget und Termine besser einhalten als klassische. Und sie warnt, agile Methoden würden in vielen Vorhaben «als per se erfolgsversprechend betrachtet».

Die Beispiele dafür gibt es. Das neue Fallführungssystem des Kantons Bern sollte bewusst als kleine erste Version entstehen, gemeinsam mit den ersten Gemeinden entwickelt und im Betrieb ausgebaut. Es steckt trotzdem in der Krise. Der Kredit von 52 Mio. Franken wird laut dem zuständigen Amtsleiter «wahrscheinlich nicht ausreichen», und er sagt: «Rückblickend erfolgte die Einführung zu früh.» Das Zollprogramm DaziT arbeitet agil, die Finanzkontrolle lobte 2022 seine Steuerung, und trotzdem wurde die Umstellung der Einfuhr um rund ein Jahr verschoben.

Dazu kommt ein grundsätzlicher Einwand, den ich ernst nehme. Er lautet ungefähr so: Agil heisst, man weiss nicht, was es kostet, und nicht, wann es fertig ist. Ein Parlament hat aber das Recht, beides zu wissen, bevor es zustimmt. Feste Regeln schützen zudem vor Missbrauch. Bei INSIEME entstanden die Anforderungen ab 2009 laut Bundesrat schrittweise, statt zu Beginn komplett festgelegt zu werden. In denselben Jahren vergab die Steuerverwaltung jährlich Dutzende Aufträge knapp unter dem Schwellenwert ohne Ausschreibung. Und wer Industriepolitik fordert, muss sich fragen lassen, ob der Staat Gewinner auswählen kann. Für jedes TSMC gibt es staatlich geförderte Firmen, von denen niemand mehr spricht. Eine Bevorzugung nationaler Anbieter verbietet das Schweizer und das internationale Beschaffungsrecht ohnehin, wie der Bundesrat festhält.

In einem Punkt hat die Gegenseite recht: Das Etikett hilft nichts. Ein System für 85 Organisationen mit einem Kredit von 52 Mio. Franken bleibt ein Grossprojekt, auch wenn es mit einer kleinen ersten Version beginnt. Entscheidend ist nicht die Methode auf dem Papier, sondern wie gross der einzelne Schritt ist, wie früh echte Nutzer ihn sehen und ob das Wissen im Haus bleibt.

In diesem Einwand stecken ein echtes Dilemma und eines, das nur so aussieht. Echt ist der Zielkonflikt zwischen Kostenwahrheit im Voraus und Lernen unterwegs. Beides zugleich maximieren kann niemand. Scheinbar ist dagegen der Gegensatz zwischen Kontrolle und kleinen Schritten. Ein Parlament, das jedes Jahr sieht, was ein Team geliefert hat, weiss mehr als eines, das einen Kredit für sieben Jahre bewilligt und am Ende eine Abrechnung erhält. Wer Kostenkontrolle will, müsste kleine Tranchen verlangen, nicht Bindungen über 14 Jahre.

Auch INSIEME spricht nicht gegen kleine Schritte. Die Freihandvergaben waren ein grosses Projekt, das man in kleine Verträge zerlegt hat, um die Ausschreibung zu umgehen. Und Gewinner muss der Staat nicht auswählen. Er muss ein guter Kunde sein: in kleinen Losen kaufen, Zusammenschlüsse zulassen, offenen Code verlangen. Das bevorzugt niemanden nach Herkunft, sondern Anbieter, die in kleinen Schritten gute Arbeit liefern. Dass darunter viele Schweizer Firmen wären, ist eine Folge, keine Bedingung.

Die Finanzkontrolle schreibt auch, das Argument, die Gesetze verhinderten die Zusammenarbeit, die agile Methoden brauchen, entpuppe sich «oftmals als Ausrede». Ich lese das als gute Nachricht. Wenn das Recht Dialog mit den Anbietern, Qualitätswettbewerb und Rahmenverträge schon erlaubt, liegt das Problem in der Praxis und in den Anreizen. Beides lässt sich schneller ändern als ein Gesetz.

Ob der Bund die Leute findet, weiss ich nicht. 2023 konnten seine IT-Abteilungen einen Viertel der ausgeschriebenen Stellen nicht besetzen. Den Aufbau der Kompetenzen und Strukturen für agiles Arbeiten veranschlagt die Finanzkontrolle auf drei bis vier Jahre. Das ist kein Grund zu warten. Es ist der Grund, jetzt anzufangen und nicht erst nach der nächsten Bindung über 14 Jahre.

Gut für Tunnel, schlecht für Software

Für den Gotthard war das Verfahren richtig. Man wusste, wo der Tunnel beginnt und wo er endet. Bei Software weiss man das nie, und deshalb kommt die Finanzkontrolle nach zehn Jahren zum selben Befund. Der Bund muss nicht lernen, grosse IT-Projekte zu führen. Er muss aufhören, welche zu machen.

Auf Plural hat der Verein CH++ eine Initiatividee eingebracht, die beim Bund ansetzt: ein eigenes Departement, das Informatik, Daten, Cybersicherheit und KI bündelt. Ich habe dort selbst einige Aspekte ergänzt, darunter die beiden oben eingebetteten.

Meine Position dazu: Ein neues Departement allein ist eine Reorganisation, und Reorganisationen tragen dasselbe Risiko wie Grossprojekte. Es lohnt sich nur, wenn es ändert, wie der Staat Software baut und bezahlt, und nicht bloss Zuständigkeiten bündelt. Ob dafür ein Departement der richtige Hebel ist oder ob es reicht, Budget und Beschaffung umzubauen, darüber kann man mit guten Gründen streiten.

Du kennst jetzt beide Seiten. Wie siehst du es?

Oliver Herren ist Mitgründer von Plural, Digitec Galaxus und True Wealth. Er schreibt hier seine persönliche Meinung, nicht die von Plural.