Perché i grandi progetti IT del governo falliscono continuamente.

Chi a Zurigo riceve l'assistenza sociale ottiene ogni mese un budget: tanto per l'affitto, tanto per il sostentamento. Con il nuovo software dei Servizi Sociali questo budget non è stato creato in modo comprensibile fino a febbraio 2026, come annota l'ombudsman della città in un rapporto. Il denaro che qualcuno aveva ricevuto indebitamente la città non è riuscita a recuperare nel 2025. Il sistema non prevedeva alcun recupero.

Le richieste per questo software sono state raccolte da esperti di Berna, Basilea e Zurigo nel 2013 durante workshop svolti. A gennaio 2018 l'associazione congiunta delle tre città ha assegnato l'incarico. Berna ha cambiato nel 2023, Zurigo a gennaio 2025, Basilea probabilmente all'inizio del 2027. Tra il primo workshop e il primo caso di Zurigo sono passati più di undici anni. L'ombudsman riassume nel suo rapporto annuale una conclusione concisa: l'implementazione deve essere «purtroppo considerata fallita anche a Zurigo».

Il 20 ottobre 2026 il governo federale ha indetto una gara per una cloud fino a 7 miliardi di franchi pubblicata. I contratti hanno una durata complessiva di 14 anni.

Un software per l'assistenza sociale e una cloud hanno poco in comune. Il loro problema è lo stesso. Lo Stato fallisce con il software non per mancanza di diligenza, ma a causa del software stesso. Lo progetta come un tunnel, lo assegna in un unico blocco e lo finanzia come un progetto con una fine. Il software, però, non ha fine.

Nessun guasto, ma un modello

Citysoftnet, così si chiama il software di Zurigo, non è un caso isolato. L'elenco dei grandi progetti IT che sono andati fuori controllo è sufficientemente lungo per una tabella:

I progetti provengono da diversi dipartimenti e decenni, ma presentano analogie. All'inizio c'è un sistema integrato destinato a sostituire molti vecchi sistemi contemporaneamente. Le richieste nascono anni prima che il primo utente veda il sistema. Il passaggio avviene in una data fissata, quando il vecchio sistema viene disconnesso. E i ruoli chiave sono occupati da esterni che poi lasciano il progetto. Nel caso di INSIEME, secondo il rapporto parlamentare, «la maggioranza dei posti era occupata da esperti esterni».

Non è questione di sfortuna. La Controllo finanziario federale ha valutato nel 2026 le verifiche dei grandi progetti IT di due anni, 24 rapporti su un volume compreso tra 3 e 5 miliardi di franchi. Il risultato: le carenze principali identificate già nel 2016 persistono. Un capitolo del rapporto è intitolato «L'organizzazione non impara sistematicamente».

La Segreteria di Stato federale risponde nella sua dichiarazione. Delle circa 200 iniziative completate ogni anno, la gran parte ha successo. Lo credo, e questo sostiene l'argomento più che contraddirlo. I piccoli progetti funzionano. Sono i grandi a fallire.

Un tunnel è completato, il software no

La Svizzera può costruire un tunnel ferroviario di 57 chilometri attraverso il Gotthard. La procedura è consolidata: pianificare, calcolare i costi, bandire, costruire, collaudare. Nel settore software questo approccio è chiamato waterfall, perché ogni fase fluisce nella successiva senza ritorno. Funziona per un tunnel. Deve collegare due porte, e in 17 anni di costruzione nulla cambia.

Per il software è l'opposto. All'inizio si sa meno. Un assistente sociale capisce davvero di cosa ha bisogno solo quando utilizza il sistema. E la tecnologia evolve più velocemente di quanto duri una gara d'appalto. Chi nel 2012 avesse ordinato una cloud per 14 anni non avrebbe potuto conoscere strumenti come Kubernetes o i grandi modelli di IA. Oggi sono all'ordine del giorno.

Che la dimensione stessa sia il rischio è dimostrato anche dai dati. Uno studio di McKinsey e dell'Università di Oxford su più di 5.400 progetti IT ha concluso che i grandi progetti oltre i 15 milioni di dollari superano in media il budget del 45% e forniscono il 56% in meno di benefici rispetto a quanto promesso. Chi ordina in grande ottiene in media meno della metà dei benefici per quasi una volta e mezza il denaro speso. Ogni anno aggiuntivo di progetto aumenta lo scostamento del 15%. Bent Flyvbjerg e Alexander Budzier hanno trovato, su 1.471 progetti IT, che uno su sei costa in media tre volte quanto previsto.

Negli ultimi 25 anni ho co-fondato diverse aziende il cui core è il software, tra cui un commerciante online e un gestore patrimoniale digitale. Nessuna è nata da un documento di specifiche. Abbiamo iniziato in piccolo, testando ogni passo subito con clienti reali e ampliando solo ciò che funzionava. Non c'erano budget di progetto. C'erano team dedicati a un ambito, ciascuno con una persona che decideva cosa costruire dopo, nella terminologia di prodotto il Product Owner. Eravamo rapidi, ma ogni passo era così piccolo che un errore costava poco. Questa è la vera differenza. Non si tratta di velocità contro diligenza, ma di molti piccoli rischi invece di uno grande.

Il sistema premia il grande pacchetto

Una cosa fin da subito: non affermo che negli uffici ci siano le persone sbagliate. L'accusa sarebbe comoda e falsa. Chi legge le regole secondo le quali lo Stato acquista software vede qualcosa di diverso. Il grande progetto è lì la scelta ragionevole.

Inizia dal denaro. Un progetto IT federale richiede un credito di impegno. Il Finanzhaushaltgesetz lo descrive come «importo massimo», fino al quale il Consiglio federale «per uno scopo specifico» può assumere impegni. Viene determinato «sulla base di calcoli accurati, redatti secondo regole professionali». Chi vuole soldi deve quindi stabilire all'inizio cosa costruisce e quanto costa. Proprio quando sa meno. Chi impara qualcosa lungo il percorso ha bisogno di un credito aggiuntivo, e questo è pubblicamente riconosciuto come ammissione di un errore. Nelle città non è diverso: Berna ha dovuto richiedere "mehrere Nachkredite" dal 2023 per Citysoftnet.

Poi si indice una gara, come un appalto a un fornitore. Per Citysoftnet la normativa di approvvigionamento dell'epoca vietava qualsiasi dialogo con i fornitori. Le offerte e i prezzi sarebbero quindi stati «parzialmente basati su ipotesi errate», ha scritto il Berner Gemeinderat in seguito. Una volta assegnato l'appalto, ogni cambiamento diventa costoso. La Beschaffungsgesetz consente poi persino di assegnare contratti successivi senza gara al fornitore attuale, se un cambiamento comporterebbe «costi sostanziali». Il Bundesrat ha spiegato nel 2025 perché ha prorogato manualmente i contratti cloud esistenti: un cambio di fornitore per il periodo di transizione «sarebbe associato a rischi significativi di interruzione e di sicurezza nonché a costi sproporzionati». Questo è l'esempio di un lock‑in, una dipendenza da cui non si esce facilmente.

E ogni progetto ha una fine. Il metodo di progetto federale, HERMES, conosce dal 2022 anche i progetti agili. Ma anche questi vengono chiusi. Il controllo finanziario riassume la contraddizione in una frase che potrebbe essere appesa in ogni ufficio: «I progetti si evolvono sempre più in modo orientato al prodotto e iterativo, mentre la governance rimane basata sui progetti». Il software viene quindi costruito come un prodotto e gestito come un tunnel.

Perciò è di poco aiuto che i team lavorino in modo agile, cioè in cicli brevi con feedback continui. Per Citysoftnet il fornitore ha lavorato secondo una Gutachten per il parlamento cittadino di Berna in modo agile, ma i progetti stessi sono seguiti secondo HERMES. Per le telecomunicazioni dell'esercito, un progetto da circa 1,9 miliardi di franchi, è stato deciso di procedere in modo agile solo nel 2025, dopo l'assegnazione, per una parte del progetto. Questo deve ora essere retrofittato «nelle strutture contrattuali», e secondo la Finanzkontrolle sono emersi «ulteriori ritardi». Lo definisco una cascata con sprint: team agili in un quadro che all'inizio definisce tutto.

Rimane la domanda su chi possieda la conoscenza. La Finanzkontrolle spricht parla di «una quota già oggi elevata di personale esterno nei progetti IT». L'approvvigionamento esterno è «relativamente costoso» e aumenta «il rischio di perdita di conoscenza». Chi non costruisce in proprio può solo ordinare. E chi ordina deve scrivere tutto in anticipo.

Il cloud segue lo stesso piano di costruzione

Un cloud non è un sistema di gestione dei casi. È infrastruttura: data center, storage, rete. Si acquista, non si inventa. E il nuovo bando è costruito meglio di INSIEME. Lo Stato vergibt assegna tre lotti a cinque diversi fornitori, paga solo ciò che utilizza e riapre il mercato dopo sette anni. I 7 miliardi di franchi sono un tetto massimo e non una spesa, distribuiti su 14 anni fino a 500 milioni di franchi all'anno. Quanto il tetto massimo e il consumo possano differire è evidente nei contratti cloud esistenti: da un tetto di costo di 110 milioni di franchi lo Stato ha richiesto fino a settembre 2025 rund 61 Mio. abgerufen.

Tuttavia il cloud nasce secondo il vecchio piano. La strategia cloud federale risale a dicembre 2020. I primi servizi dovrebbero essere attivati nell'autunno 2027, salvo reclami intermedi. Dalla strategia al primo prelievo passano quindi sette anni. I contratti quadro durano fino al 2034, i singoli contratti fino al 2041.

Se ne valga la pena, oggi nessuno lo sa. Il Botschaft des Bundesrats ha dichiarato nel 2024 che esiste «solo un quadro di costi, non un'analisi costi‑benefici». La Finanzkontrolle ha scritto nel 2025 che il beneficio economico non è ancora stato dimostrato. L'uso non è obbligatorio e gli uffici non si sono «finora impegnati». Il rischio di ulteriori ritardi e reclami nell'approvvigionamento è considerato alto nello stesso rapporto. Anche qui si vedrà solo all'apertura se il tunnel ne vale la pena.

Ciò che più mi preoccupa è qualcos'altro. Il parlamento ha beschlossen deciso che per il cloud «se possibile» si preferiscano soluzioni open source e aziende con sede in Svizzera. Tuttavia la Ausschreibung non consente consorzi, quindi nessuna alleanza tra più imprese, e ogni fornitore può partecipare a un solo lotto. Un fornitore svizzero, troppo piccolo da solo, non può unirsi ad altri. Come subfornitore di un grande può partecipare, ma non come partner alla pari. Chi vuole promuovere fornitori svizzeri dovrebbe permettere loro di unirsi. L'appalto fa il contrario.

Scrivo come imprenditore che ha beneficiato di un forte polo tecnologico svizzero. Questo è importante da sapere quando si valuta l'argomento. Ho presentato il problema come questione in una proposta per un dipartimento federale della tecnologia, a cui tornerò alla fine:

Non dico che il cloud fallirà. Dico che sarà costruito secondo lo stesso piano dei progetti che sono falliti: grande, lungo, e il beneficio si vede solo alla fine.

Piccolo, autonomo, duraturo

Il miglior controesempio proviene dalla stessa amministrazione fiscale che ha dovuto interrompere INSIEME. Anche il progetto successivo FISCAL-IT è finito in difficoltà nel 2016, un grande rilascio è stato annullato a causa di errori critici. Successivamente l'amministrazione ha cambiato: team agili insieme all'Ufficio federale di informatica, alla fine di ogni ciclo di sviluppo di 14 giorni una dimostrazione del software. Nel 2020 la "Finanzkontrolle", ha affermato che lo sviluppo agile e i team congiunti si erano "dimostrati efficaci". L'amministrazione fiscale vuole evitare "soluzioni integrate" dei propri sistemi da allora.

La stessa agenzia ha ricevuto a maggio 2021 l'incarico per il Covid-Zertifikat. Tre settimane dopo le prime persone in Svizzera tenevano in mano un certificato. Il codice sorgente è aperto, l'Austria ha basato la sua app su di esso. Funziona quindi, anche nella stessa amministrazione.

Altri paesi hanno trasformato i loro fallimenti in regole. Il Regno Unito ha deciso nel 2014 di non stipulare più contratti IT superiori a 100 milioni di sterline, salvo casi eccezionali. Da allora non ci sono più rinnovi automatici, i contratti di hosting durano al massimo due anni. In Francia piccoli team statali sviluppano servizi digitali propri. Il Rechnungshof ha elencato oltre 450 prodotti che sono stati sperimentati o sviluppati in questo modo. In un campione uno costava in media 290'000 euro all'anno per sviluppo e design. È una frazione di quello che costa un grande progetto all'anno.

Da ciò nasce una proposta in quattro parti. Prima, lo Stato finanzia prodotti invece di progetti: team permanenti per un ambito tematico, ad esempio assistenza sociale o tasse, con un budget annuale. Il Parlamento li valuta in base a ciò che cittadini e amministrazione usano realmente, non in base a un pacchetto di consegne. Secondo, si fissa un tetto massimo per dimensione e durata dei contratti IT, seguendo l'esempio britannico. Terzo, lo Stato costruisce il nucleo con sviluppatori interni e ricorre a esterni per le competenze più avanzate. Secondo Finanzkontrolle, lo Stato può pagare salari di mercato, ma non sempre per funzioni altamente specializzate. Quarto, il codice è aperto, come già richiesto dalla Gesetz dal 2024 per il software che lo Stato sviluppa o fa sviluppare.

Il quarto punto è più di una questione tecnica. Quando lo Stato spende miliardi per l'informatica, decide anche quali aziende esisteranno tra dieci anni. Se acquista grandi pacchetti dai maggiori fornitori mondiali, finanzia la loro crescita. Se acquista in piccoli lotti, permette fusioni e rende il suo codice aperto, nascono aziende svizzere capaci di fare questo lavoro e poi venderlo ad altri clienti. Ne derivano posti di lavoro e entrate fiscali. Grandi aziende tecnologiche spesso nascono con l'aiuto a lungo termine dello Stato. Il produttore di chip TSMC è stato fondato nel 1987 come Gemeinschaftsunternehmen del governo taiwanese, del conglomerato elettronico Philips e di investitori privati. Oggi è, secondo le proprie dichiarazioni, il principale produttore di chip su commissione al mondo. Chi non investe nelle fondamenta non dovrebbe sorprendersi se mancherà in futuro.

Alla stessa idea di iniziativa ho anche proposto una soluzione che va in questa direzione:

L'agilità è solo un'etichetta?

Si potrebbe fermare qui. Tuttavia non è così semplice, e le obiezioni più forti provengono da Finanzkontrolle stessa. Non può dedurre dalle sue verifiche che i progetti agili rispettino meglio budget e scadenze rispetto a quelli tradizionali. E avverte che i metodi agili sono spesso considerati "perché intrinsecamente promettenti".

Gli esempi esistono. Il nuovo sistema di gestione dei casi del cantone di Berna doveva nascere consapevolmente come una piccola prima versione, sviluppata insieme ai primi comuni e ampliata in esercizio. È comunque trotzdem in der Krise. Il credito di 52 milioni di franchi, secondo il responsabile dell'ufficio, "probabilmente non sarà sufficiente", e afferma: "In retrospettiva l'implementazione è avvenuta troppo presto." Il programma doganale DaziT è gestito in modo agile, la Finanzkontrolle ha elogiato la sua gestione nel 2022, eppure il passaggio delle importazioni è stato rimandato di rund ein Jahr verschoben.

A ciò si aggiunge un'obiezione fondamentale che prendo seriamente. Essa è più o meno così: Agile significa non sapere quanto costerà, non sapere quando sarà finito. Un Parlamento ha il diritto di conoscere entrambe le cose prima di approvare. Regole fisse proteggono anche dall'abuso. In INSIEME i requisiti sono stati introdotti gradualmente dal 2009 secondo il Consiglio federale, invece di essere definiti completamente all'inizio. Negli stessi anni l'amministrazione fiscale ha assegnato annualmente decine di contratti appena sotto la soglia senza gara d'appalto. E chi richiede una politica industriale deve chiedersi se lo Stato possa scegliere un vincitore. Per ogni TSMC esistono aziende finanziate dallo Stato di cui nessuno parla più. Una preferenza per fornitori nazionali è già vietata dalla legge svizzera e internazionale sugli appalti, come ricorda il Bundesrat.

In un punto la controparte ha ragione: l'etichetta non aiuta. Un sistema per 85 organizzazioni con un credito di 52 milioni di franchi resta un grande progetto, anche se parte da una piccola prima versione. L'importante non è il metodo sulla carta, ma la dimensione di ogni passo, quanto presto gli utenti reali lo vedono e se la conoscenza rimane in casa.

In questa obiezione c'è un vero dilemma e uno che sembra tale. Il vero conflitto è tra la verità dei costi in anticipo e l'apprendimento lungo il percorso. Nessuno può massimizzare entrambi simultaneamente. Sembra invece esserci un contrasto tra controllo e piccoli passi. Un Parlamento che ogni anno vede cosa ha consegnato un team sa più di uno che approva un credito per sette anni e alla fine riceve solo un rendiconto. Chi vuole il controllo dei costi dovrebbe richiedere piccole tranche, non impegni di 14 anni.

Anche INSIEME non si oppone ai piccoli passi. Le concessioni senza gara erano un grande progetto suddiviso in piccoli contratti per aggirare la procedura di gara. E lo Stato non deve scegliere un vincitore. Deve essere un buon cliente: acquistare in piccoli lotti, consentire fusioni, richiedere codice aperto. Questo non favorisce nessuno per origine, ma i fornitori che consegnano lavori di qualità in piccoli passi. Che ciò comporti molte aziende svizzere è una conseguenza, non una condizione.

Il controllo finanziario afferma anche che l'argomento, le leggi impedivano la collaborazione, i metodi agili ne hanno bisogno, si rivela «spesso come scusa». Lo leggo come una buona notizia. Se la legge permette già il dialogo con i fornitori, la concorrenza di qualità e i contratti quadro, il problema sta nella pratica e negli incentivi. Entrambi possono cambiare più rapidamente di una legge.

Se il governo troverà le persone, non lo so. Nel 2023 i suoi dipartimenti IT non sono riusciti a coprire un quarto delle posizioni pubblicate. La costruzione di competenze e strutture per il lavoro agile è stimata dal controllo finanziario in tre‑quattro anni. Non è un motivo per aspettare. È il motivo per iniziare ora e non solo dopo il prossimo vincolo di 14 anni.

Buono per i tunnel, cattivo per il software

Per il Gotthard la procedura era corretta. Si sapeva dove inizia il tunnel e dove finisce. Per il software non si sa mai, e per questo il controllo finanziario arriva allo stesso risultato dopo dieci anni. Il governo non deve imparare a gestire grandi progetti IT. Deve smettere di farli.

Su Plural l'associazione CH++ ha proposto un'idea iniziativa che parte dal governo: un dipartimento proprio che raggruppi informatica, dati, cybersicurezza e IA. Ho aggiunto personalmente alcuni aspetti, tra cui i due inseriti sopra.

La mia posizione a riguardo: Un nuovo dipartimento è solo una riorganizzazione, e le riorganizzazioni comportano lo stesso rischio dei grandi progetti. Vale la pena solo se cambia il modo in cui lo Stato costruisce e paga il software, e non solo raggruppa le responsabilità. Se un dipartimento è la leva giusta o se basta ristrutturare budget e approvvigionamento, si può dibattere con buone ragioni.

Ora conosci entrambe le parti. Come la vedi?

Oliver Herren è cofondatore di Plural, Digitec Galaxus e True Wealth. Scrive qui la sua opinione personale, non quella di Plural.