¿Por qué los grandes proyectos de TI del gobierno federal fracasan una y otra vez?

Quien recibe asistencia social en Zúrich, recibe cada mes un presupuesto: tanto para el alquiler, tanto para el sustento. Con el nuevo software de los Servicios Sociales, este presupuesto no se pudo elaborar de forma comprensible hasta febrero de 2026, como indica el ombudsman de la ciudad en un informe. El dinero que alguien había recibido indebidamente, la ciudad no pudo reclamar en 2025. El sistema no conocía la devolución.

Los requisitos para este software fueron recopilados por expertos de Berna, Basilea y Zúrich en 2013 en talleres recogidos. En enero de 2018 la asociación conjunta de las tres ciudades adjudicó el contrato. Berna cambió en 2023, Zúrich en enero de 2025, Basilea se espera a principios de 2027. Entre el primer taller y el primer caso en Zúrich pasaron más de once años. La oficina del ombudsman extrae en su informe anual una conclusión breve: la puesta en marcha debe «lamentablemente también considerarse fallida en Zúrich».

El 20 de octubre de 2026 el gobierno federal lanzó una licitación para una nube de hasta 7 000 millones de francos publicada. Los contratos tienen una duración total de 14 años.

Un software de asistencia social y una nube tienen poco en común. Su problema sigue siendo el mismo. El Estado fracasa en el software no a pesar de su diligencia, sino por él. Lo planifica como un túnel, lo adjudica de una sola vez y lo financia como un proyecto con un final. Pero el software no tiene final.

Sin fallos, sino un patrón

Citysoftnet, así se llama el software de Zúrich, no es un caso aislado. La lista de grandes proyectos de TI que se han salido de control es lo suficientemente larga para una tabla:

Los proyectos provienen de diferentes departamentos y décadas, y sin embargo se parecen. Al principio hay un sistema integral que debe reemplazar muchos sistemas antiguos de una sola vez. Los requisitos se generan años antes de que el primer usuario vea el sistema. La migración se realiza en una fecha límite, cuando el sistema antiguo se desconecta. Y los roles clave los ocupan externos que abandonan el proyecto después. En INSIEME estaban, según el informe de investigación del parlamento, «mayoritariamente ocupados por expertos externos».

Eso no es cuestión de suerte. La Contraloría Federal suiza evaluó en 2026 sus auditorías de los grandes proyectos de TI de dos años, 24 informes sobre un volumen de 3 a 5 000 Mio. de francos. Su conclusión: los déficits esenciales que ya había señalado en 2016 siguen presentes. Un capítulo del informe lleva el título «La organización no aprende sistemáticamente».

La Cancillería Federal mantiene en su respuesta que, de los aproximadamente 200 proyectos que se completan cada año, la gran mayoría tiene éxito. Yo lo creo, y eso refuerza el argumento más que lo contradice. Los proyectos pequeños funcionan. Son los grandes los que fracasan.

Un túnel se termina, el software nunca

Suiza puede construir un túnel ferroviario de 57 kilómetros a través del Gotardo. El procedimiento está probado: planificar, calcular costos, licitar, construir, aceptar. En la industria del software este enfoque se llama cascada, porque cada fase fluye a la siguiente y no hay retroceso. Funciona para un túnel. Conecta dos portales y nada cambia en los 17 años de construcción.

En el software es al revés. Al principio se sabe menos. Lo que un trabajador social realmente necesita, a menudo lo descubre solo cuando usa el sistema. Y la tecnología cambia más rápido de lo que dura una licitación. Quien hubiera pedido una nube por 14 años en 2012 no habría conocido herramientas como Kubernetes o los grandes modelos de IA. Hoy son cotidianos.

Que el tamaño mismo sea el riesgo lo demuestran también los números. Un estudio de McKinsey y la Universidad de Oxford sobre más de 5 400 proyectos de TI concluyó que los proyectos grandes de más de 15 Mio. de dólares superan su presupuesto en un promedio del 45 % y entregan un 56 % menos de valor del prometido. Quien pide en grande recibe, en promedio, menos de la mitad del valor por casi una vez y media más de dinero. Cada año adicional del proyecto aumentó el exceso en un 15 %. Bent Flyvbjerg y Alexander Budzier encontraron en 1 471 proyectos de TI que uno de cada seis costó, en promedio, tres veces lo planificado.

En los últimos 25 años he cofundado varias empresas cuya actividad principal es el software, incluyendo un comercio electrónico y un gestor de patrimonio digital. Ninguna surgió a partir de un pliego de requisitos. Empezamos pequeño, probando cada paso inmediatamente con clientes reales y solo ampliamos lo que funcionaba. No había presupuestos de proyecto. Había equipos dedicados permanentemente a un área temática, cada uno con una persona que decide qué se construye a continuación, en la jerga profesional el Product Owner. Éramos rápidos, pero cada paso era tan pequeño que un error costaba poco. Esa es la verdadera diferencia. No se trata de velocidad contra diligencia, sino de muchos riesgos pequeños en lugar de uno grande.

El sistema premia el paquete grande

Una cosa por delante: No afirmo que en las administraciones haya gente equivocada. Esa acusación sería cómoda y falsa. Quien lee las normas bajo las cuales el Estado encarga software ve algo diferente. El gran proyecto allí es la elección sensata.

Todo comienza con el dinero. Un proyecto de TI federal necesita una línea de crédito comprometida. El Finanzhaushaltgesetz lo describe como «límite máximo», hasta el cual el Consejo Federal «puede contraer compromisos para un propósito específico». Se determina «sobre la base de cálculos cuidadosos elaborados según normas profesionales». Quien quiere dinero debe, al principio, definir qué construye y cuánto cuesta. Exactamente cuando menos sabe. Cuando se aprende sobre la marcha, se necesita un crédito adicional, y eso se reconoce públicamente como admisión de un error. En las ciudades no es diferente: Berna ha tenido que solicitar "mehrere Nachkredite" desde 2023.

Luego se licita, como un contrato a un proveedor. En Citysoftnet la normativa de adquisiciones de entonces prohibía cualquier diálogo con los oferentes. Las ofertas y precios se basaron "en parte en suposiciones incorrectas", escribió el Berner Gemeinderat más tarde. Una vez adjudicado el contrato, cualquier cambio resulta costoso. La Beschaffungsgesetz permite incluso asignar contratos subsiguientes sin licitación al proveedor actual si un cambio implicaría "costos sustanciales adicionales". El Bundesrat justificó en 2025 por qué extendió de forma directa los contratos de nube existentes: Un cambio de proveedor para el período de transición "conllevaría riesgos significativos de interrupción y seguridad, así como costos desproporcionados". Así es como se ve un lock‑in, una dependencia de la que no se sale fácilmente.

Y todo proyecto tiene un final. El método de proyecto del gobierno, HERMES, conoce desde 2022 también proyectos ágiles. Pero incluso estos se cierran. El control financiero resume la contradicción en una frase que podría colgar en cualquier oficina: «Los proyectos se desarrollan cada vez más de forma orientada al producto e iterativa, mientras la gobernanza sigue basada en proyectos». Por lo tanto, el software se construye como un producto y se gestiona como un túnel.

Por eso ayuda poco que los equipos trabajen de forma ágil, es decir, en ciclos cortos con retroalimentación continua. En Citysoftnet el proveedor trabajó según un Gutachten para el parlamento municipal de Berna de forma ágil, mientras los proyectos siguieron HERMES. En la telecomunicación del ejército, un proyecto de unos 1,9 mil millones de francos, se decidió en 2025, después de la adjudicación, avanzar de forma ágil en una sub‑parte. Eso ahora debe reflejarse retroactivamente "en las estructuras contractuales", y según el Finanzkontrolle se han generado "retrasos adicionales". Lo llamo una cascada con sprints: equipos ágiles dentro de un marco que define todo al inicio.

Queda la pregunta de quién posee el conocimiento. El control financiero spricht dice que ya hay "un alto porcentaje de profesionales externos en los proyectos de TI". La contratación externa es "relativamente cara" y aumenta "el riesgo de pérdida de conocimiento". Quien no construye por sí mismo solo puede comprar. Y quien compra debe describir todo de antemano.

La nube sigue el mismo plan de construcción

Una nube no es un sistema de gestión de casos. Es infraestructura: centros de datos, almacenamiento, redes. Eso se compra, no se inventa. Y la nueva licitación está mejor diseñada que INSIEME. El gobierno vergibt tres lotes a cinco proveedores diferentes, paga solo lo que usa y reabre el mercado después de siete años. Los 7 mil millones de francos son un techo y no un gasto, distribuidos en 14 años hasta 500 millones de francos al año. La distancia entre el techo y el consumo real se muestra en los contratos de nube existentes: de un techo de costos de 110 millones de francos, el gobierno había "rund 61 Mio. abgerufen" hasta septiembre de 2025.

Sin embargo, la nube se crea según el antiguo plan. La estrategia de nube del gobierno data de diciembre de 2020. Los primeros servicios deberían adquirirse a finales del otoño de 2027, siempre que no surjan quejas. Desde la estrategia hasta la primera solicitud transcurren siete años. Los contratos marco se extienden hasta 2034, y los contratos individuales hasta 2041.

Nadie sabe hoy si vale la pena. El Botschaft des Bundesrats afirmó en 2024 que solo existe "un marco de costos, pero no un análisis de costo‑beneficio". El Finanzkontrolle escribió en 2025 que el beneficio económico "todavía no se ha demostrado". El uso no es obligatorio y las administraciones "hasta ahora no se han comprometido firmemente". El riesgo de más retrasos y quejas en la adquisición se considera alto en el mismo informe. Aquí también solo se verá al abrir el túnel si vale la pena.

Lo que más me preocupa es otra cosa. El parlamento ha beschlossen, que la nube "cuando sea posible" favorezca el código abierto y a empresas con sede en Suiza. Sin embargo, la Ausschreibung no permite consorcios, es decir, la unión de varias empresas, y cada proveedor solo puede participar en un lote. Un proveedor suizo que sea demasiado pequeño no puede asociarse con otros. Puede participar como subcontratista de un gran contrato, pero no como socio igualitario. Si se quiere impulsar a los proveedores suizos, habría que permitirles agruparse. La licitación hace lo contrario.

Escribo esto como empresario que se beneficia de un fuerte ecosistema tecnológico suizo. Eso es lo que se debe saber al evaluar el argumento. En plural presenté el problema como cuestión en una iniciativa para un departamento federal de tecnología, a la que volveré al final:

No digo que la nube vaya a fracasar. Digo que se construye con el mismo plan que los proyectos que han fracasado: grande, largo, y el beneficio solo se ve al final.

Pequeña, propia, duradera

El mejor contraejemplo proviene de la misma administración tributaria que tuvo que abortar INSIEME. También el proyecto sucesor FISCAL-IT se vio en problemas en 2016, un gran lanzamiento tuvo que cancelarse por errores críticos. Después la administración cambió: equipos ágiles junto con la Oficina Federal de Informática, al final de cada ciclo de desarrollo de 14 días una demostración del software. En 2020 escribió la Finanzkontrolle, que el desarrollo ágil y los equipos conjuntos se habían «demostrado». La administración tributaria quiere «evitar lo más posible» soluciones integrales de sus sistemas desde entonces.

La misma oficina recibió en mayo de 2021 el encargo para el Covid-Zertifikat. Tres semanas después, las primeras personas en Suiza tenían un certificado en la mano. El código fuente es abierto, Austria ha construido su aplicación sobre él. Así que funciona, incluso en la misma administración.

Otros países han convertido sus fracasos en reglas. Reino Unido beschloss 2014, no firmar más contratos de TI de más de 100 millones de libras, salvo por razones excepcionales. Desde entonces no hay renovaciones automáticas, los contratos de hosting duran como máximo dos años. En Francia, pequeños equipos estatales desarrollan sus propios servicios digitales. El Rechnungshof contabilizó más de 450 productos que fueron probados o desarrollados de esa manera. En una muestra, uno costó en promedio 290.000 euros al año en desarrollo y diseño. Eso es una fracción de lo que cuesta un gran proyecto al año.

De ello surge una propuesta en cuatro partes. Primero, el Estado financia productos en lugar de proyectos: equipos permanentes para un área temática, como la asistencia social o los impuestos, con un presupuesto anual. El Parlamento los evalúa según lo que ciudadanos y administración realmente usan, no según un alcance de entrega. Segundo, se establece un límite máximo para el tamaño y la duración de los contratos de TI, siguiendo el modelo británico. Tercero, el Estado construye el núcleo con desarrolladores propios y contrata externos para picos. Según Finanzkontrolle, el gobierno puede pagar salarios de mercado, aunque no siempre en funciones altamente especializadas. Cuarto, el código es abierto, como lo exige la Gesetz desde 2024 para el software que el gobierno desarrolla o haga desarrollar, ya exige.

El cuarto punto es más que tecnología. Cuando el Estado gasta miles de millones en informática, decide qué empresas existirán dentro de diez años. Si compra grandes paquetes a los mayores proveedores del mundo, financia su crecimiento. Si compra en lotes pequeños, permite fusiones y publica su código, surgen empresas en Suiza que pueden hacer este trabajo y luego venderlo a otros clientes. De eso provienen empleos e ingresos fiscales. Las grandes empresas tecnológicas a menudo nacen con ayuda estatal a largo plazo. El fabricante de chips TSMC se fundó en 1987 como Gemeinschaftsunternehmen fundado por el gobierno taiwanés, la empresa electrónica Philips y inversores privados. Hoy es, según sus propias declaraciones, el principal fabricante por contrato de chips de computadora del mundo. Quien no invierte en los cimientos no debe sorprenderse si falta.

A la misma idea de iniciativa también he presentado una propuesta de solución que va en esa dirección:

¿No es ágil solo una etiqueta?

Uno podría detenerse aquí. Pero no es tan simple, y los mayores objeciones vienen de la Finanzkontrolle misma. No puede deducir de sus auditorías que los proyectos ágiles cumplan mejor el presupuesto y los plazos que los clásicos. Y advierte que los métodos ágiles se consideran «por sí mismos prometedores» en muchos proyectos.

Hay ejemplos de ello. El nuevo sistema de gestión de casos del cantón de Berna debía surgir deliberadamente como una pequeña versión inicial, desarrollado conjuntamente con los primeros municipios y ampliado en operación. Está trotzdem in der Krise. El crédito de 52 millones de francos, según el responsable, «probablemente no será suficiente», y dice: «En retrospectiva la implementación fue demasiado pronto». El programa aduanero DaziT funciona ágilmente, la Finanzkontrolle elogió en 2022 su gestión, y sin embargo la transición de importación se retrasó rund ein Jahr verschoben.

Se suma una objeción fundamental que tomo en serio. Es dice más o menos: Ágil significa que no se sabe cuánto cuesta, y no cuándo estará terminado. Un Parlamento tiene derecho a saber ambas cosas antes de aprobar. Las reglas fijas también protegen contra abusos. En INSIEME los requisitos surgieron a partir de 2009 según el Consejo Federal de forma gradual, en lugar de estar totalmente definidos desde el inicio. En esos mismos años la administración tributaria adjudicó anualmente decenas de contratos justo por debajo del umbral sin licitación. Y quien exige política industrial debe preguntarse si el Estado puede seleccionar ganadores. Por cada TSMC existen empresas subvencionadas por el Estado, de las que nadie habla. La preferencia a proveedores nacionales está prohibida por la legislación suiza e internacional de adquisiciones, como señala el Bundesrat afirma.

En un aspecto la parte contraria tiene razón: la etiqueta no ayuda. Un sistema para 85 organizaciones con un crédito de 52 millones de francos sigue siendo un gran proyecto, aunque empiece con una pequeña versión inicial. Lo decisivo no es el método en papel, sino el tamaño del paso individual, cuán pronto lo vean usuarios reales y si el conocimiento permanece dentro de la organización.

Este argumento contiene un dilema real y otro que solo parece serlo. Real es el conflicto entre la veracidad de costos anticipados y el aprendizaje en marcha. Nadie puede maximizar ambos a la vez. Lo que parece opuesto es el contraste entre control y pasos pequeños. Un Parlamento que cada año ve lo que un equipo ha entregado sabe más que uno que aprueba un crédito por siete años y al final recibe una liquidación. Quien quiere control de costos debería exigir pequeñas entregas, no compromisos de 14 años.

INSEMIE tampoco se opone a pasos pequeños. Las adjudicaciones libres fueron un gran proyecto que se dividió en contratos pequeños para eludir la licitación. Y el Estado no tiene que elegir ganadores. Debe ser un buen cliente: comprar en lotes pequeños, permitir fusiones, exigir código abierto. Eso no favorece a nadie por origen, sino a proveedores que entregan buen trabajo en pasos pequeños. Que muchas de esas empresas sean suizas es una consecuencia, no una condición.

El control financiero también dice que el argumento de que las leyes impedían la colaboración que los métodos ágiles necesitan a menudo se revela como una excusa. Lo interpreto como una buena noticia. Si la legislación ya permite el diálogo con los proveedores, la competencia de calidad y los contratos marco, el problema está en la práctica y en los incentivos. Ambos pueden cambiarse más rápido que una ley.

No sé si el Estado encontrará a la gente. En 2023 sus departamentos de TI no pudieron cubrir una cuarta parte de los puestos anunciados. El control financiero estima que desarrollar las competencias y estructuras para el trabajo ágil llevará de tres a cuatro años. Eso no es motivo para esperar. Es la razón para comenzar ahora y no después de la próxima vinculación de 14 años.

Bueno para túneles, malo para software

Para el Gotardo el proceso fue correcto. Se sabía dónde empezaba y dónde terminaba el túnel. En el software nunca se sabe, y por eso el control financiero llega al mismo hallazgo después de diez años. El Estado no tiene que aprender a dirigir grandes proyectos de TI. Tiene que dejar de hacerlos.

En Plural la asociación CH++ presentó una idea que parte del Estado: un departamento propio que agrupe informática, datos, ciberseguridad e IA. Yo mismo añadí algunos aspectos, incluidos los dos mencionados arriba.

Mi posición al respecto: Un nuevo departamento es solo una reorganización, y las reorganizaciones conllevan el mismo riesgo que los grandes proyectos. Solo vale la pena si cambia la forma en que el Estado construye y paga el software, y no simplemente agrupa responsabilidades. Se puede debatir con buenos argumentos si un departamento es la palanca adecuada o si basta con reformar el presupuesto y la contratación.

Ahora conoces ambos lados. ¿Qué opinas?

Oliver Herren es cofundador de Plural, Digitec Galaxus y True Wealth. Escribe aquí su opinión personal, no la de Plural.