Zero progetti falliti dal 2007 — le regole di ingegneria che reggono il record
Ho fondato Software Tailor nel 2006. Diciannove anni dopo, la società ha distribuito attraverso quattro distinti cicli economici, sei clienti Fortune Global 500 nei settori farmaceutico, finanziario, pubblico, legale, della difesa e dell'energia, e zero progetti falliti dal 2007. Quest'ultimo numero è quello su cui investitori e revisori di procurement chiedono più spesso conto, ed è l'unico che necessita di una spiegazione. Ecco le quattro regole di ingegneria che reggono il record.
Regola 1: Un unico modello di delivery, nessuna confusione tra servizio e prodotto
Ogni incarico di Software Tailor segue lo stesso modello di delivery — una fase pilot dallo scope strettamente definito che rilascia software funzionante, seguita da un'espansione che il cliente sceglie di finanziare (o no) sulla base di ciò che è stato rilasciato. Non gestiamo una pratica di "servizi" separata che rilascia contro documenti di requisiti e una pratica di "prodotto" separata che rilascia contro roadmap. Le due cose entrerebbero in conflitto; una sussidierebbe sempre l'altra.
Il modello unico fa sì che ogni ingegnere sappia che aspetto abbia il "fatto" prima di iniziare. È la precondizione per non fallire.
Regola 2: Disciplina sulla coorte di clienti — solo clienti per i quali possiamo davvero rilasciare
La nostra coorte di clienti è selezionata — non opportunistica. Sei clienti Fortune Global 500 in 19 anni non sono una pipeline commerciale lenta; sono una soglia di selezione deliberata. Ogni cliente che accettiamo deve superare tre test prima del kickoff: il loro problema è uno che abbiamo già risolto in passato, il loro sponsor interno è la persona che utilizzerà il software (non uno strato di intermediari), e il loro ambiente hardware/dati ci consente di rilasciare senza una deviazione di procurement di sei mesi.
Un cliente che fallisce uno qualsiasi di quei test diventa una referral verso qualcun altro, non un progetto. È la regola che ci costa fatturato più spesso. È anche quella che ha zero eccezioni in 19 anni.
Regola 3: Disciplina ingegneristica mappata su un framework riconosciuto
Molto prima che il risk management dell'AI avesse un proprio framework, le regole di ingegneria che ho codificato per Software Tailor combaciavano già con la stessa forma: governare il lavoro, mappare i rischi, misurare gli esiti, gestire i cambiamenti. Il NIST AI RMF 1.0 [1] ha formalizzato quello schema per l'AI nel 2023, e il profilo Critical Infrastructure di aprile 2026 [1] lo ha esteso ai settori regolamentati. Leggendo quei documenti, la nostra disciplina interna si mappa in modo pulito sulle quattro funzioni.
Cosa ci dà questo: ogni progetto è auditabile end-to-end rispetto a un framework esterno, non solo rispetto alle nostre abitudini. Quando un team di procurement chiede come si decida lo scope della fase pilot, la risposta è la stessa che darebbe il NIST per il risk management — e il team di compliance del cliente ha già interiorizzato quel vocabolario.
Regola 4: Registrabile, recuperabile, ricreabile
La quarta regola precede il vocabolario di audit trail che oggi usiamo per AI Suite. Ogni incarico di Software Tailor opera in uno stato in cui qualunque decisione, qualunque artefatto, qualunque versione del codice può essere ricreata a partire da input versionati. Non è insolito per l'ingegneria del software in generale; ciò che è insolito è che lo applichiamo al progetto, non solo al codice. Decisioni di sprint, modifiche di scope, sign-off del cliente — tutto registrato, tutto recuperabile.
La disciplina è il motivo per cui il nostro approccio ai log di audit privi di contenuto per AI Suite è stato spedito così come è stato. Lo schema della riga di audit è lo stesso schema che applicavamo già ai progetti. Il vocabolario è preso in prestito dai quadri di compliance; la pratica è presa in prestito dal modo in cui rilasciamo.
Cosa è passato in AI Suite
La linea Local AI Suite + AI Admin Console — vedi Perché distribuiamo l'AI come binari installabili, non come SaaS cloud — è la stessa disciplina di ingegneria applicata a una linea di prodotto invece che a un incarico personalizzato. Stesso modello di delivery unico (installer desktop che il cliente esegue nel proprio ambiente), stessa disciplina sulla coorte di clienti (settori regolamentati con vincoli chiari di data-residency), stessa mappatura sui framework (NIST AI RMF + obblighi del deployer dell'EU AI Act), stessa postura di audit registrabile-recuperabile-ricreabile.
Zero progetti falliti dal 2007 non è uno slogan. È il risultato di un piccolo numero di regole applicate senza eccezioni. Le stesse regole oggi governano il modo in cui AI Suite viene costruito.
Riferimenti
- NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Consultato il 2026-07-15.
Articoli correlati
Metti alla prova la stessa disciplina su un carico di lavoro reale.
La piattaforma AI on-premises è costruita sulle stesse regole che hanno prodotto il record — registrabile, recuperabile, ricreabile, applicate senza eccezioni. Distribuiscila su un carico di lavoro reale nel tuo ambiente e mettila allo stesso standard.