Por que os grandes projetos de TI do governo federal continuam falhando.

Quem recebe assistência social em Zurique tem um orçamento mensal: tanto para o aluguel quanto para o sustento. Com o novo software dos Serviços Sociais, esse orçamento não pôde ser criado de forma compreensível até fevereiro de 2026, como o Ombudsman da cidade registra em umrelatório. O dinheiro que alguém recebeu indevidamente poderia ser devolvido pela cidade em 2025não foi recuperado. O sistema não previa devolução.

As exigências para esse software foram levantadas por especialistas de Berna, Basel e Zurique em 2013 em workshopsrealizados. Em janeiro de 2018 a associação conjunta das três cidades concedeu o contrato. Berna mudou em 2023, Zurique em janeiro de 2025, Basel provavelmente no início de 2027. Entre o primeiro workshop e o primeiro caso em Zurique passaram-se mais de onze anos. O Ombudsman conclui em seurelatório anual um breve resumo: a implementação deve ser "infelizmente também considerada um fracasso em Zurique".

Em 20 de outubro de 2026 o governo federal lançou uma licitação para uma nuvem de até 7 bilhões de francospublicada. Os contratos têm duração total de 14 anos.

Um software de assistência social e uma nuvem têm pouco em comum. O problema, porém, é o mesmo. O Estado falha em software não por falta de diligência, mas por causa dele. Ele o planeja como um túnel, o concede de uma só vez e o financia como um projeto com fim. Mas o software não tem fim.

Sem falhas, mas um padrão

Citysoftnet, o software de Zurique, não é um caso isolado. A lista de grandes projetos de TI que saíram do controle é suficientemente longa para uma tabela:

Os projetos vêm de diferentes departamentos e décadas, mas apresentam semelhanças. No início há um sistema integrado que deve substituir muitos sistemas antigos de uma só vez. As exigências surgem anos antes de o primeiro usuário ver o sistema. A migração ocorre em uma data fixa, quando o sistema antigo é desligado. E os papéis-chave são ocupados por externos que deixam o projeto depois. No caso do INSIEME, o relatório parlamentar indica que "a maioria das posições era ocupada por especialistas externos".

Isso não é azar. O Controle Financeiro Federal, em 2026, analisou suasauditorias de grandes projetos de TI de dois anos, produzindo 24 relatórios sobre um volume de 3 a 5 bilhões de francos. Seu achado: os principais déficits identificados já em 2016 ainda persistem. Um capítulo do relatório se intitula "A organização não aprende sistematicamente".

O Chanceler Federal responde a isso. Dos cerca de 200 projetos concluídos anualmente, a grande maioria tem sucesso. Eu acredito nisso, e isso reforça o argumento em vez de contradizê‑lo. Os pequenos projetos dão certo. São os grandes que falham.

Um túnel fica pronto, o software nunca

A Suíça pode construir umtúnel ferroviário de 57 quilômetros através do Gotthard. O procedimento é comprovado: planejar, calcular custos, licitar, construir, aceitar. Na área de software isso se chama modelo cascata, porque cada fase flui para a próxima sem retorno. Funciona para um túnel. Ele deve conectar dois portais, e nada muda em 17 anos de construção.

Com software é o inverso. No início sabe‑se menos. O que um assistente social realmente precisa costuma perceber só ao usar o sistema. E a tecnologia muda mais rápido que o tempo de uma licitação. Quem encomendou uma nuvem por 14 anos em 2012 não poderia conhecer ferramentas como Kubernetes ou os grandes modelos de IA. Hoje são rotina.

O próprio tamanho representa risco, como mostram os números. Umestudo da McKinsey e da Universidade de Oxford sobre mais de 5.400 projetos de TI concluiu que projetos grandes acima de 15 milhões de dólares excedem seu orçamento em média 45% e entregam 56% menos benefício do que prometido. Quem encomenda grande recebe, em média, menos da metade do benefício por quase uma vez e meia mais dinheiro. Cada ano adicional aumenta o excesso em 15%. Bent Flyvbjerg e Alexander Budzierdescobriram, em 1.471 projetos de TI, que um sexto custou, em média, três vezes o planejado.

Nos últimos 25 anos, ajudei a criar várias empresas cujo núcleo é software, incluindo um comércio eletrônico e um gestor de patrimônio digital. Nenhum deles surgiu a partir de um documento de requisitos. Começamos pequeno, testando cada passo imediatamente com clientes reais e expandindo apenas o que funcionava. Não havia orçamentos de projeto. Havia equipes permanentes responsáveis por uma área, cada uma com uma pessoa que decide o próximo passo, o que na prática chamamos de Product Owner. Éramos ágeis, mas cada passo era tão pequeno que um erro custava pouco. Essa é a verdadeira diferença. Não se trata de velocidade versus diligência, mas de muitos pequenos riscos ao invés de um grande.

O sistema recompensa o grande pacote

Um aviso prévio: Não afirmo que nas administrações estejam as pessoas erradas. A acusação seria conveniente e falsa. Quem lê as regras segundo as quais o Estado encomenda software vê algo diferente. O grande projeto é a escolha sensata.

Tudo começa com o dinheiro. Um projeto de TI federal precisa de um crédito de compromisso. O Finanzhaushaltgesetz descreve-o como «valor máximo», até o qual o Conselho Federal «para um determinado propósito» pode assumir compromissos. Ele é dimensionado «com base em cálculos cuidadosos elaborados segundo regras técnicas». Quem quer dinheiro, deve então, no início, definir o que vai construir e quanto custa. Exatamente quando sabe menos. Quem aprende ao longo do caminho, precisa de um crédito adicional, e isso é publicamente reconhecido como admissão de erro. Nas cidades não é diferente: Berna tem, desde 2023 mehrere Nachkredite precisar solicitar.

Então é licitado, como um contrato a um fornecedor. No caso do Citysoftnet, a lei de aquisição da época proibia qualquer diálogo com os fornecedores. As ofertas e preços, portanto, «basearam‑se parcialmente em suposições erradas», escreveu o Berner Gemeinderat mais tarde. Uma vez concedida a adjudicação, qualquer troca torna‑se cara. A Beschaffungsgesetz permite então até mesmo conceder contratos subsequentes sem licitação ao fornecedor anterior, se uma troca acarretasse «custos substanciais adicionais». O Bundesrat justificou, em 2025, por que prorrogou livremente os contratos de nuvem existentes: Uma troca de fornecedor para o período de transição «acarreta riscos significativos de interrupção e segurança, bem como custos excessivos desproporcionais». Assim se vê um lock‑in, uma dependência da qual não se sai facilmente.

E todo projeto tem um fim. O método de projetos do governo, HERMES, conhece projetos ágeis desde 2022. Mas mesmo esses são concluídos. O controle financeiro resume a contradição em uma frase que poderia estar pendurada em qualquer escritório: «Os projetos evoluem cada vez mais de forma orientada a produto e iterativa, enquanto a governança permanece baseada em projetos». O software, portanto, é construído como um produto e gerido como um túnel.

Por isso, pouco ajuda se as equipas trabalham de forma ágil, isto é, em ciclos curtos com feedback contínuo. No Citysoftnet, o fornecedor trabalhou, segundo um Gutachten, de forma ágil para o parlamento municipal de Berna, enquanto os projetos seguiam o HERMES. Na telecomunicação do exército, um projeto de cerca de 1,9 mil milhões de francos, foi decidido, em 2025, após a adjudicação, avançar de forma ágil num sub‑projeto. Isso agora tem de ser refletido retroactivamente «nas estruturas contratuais», e, segundo o Finanzkontrolle, isso gerou «novos atrasos». Chamo‑o de cascata com sprints: equipas ágeis dentro de um quadro que define tudo no início.

Permanece a questão de quem detém o conhecimento. O controle financeiro spricht fala do «alto [n] nível de profissionais externos em projetos de TI já hoje». A contratação externa é «relativamente cara» e aumenta «o risco de perda de conhecimento». Quem não constrói por si próprio só pode encomendar. E quem encomenda tem de escrever tudo com antecedência.

A nuvem segue o mesmo plano de construção

Uma nuvem não é um sistema de gestão de casos. É infraestrutura: centros de dados, armazenamento, rede. Algo assim compra‑se, não se inventa. E a nova licitação está melhor construída que a INSIEME. O governo vergibt atribui três lotes a cinco fornecedores diferentes, paga apenas o que utiliza e reabre o mercado após sete anos. Os 7 mil milhões de francos são um teto e não uma despesa, distribuídos ao longo de 14 anos até 500 milhões de francos por ano. O quão distante o teto pode estar do consumo real mostra‑se nos contratos de nuvem existentes: de um teto de custos de 110 milhões de francos, o governo até setembro de 2025 rund 61 Mio. abgerufen já havia consumido cerca de 61 milhões.

Ainda assim, a nuvem surge segundo o antigo plano de construção. A estratégia de nuvem do governo data de dezembro de 2020. Os primeiros serviços devem ser adquiridos no final do outono de 2027, salvo reclamações intervenientes. Da estratégia ao primeiro consumo passam‑se sete anos. Os contratos‑quadro vão até 2034, contratos individuais até 2041.

Se vale a pena, ninguém sabe hoje. A Botschaft des Bundesrats afirmou, em 2024, que há «apenas um enquadramento de custos, mas não uma análise de custo‑benefício». O Finanzkontrolle escreveu, em 2025, que o benefício económico ainda não foi demonstrado. O uso não é obrigatório, e os escritórios ainda não se «comprometeram definitivamente». O risco de novos atrasos e reclamações na aquisição é considerado alto no mesmo relatório. Também aqui só se saberá na abertura se o túnel compensa.

O que mais me ocupa é outra coisa. O parlamento beschlossen decidiu que, na nuvem, «quando possível», deve‑se privilegiar o código aberto e empresas sediadas na Suíça. Contudo, a Ausschreibung não permite consórcios, ou seja, nenhuma aliança de várias empresas, e cada fornecedor pode concorrer apenas a um lote. Um fornecedor suíço, pequeno demais para concorrer sozinho, não pode associar‑se a outros. Como sub‑fornecedor de um grande pode participar, mas não como parceiro em igualdade de condições. Quem quiser promover fornecedores suíços teria de lhes permitir formar consórcios. A licitação faz exatamente o oposto.

Escrevo isto como empresário que beneficia de um forte polo tecnológico suíço. Isso deve ser conhecido ao avaliar o argumento. Em plural, apresentei o problema como questão numa ideia iniciativa para um departamento federal de tecnologia, à qual volto no final:

Não digo que a nuvem vai falhar. Digo que ela será construída segundo o mesmo plano que os projetos que falharam: grande, longo, e o benefício só aparece no final.

Pequeno, próprio, duradouro

O melhor contra‑exemplo vem da mesma administração fiscal que teve que encerrar o INSIEME. Também o projeto sucessor FISCAL‑IT entrou em dificuldades em 2016, um grande lançamento teve de ser cancelado devido a erros críticos. Depois a administração mudou: equipes ágeis em conjunto com o Departamento Federal de Informática, ao final de cada ciclo de desenvolvimento de duas semanas, uma demonstração do software. Em 2020 a "Finanzkontrolle" escreveu que o desenvolvimento ágil e as equipes conjuntas se "provaram". A administração fiscal quer evitar soluções completas dos seus sistemas desde então "o máximo possível".Finanzkontrolle, o desenvolvimento ágil e as equipes conjuntas se "provaram". A administração fiscal quer evitar soluções completas dos seus sistemas desde então "o máximo possível".

A mesma agência recebeu em maio de 2021 a missão para o Covid‑Zertifikat. Três semanas depois as primeiras pessoas na Suíça seguravam um certificado nas mãos. O código‑fonte é aberto, a Áustria construiu seu aplicativo sobre ele. Portanto, funciona, mesmo na mesma administração.

Outros países transformaram seus fracassos em regras. O Reino Unido decidiu em 2014 de não celebrar mais contratos de TI acima de 100 milhões de libras, exceto por motivo excepcional. Desde então não há renovações automáticas, contratos de hospedagem duram no máximo dois anos. Na França, pequenas equipes estatais desenvolvem serviços digitais próprios. O Rechnungshof contou mais de 450 produtos que foram testados ou desenvolvidos dessa forma. Em uma amostra, um custava em média 290 000 euros por ano para desenvolvimento e design. Isso é uma fração do que um grande projeto custa por ano.

Dessa forma surge uma proposta em quatro partes. Primeiro, o Estado financia produtos em vez de projetos: equipes permanentes para um tema, como assistência social ou impostos, com um orçamento anual. O parlamento as avalia pelo que cidadãos e administração realmente utilizam, não por um escopo de entrega. Segundo, há um teto para tamanho e duração de contratos de TI, seguindo o modelo britânico. Terceiro, o Estado constrói o núcleo com desenvolvedores internos e contrata externos para picos. Segundo a Finanzkontrolle, o governo pode pagar salários de mercado, exceto em funções altamente especializadas. Quarto, o código é aberto, como a Lei exige desde 2024 para software que o governo desenvolve ou encomenda.

O quarto ponto vai além da tecnologia. Quando o Estado gasta bilhões em TI, decide quais empresas existirão em dez anos. Se compra grandes pacotes dos maiores fornecedores do mundo, financia seu crescimento. Se compra em pequenos lotes, permite fusões e deixa seu código aberto, surgem empresas na Suíça que podem fazer esse trabalho e depois vendê‑lo a outros clientes. Isso gera empregos e receitas fiscais. Grandes empresas de tecnologia muitas vezes nascem com apoio estatal de longo prazo. O fabricante de chips TSMC foi fundado em 1987 como empresa conjunta do governo taiwanês, da Philips e de investidores privados. Hoje, segundo suas próprias informações, é o principal fabricante de chips por encomenda do mundo. Quem não investe na base não deve se surpreender se ela faltar.

Na mesma ideia de iniciativa, também apresentei uma proposta de solução que segue essa direção:

Agilidade não é apenas um rótulo?

Alguém poderia parar aqui. Mas não é tão simples, e os maiores argumentos vêm da Finanzkontrolle própria. Ela não pode concluir, a partir de suas auditorias, que projetos ágeis cumprem orçamento e prazos melhor que os tradicionais. E alerta que métodos ágeis são vistos como "por si só promissores" em muitos projetos.

Existem exemplos disso. O novo sistema de gestão de casos do cantão de Berna deveria ser criado deliberadamente como uma pequena primeira versão, desenvolvida em conjunto com os primeiros municípios e expandida na operação. Ainda está em crise. O crédito de 52 milhões de francos, segundo o responsável da agência, "provavelmente não será suficiente", e ele afirma: "Em retrospectiva, a implementação foi precoce." O programa aduaneiro DaziT funciona de forma ágil, a Finanzkontrolle elogiou sua gestão em 2022, mas mesmo assim a mudança da importação foi adiada em cerca de um ano.

Além disso, há uma objeção fundamental que levo a sério. Ela diz mais ou menos: ágil significa que não se sabe o custo, nem quando terminará. Um parlamento tem o direito de saber ambos antes de aprovar. Regras fixas também protegem contra abusos. No INSIEME, os requisitos foram definidos gradualmente a partir de 2009, conforme o Conselho Federal, em vez de serem totalmente fixados no início. Nos mesmos anos, a administração fiscal concedia dezenas de contratos anualmente logo abaixo do limiar sem licitação. E quem defende política industrial deve se perguntar se o Estado pode escolher vencedores. Para cada TSMC há empresas financiadas pelo Estado das quais ninguém mais fala. A preferência por fornecedores nacionais é proibida tanto pela lei suíça quanto pela internacional de compras, como o Conselho Federal afirma.

Em um ponto a parte contrária tem razão: o rótulo não ajuda. Um sistema para 85 organizações com um crédito de 52 milhões de francos continua sendo um grande projeto, mesmo que comece com uma pequena primeira versão. O que importa não é o método no papel, mas o tamanho de cada passo, quão cedo usuários reais o veem e se o conhecimento permanece interno.

Neste argumento há um dilema real e outro que parece apenas um. O dilema real é o conflito entre transparência de custos antecipada e aprendizado ao longo do caminho. Ninguém pode maximizar ambos simultaneamente. O aparente contraste entre controle e pequenos passos também é ilusório. Um parlamento que vê anualmente o que uma equipe entregou sabe mais do que um que aprova um crédito por sete anos e só recebe um relatório ao final. Quem quer controle de custos deveria exigir pequenas parcelas, não compromissos de 14 anos.

O INSIEME também não se opõe a pequenos passos. As adjudicações livres foram um grande projeto dividido em pequenos contratos para contornar a licitação. E o Estado não precisa escolher vencedores. Ele deve ser um bom cliente: comprar em pequenos lotes, permitir fusões, exigir código aberto. Isso não favorece ninguém por origem, mas fornecedores que entregam bom trabalho em pequenos passos. O fato de que muitas dessas empresas seriam suíças é uma consequência, não uma condição.

O controle financeiro também afirma que o argumento de que as leis impediam a colaboração necessária para métodos ágeis costuma ser "uma desculpa". Vejo isso como uma boa notícia. Se a lei já permite o diálogo com os fornecedores, a concorrência de qualidade e os contratos-quadro, o problema está na prática e nos incentivos. Ambos podem ser alterados mais rapidamente do que uma lei.

Se o governo federal encontrará as pessoas, não sei. Em 2023, seus departamentos de TI não conseguiram preencher um quarto das vagas anunciadas. O desenvolvimento de competências e estruturas para trabalho ágil foi estimado pelo controle financeiro em três a quatro anos. Isso não é motivo para esperar. É a razão para começar agora e não apenas após o próximo vínculo de 14 anos.

Bom para túneis, ruim para software

Para o Gotthard o procedimento foi correto. Sabia‑se onde o túnel começa e onde termina. Em software nunca se sabe, e por isso o controle financeiro chega ao mesmo veredicto após dez anos. O governo não precisa aprender a conduzir grandes projetos de TI. Precisa parar de fazer esses projetos.

Na Plural, a associação CH++ propôs uma iniciativa que parte do governo: um departamento próprio que agrupe informática, dados, cibersegurança e IA. Eu mesmo acrescentei alguns aspectos, incluindo os dois inseridos acima.

Minha posição a respeito: um novo departamento é apenas uma reorganização, e reorganizações carregam o mesmo risco que grandes projetos. Vale a pena somente se mudar a forma como o Estado desenvolve e paga software, e não apenas agrupar responsabilidades. Se um departamento é a alavanca certa ou se basta reformular orçamento e compras, isso pode ser debatido com bons argumentos.

Agora você conhece ambos os lados. Como você vê isso?

Oliver Herren é cofundador da Plural, Digitec Galaxus e True Wealth. Ele escreve aqui sua opinião pessoal, não a da Plural.