Quanto costa davvero un progetto software? Come IT e le linee di business pianificano sforzo, rischio e riserve in modo realistico

La domanda «Quanto costa davvero un progetto software?» sembra a prima vista semplice: si prende il prezzo giornaliero, si moltiplica per qualche mese e si aggiungono i costi di licenza. Nella pratica le grandi divergenze però raramente derivano dalla sola implementazione di singole funzionalità. Nascono invece dove la realtà aziendale incontra la tecnologia: processi non chiari, problemi dati nascosti, interfacce con effetti collaterali, requisiti di sicurezza e compliance, sforzo per test e accettazione, rollout su più sedi, nonché l’esercizio continuativo dopo il Go-live.

Questo contributo classifica i tipici fattori di costo nei progetti software in modo che la direzione IT, gli amministratori, i responsabili di progetto e le unità di business possano pianificare insieme budget realistici e riserve. Il focus non è sulla programmazione come fine a sé stessa, ma su ciò che rende la pianificazione affidabile nella pratica quotidiana: ipotesi chiare, logiche di stima solide, cataloghi di rischio, punti decisionali e una visione dei costi lungo l’intero ciclo di vita.

Perché «Implementazione» è solo una parte della verità

Molte discussioni sul budget partono con un orizzonte troppo ristretto: «Quanto costa la realizzazione?» Con ciò si intende di solito il tempo di sviluppo. Questa prospettiva è troppo limitata, perché una soluzione digitale vicina ai processi aziendali è quasi sempre integrata in un paesaggio di sistemi esistente. Ciò include modelli utenti e di ruoli, gestione dei dati, interfacce, monitoring, backup, ripartenza, processi di supporto e documentazione. Ognuno di questi livelli genera lavoro che, a seconda del grado di maturità della vostra organizzazione IT, può essere rilevante.

Segni tipici che la prospettiva dei costi è troppo ristretta:

• I requisiti descrivono funzionalità, ma non i flussi di dati, le accettazioni o i requisiti operativi.
• Non c’è un quadro chiaro su quali sistemi debbano essere collegati e chi «possegga» questi sistemi (proprietario, gestione, fornitore).
• Test e accettazione sono considerati „più avanti“, pur essendo fattori che determinano scadenze e budget.
• Lo sforzo per migrazione, autorizzazioni e formazione viene sottostimato.

Un quadro dei costi più realistico si ottiene se si considera il progetto come l’introduzione o la modernizzazione di un sistema produttivo – inclusa la consegna all’esercizio e i costi successivi (Total Cost of Ownership, abbreviato TCO: costi complessivi per esercizio, manutenzione e evoluzione).

Tipologie di costo: CAPEX, OPEX e i costi interni „invisibili“

Nelle aziende i progetti software vengono spesso trattati come investimenti una tantum (CAPEX). L’esercizio e l’evoluzione sono quindi OPEX (costi correnti). Per la pianificazione è fondamentale pensare insieme entrambe le dimensioni: un Go-live economico può diventare costoso se mancano manutenibilità, osservabilità e capacità di supporto.

Praticamente dovreste distinguere almeno quattro tipologie di costo:

• Costi di progetto esterni: implementazione, consulenza, revisioni architetturali, supporto ai test, direzione progetto da parte di fornitori.
• Costi del personale interno: tempo delle unità di business per chiarimento dei processi, test, accettazione (UAT: User Acceptance Test), key-user, responsabili dei dati, gestione IT per gli ambienti.
• Costi tecnici di esercizio: infrastruttura (On-Prem o Cloud), gestione database, monitoring, backup, processi di gestione incidenti e patch, reperibilità.
• Costi di introduzione: formazione, rollout, comunicazione, esercizio in parallelo, doppia rilevazione temporanea, cutover (momento pianificato della transizione).

Proprio i costi interni non vengono spesso quantificati in modo preciso nelle fasi di budget. Questo genera poi conflitti: l’IT „consegna“, ma il reparto specialistico non ha sufficiente capacità per l’accettazione e la pulizia dei dati – il progetto si ritarda e i costi esterni aumentano.

Ciò che le stime di effort devono fornire nel concreto (e ciò che non devono fare)

Una stima dell’effort non è un oracolo, ma uno strumento per decidere in condizioni di incertezza. Deve fornire tre elementi: un corridoio plausibile, un elenco delle assunzioni centrali e un quadro trasparente dei rischi. Le stime falliscono raramente per problemi matematici e più spesso per mancanza di definizione del perimetro e delle condizioni al contorno.

Importante è la distinzione:

• Ambito (estensione della prestazione): Quali processi, ruoli, oggetti dati, interfacce, report e requisiti non funzionali (p.es. performance, disponibilità, auditabilità) sono inclusi?
• Complessità: Quante eccezioni, varianti, autorizzazioni, tenant, lingue, sedi, integrazioni?
• Incognite: Dove mancano informazioni, accessi, qualità dei dati o decisioni di business?

Una stima solida indica esplicitamente cosa non è incluso. Questo non è un minimizzare, ma protegge budget e scadenze. Nella pratica un catalogo di esclusioni ben redatto vale spesso più di un numero con due decimali.

„Quanto costa davvero un progetto software“: i fattori di costo più frequenti

I seguenti driver ricorrono nei progetti indipendentemente dal fatto che stiate sviluppando una nuova software aziendale, modernizzando una soluzione esistente o estendendo un portale.

1) Requisiti soggetti a interpretazione

«L’utente può approvare le operazioni» suona innocuo, ma a seconda dell’organizzazione può significare: revisione a quattro occhi, regole di delega, limiti di importo, registrazione, procedure di escalation, notifiche e-mail, cronologia, reporting. Senza criteri di accettazione (condizioni chiare che definiscono quando qualcosa è «finito e corretto») una funzione diventa un punto di discussione permanente – e il budget un obiettivo mobile.

Per la pianificazione utile: definite per ciascun processo core almeno (a) il Happy Path, (b) le deviazioni frequenti, (c) i casi di errore e (d) le evidenze di accettazione (quali prove si attendono dall’audit o dal responsabile del processo?).

2) Interfacce e i loro effetti collaterali

Le interfacce raramente sono „solo un REST-Endpunkt“. REST (Representational State Transfer) descrive un principio API diffuso per le interfacce web. Nelle architetture enterprise si aggiunge: i modelli dati non combaciano, i campi sono evoluti storicamente, i tempi non coincidono e gli errori devono essere ricostruibili. Ogni integrazione richiede inoltre regole per il versionamento, il monitoraggio e il supporto.

I fattori di costo ricorrenti sono spesso:

• proprietà dei dati poco chiara (quale sistema è autorevole?),
• assenza di ambienti di test o di dati di test,
• cambiabilità limitata dei sistemi di terze parti,
• elaborazione batch vs. elaborazione in tempo reale (ad es. esecuzioni notturne, elaborazione basata su code).

Se attribuite valore alle integrazioni, non pianificate solo la „implementazione“, ma prevedete anche il coordinamento con terze parti, i test contrattuali/delle interfacce, i casi di errore e la documentazione operativa.

3) Migrazione dei dati e qualità dei dati

La migrazione dei dati è regolarmente un sotto-progetto a sé. Non si tratta solo di copiare tabelle, ma di mapping (attribuzione dei vecchi ai nuovi campi dati), pulizia, gestione dei duplicati, storicizzazione e report di riconciliazione. Diventa particolarmente costosa se i dati vengono esaminati solo tardivamente e mancano le regole di business („Come gestiamo indirizzi di consegna non validi?“, „Quali transazioni storiche devono essere migrate?“).

Per una pianificazione realistica sono necessari:

• un inventario di migrazione (quali oggetti, quali quantità, quali fonti),
• un controllo della qualità dei dati (campi obbligatori, range di valori, riferimenti),
• almeno una prova con riconciliazione (campionamenti, totali, plausibilità funzionale),
• una strategia di cutover (freeze dei dati, funzionamento parallelo, piano di rollback).

4) Test, accettazione e regressione

Lo sforzo per i test è spesso sottostimato perché non appare „come progresso“. Nei sistemi prossimi alla produzione è invece il meccanismo che traduce i rischi in lavoro pianificabile. I test di regressione (test ripetuti dopo modifiche) diventano particolarmente rilevanti quando il sistema viene distribuito su più release o quando sono coinvolti molti ruoli.

Determinanti per budget e tempi:

• Chi testa cosa (IT, reparto business, Key-User)?
• Quali ambienti di test esistono, quanto sono vicini alla produzione (Staging)?
• Come vengono forniti, anonimizzati e ripristinati i dati di test?
• Come viene gestito il management dei difetti (priorità, scadenze, approvazioni)?

L’UAT non dovrebbe essere pianificato come „fase finale“, ma come un ritmo ricorrente: consegne piccole e accettabili riducono il rischio di grandi sorprese poco prima del go-live.

5) Sicurezza, autorizzazioni e auditabilità

Le esigenze di sicurezza spesso si concretizzano tardi. A quel punto riguardano non solo il „login“, ma modelli di ruoli, tracciatura (Audit-Trail: registri di modifica e accesso verificabili), ereditarietà dei diritti, recertificazione e, se necessario, Single Sign-on (SSO, ad es. tramite SAML 2.0 come standard per la federazione delle identità).

Sforzi aggiuntivi derivano da:

• coordinamento con l’Identity-Management e i servizi di directory,
• definizione per ruoli tecnici e funzionali,
• registrazione con conservazione e analizzabilità (non solo „Logfiles“),
• processi di approvazione (controllo a quattro occhi, separazione dei compiti).

Se avete bisogno di auditabilità, questo è una caratteristica di architettura e di esercizio, non una spunta da aggiungere in seguito.

6) Prontezza operativa: monitoraggio, runbook, supporto

Un sistema è completato solo quando è gestibile in esercizio. Questo include il monitoraggio (sorveglianza della disponibilità e degli errori), l’alerting (segnalazione mirata), i backup, i processi di patch, nonché i runbook (manuali operativi per casi standard e guasti). Questo sforzo viene spesso rimandato nei progetti a „più tardi“, ma finisce per diventare lavoro frenetico di rifinitura nel team subito dopo il Go-live.

Pianificate lo sforzo operativo fin dall’inizio, in particolare quando:

• sono necessari più ambienti (Dev/Test/Prod) e questi devono essere mantenuti coerenti,
• la soluzione fornisce interfacce con processi critici,
• si discutono obiettivi di disponibilità o SLA (Service Level Agreements).

Modelli di budget che funzionano nella pratica

Il modello di budget appropriato dipende fortemente da quanto sono stabili i requisiti e le condizioni al contorno. In molte aziende la situazione è mista: i processi core sono chiari, i dettagli emergono durante il progetto. In questi casi sono utili modelli che consentano corridoi e fasi di apprendimento.

Prezzo fisso, Time & Material e prezzo obiettivo: dove si nascondono le insidie

Prezzo fisso funziona solo con una specifica chiara e condizioni di accettazione stabili. Altrimenti si trasferisce il rischio nei Change Request (richieste di modifica) e si generano conflitti su „si intendeva così“. Time & Material (fatturazione a consumo) è flessibile, ma richiede una forte governance: prioritizzazione, trasparenza sulla burn rate (consumo del budget per periodo) e decisioni Stop/Go chiare. Prezzo obiettivo è un modello intermedio: un budget target con un corridoio e una definizione della ripartizione del rischio, combinato con una misurazione trasparente dello stato di avanzamento.

Ciò che conta non è l’etichetta ma la governance: chi decide sulle variazioni di scope, come vengono valutati gli impatti e quali riserve sono previste a tal fine?

Pianificazione per fasi invece di „tutto in una volta“

Una pianificazione realistica distingue spesso tre livelli:

• Discovery/Scoping: chiarire processi, dati, integrazioni, rischi e visione obiettivo. Risultato: backlog affidabile, quadro architetturale di massima, corridoio di stima.
• Delivery in Inkrementen: consegnare funzionalità in pacchetti idonei per l’accettazione, test di integrazione precoci, prime approvazioni funzionali.
• Go-live e Hypercare: cambio controllato, stabilizzazione, trasferimento in gestione operativa, documentazione, configurazione del supporto.

Questa suddivisione riduce il rischio che grandi incertezze rimangano nascoste fino a poco prima del Go-live. Inoltre rende i budget più negoziabili, perché dopo la fase di Discovery potete decidere con maggiore fondatezza.

Pianificare riserve: il buffer non è trascuratezza, ma gestione del rischio

Il termine «Puffer» ha spesso una cattiva reputazione nel gergo di progetto. Meglio vederlo come riserve per rischi specificamente identificati. Le riserve sono efficaci quando sono (a) motivate, (b) vincolate allo scopo e (c) dotate di trigger: quando si attinge alla riserva, chi decide, come si interviene?

Fonti di riserva consolidate sono:

• Riserva di ambito per requisiti nuovi/varianti con una chiara gestione delle modifiche.
• Riserva di integrazione per problemi di interfaccia, allineamenti con terze parti, formati dati inattesi.
• Riserva di qualità per ritocchi nei test, problematiche di performance, stabilizzazione.
• Riserva per l’introduzione per formazione, rollout, capacità di supporto aggiuntiva nelle prime settimane.

Importante: le riserve non sono un assegno in bianco. Non sostituiscono la prioritizzazione. Un buon progetto può lasciare inutilizzata la riserva – oppure impiegarla in modo mirato per attenuare i rischi senza mettere a rischio la scadenza.

Come da un’idea approssimativa si arriva a una cifra attendibile: un processo pratico

Molte aziende hanno presto bisogno di un numero indicativo per budget e capacità. Allo stesso tempo all’inizio mancano dettagli. Questo si risolve se la stima viene concepita come un processo.

Fase 1: fissare per iscritto i confini del progetto e gli obiettivi esclusi

Annote su una pagina: obiettivi, obiettivi esclusi, sedi/unità organizzative interessate, processi critici, sistemi e interfacce. Gli «obiettivi esclusi» sono particolarmente efficaci contro lo scope creep (espansione graduale del perimetro).

Fase 2: creare una mappa di integrazione e dei dati

Non serve un diagramma architetturale perfetto. Ma una panoramica di quali sistemi forniscono dati, quali consumano dati e dove sono ancorate identità/autorizzazioni. Solo questa visione migliora in modo significativo la stima e il dialogo sui rischi, perché le dipendenze diventano visibili.

Fase 3: documentare le assunzioni e derivare un intervallo di stima

Per ogni epica più ampia (grande pacchetto di lavoro) definite le assunzioni: ambiente di test disponibile sì/no, qualità dei dati buona/media/scarsa, interfaccia stabile/da modificare, percorsi decisionali rapidi/lenti. Da ciò nasce un intervallo (ottimistico/realistico/pessimistico) invece di un singolo valore.

Fase 4: trattare i requisiti di qualità e operativi come „scope obbligatorio“

Monitoring, logging, backup, modello di ruoli, documentazione e trasferimento non sono extra opzionali. Se si includono questi temi nella pianificazione di base, offerte e aspettative interne diventano più confrontabili – e il go-live diventa più pianificabile.

Fase 5: un ritmo di controllo con punti decisionali

Pianificate punti fissi in cui decidere: quali funzionalità vanno nel prossimo incremento, quali rischi si sono modificati, quali riserve restano bloccate? Così evitate il classico caso in cui il budget viene discusso solo quando è già stato consumato.

Comunicazione tra IT e reparto: dove si decidono davvero i costi

La maggior parte dei costi aggiuntivi è alla fine conseguenza di decisioni: più varianti, più eccezioni, più casi speciali, accettazione posticipata, integrazioni aggiuntive. Queste decisioni raramente vengono prese «dagli sviluppatori», ma nascono dagli allineamenti tra reparto, IT e, se necessario, acquisti/Compliance.

Accordi utili per stabilizzare i costi:

• Definition of Ready: Quando un requisito è così chiaro da poter essere implementato (dati, ruoli, criteri di accettazione, data di collaudo)?

Questo è particolarmente importante per chi prende decisioni: le esplosioni di costo non sono spesso dovute a un «fornitore troppo caro», ma sono un sintomo della mancanza di processi decisionali e di accettazione.

Quando le stime di costo falliscono: modelli tipici e contromisure

„Partiamo in fretta e risolviamo il RESTo strada facendo“

Partire rapidamente ha senso se esiste un piano di apprendimento chiaro. Senza una fase di discovery si accumulano però debiti: dati poco chiari, interfacce instabili, requisiti operativi mancanti. Contromisura: timebox per lo scoping e un primo scenario end-to-end funzionante (dall’ingresso fino alla lavorazione, inclusi interfaccia e logging).

„Lo fa l’IT come attività secondaria“

„Come attività secondaria“ nella realtà significa: interruzioni, cambi di contesto, tempi di completamento prolungati. Per progetti critici per il business il collo di bottiglia è la capacità, non solo il budget. Contromisura: fasce orarie di concentrazione fisse e limiti WIP (Work in Progress: limitazione del lavoro parallelo), in modo da garantire capacità di consegna.

„Risparmiamo sui test e sulla documentazione“

Questo risparmia nel breve periodo, ma aumenta il rischio di guasti e l’onere del supporto. Diventa particolarmente costoso quando, dopo la messa in produzione, manca il know-how e la gestione degli incidenti richiede troppo tempo. Contromisura: definire standard minimi (ad es. un runbook per ogni processo chiave, monitoraggio per le interfacce, livelli di log chiari).

Conclusione: una pianificazione dei costi realistica significa rendere visibile l’incertezza

La risposta a „Quanto costa davvero un progetto software?“ raramente è un singolo numero. Una pianificazione realistica nasce quando IT e linee di business considerano alla pari l’ambito funzionale, la realtà delle integrazioni e i requisiti operativi. Buone stime forniscono corridoi, assunzioni documentate e una logica chiara per le riserve, invece di una precisione fittizia.

Se siete davanti a una decisione di budget, conviene investire pRESTo in scoping e chiarimenti su dati e integrazioni. Questo riduce il lavoro di rifacimento, stabilizza le scadenze e rende gestibili le riserve. Chi pianifica fin dall’inizio esercizio, test, migrazione e change ottiene non solo un budget più realistico, ma anche una soluzione sostenibile nella pratica quotidiana.

Se volete valutare in modo strutturato la vostra situazione di partenza e definire un quadro solido di costi e rischi per il vostro progetto software, possiamo chiarirlo insieme nel passo successivo: contattateci.

Per questo tema sono rilevanti anche i costi dei progetti software e il budget dei progetti IT. L’articolo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.

Discutere il progetto o l’iniziativa di modernizzazione con Net-Base.