Rischi di un progetto su misura, come tenere fermi budget e tempi
Che cosa fa saltare costi e date, quale modello di prezzo scegliere e che cosa scrivere nel contratto perché una modifica non diventi una lite.
Quali sono i rischi di un progetto su misura?
Costi oltre il budget, consegne in ritardo, perimetro che cresce, liti su che cosa era compreso, dipendenza dal fornitore, difetti, software che nessuno usa e dati esposti. Quasi tutti nascono prima della prima riga di codice: da un requisito che nessuno ha scritto, da una modifica che nessuno ha approvato, da un contratto che non dice chi paga.
| Rischio | Da dove nasce | Come si riduce |
|---|---|---|
| Costi oltre il budget | un prezzo fissato prima di aver deciso che cosa si compra | un perimetro scritto e un massimo nel contratto |
| Consegna in ritardo | date scelte per vincere la trattativa, ritardi scoperti alla consegna | milestone realistiche e un avviso appena una data è a rischio |
| Perimetro che cresce | richieste aggiunte strada facendo, senza una stima | ogni modifica valutata e approvata prima di svilupparla |
| Lite su che cosa era compreso | un preventivo generico, senza esclusioni | requisiti con criteri di accettazione ed esclusioni scritte |
| Dipendenza dal fornitore | codice, accessi e documentazione che restano a lui | la cessione del codice scritta nel contratto, con accessi e documentazione |
| Difetti dopo il rilascio | un collaudo fatto in fretta, senza criteri | test fatti insieme prima del rilascio e difetti segnalati nei termini |
| Software che nessuno usa | requisiti decisi a tavolino, senza chi lo userà | rilasciare per primo il punto che fa più male |
| Dati esposti | la sicurezza aggiunta alla fine | la sicurezza progettata dall'inizio, con accessi per ruolo |
La maggior parte di questi rischi si riduce prima della firma, con un'analisi che trasforma le richieste in un perimetro scritto. Il resto della guida dice come: quale modello di prezzo scegliere, chi paga una modifica, che cosa scrivere nel contratto, come si tengono fermi i tempi e che cosa succede quando qualcosa va storto.
Perché budget e tempi saltano?
Perché si fissa un prezzo, o una data, su un lavoro che nessuno ha ancora descritto abbastanza. Ogni requisito non scritto diventa, a metà progetto, una richiesta di modifica. La guida del governo britannico sui contratti per lo sviluppo agile lo dice per gli acquisti pubblici: una specifica imperfetta porta a richieste di modifica e a sforamenti che emergono tardi.
Il fenomeno è misurato. McKinsey, con l'Università di Oxford, ha studiato più di 5.400 progetti informatici. Nei grandi progetti, quelli con un prezzo iniziale sopra i 15 milioni di dollari, la spesa supera il budget in media del 45% e i tempi del 7%, e il valore consegnato è inferiore del 56% al previsto. I progetti di software sono quelli con il rischio più alto, e ogni anno in più di durata fa crescere lo sforamento del 15%. Sono progetti molto più grandi di un gestionale per una PMI, ma il meccanismo è lo stesso: più il lavoro è lungo e indefinito, più si allontana dalla stima.
Anche la media inganna. Nello studio su 1.471 progetti informatici pubblicato da Harvard Business Review lo sforamento medio era del 27%, ma un progetto su sei sforava in media del 200%: lo raccontiamo nella guida sui costi, con le nostre cifre.
Sforamento dei costi nei progetti informatici
% oltre il budgetSu 1.471 progetti informatici. Fonte: Bent Flyvbjerg e Alexander Budzier, «Why Your IT Project May Be Riskier than You Think», Harvard Business Review, settembre 2011
Il rimedio è decidere prima di firmare. Da noi l'analisi che porta al preventivo è gratuita per un progetto di media complessità. Per un progetto complesso o con tempi stretti facciamo uno studio di fattibilità: dura da 1 a 2 settimane, costa fino a 2.500 € e, se firmi, si scala dal progetto.
Prezzo fisso o a consuntivo: che cosa conviene?
Il prezzo fisso conviene solo se il perimetro è scritto; il consuntivo conviene per un lavoro breve ed esplorativo, perché ti lascia tutto il rischio della stima. Fra i due ci sono modelli con un limite di spesa, e non sono uguali.
A consuntivo, o time and material, paghi le ore o le giornate lavorate a una tariffa concordata. A prezzo fisso, o a corpo, paghi una cifra per un perimetro. Con un tetto paghi a consuntivo fino a una soglia di spesa. Con forchetta e massimo il preventivo dà una forchetta e il massimo è scritto nel contratto. A capacity riservi in anticipo tempo del team.
| Modello | Che cosa fissi | Chi porta il rischio della stima | Quando ha senso |
|---|---|---|---|
| A consuntivo | la tariffa | tu | lavoro breve ed esplorativo, seguito da vicino |
| A consuntivo con tetto | la tariffa e una spesa massima | tu, fino al tetto | una fase di esplorazione con un budget dato |
| Prezzo fisso senza perimetro scritto | una cifra | sulla carta il fornitore, nei fatti si tratta | da evitare |
| Prezzo fisso con perimetro scritto | una cifra per una lista di funzioni | il fornitore | un lavoro piccolo e già deciso |
| A progetto, con forchetta e massimo | una forchetta, con il massimo nel contratto | il fornitore, se i requisiti non cambiano | un progetto con il perimetro chiaro dopo l'analisi |
| A capacity | tempo del team riservato | tu, che decidi le priorità | picchi di lavoro o specifiche ancora in movimento |
La differenza fra tetto e massimo è quella che conta. Il tetto, se il contratto non dice altro, limita la spesa e non la consegna: arrivati al tetto il lavoro si ferma, finito o no. Il massimo della forchetta è il prezzo del perimetro concordato. Se i requisiti iniziali non cambiano, il prezzo si ferma al massimo della forchetta e l'eccedenza la assorbiamo noi.
Il consuntivo puro ha un difetto che segnala anche la guida britannica: può spingere il fornitore a vendere tempo invece del risultato, e il rischio della qualità resta a chi compra. La stessa guida lo indica per la fase di esplorazione, prima di passare a un modello più strutturato. Noi lavoriamo a progetto se perimetro e tempi sono chiari, a capacity se non lo sono ancora.
Preferisci parlarne a voce?
Prenota una call con chi lavora ogni giorno su questi temi: guardiamo insieme il tuo caso.
Chi paga una modifica chiesta a metà progetto?
La paga chi l'ha chiesta, se il contratto non dice altro: tu, per le modifiche che chiedi, anche a prezzo globale (articolo 1661); il fornitore, per quelle che fa di sua iniziativa (articolo 1659). Vale per l'appalto, cioè quando il fornitore lavora con una sua organizzazione di mezzi e a proprio rischio (articolo 1655 del Codice civile). È invece un contratto d'opera quando lavora con un lavoro prevalentemente proprio, come un professionista da solo (articolo 2222); quale dei due, si guarda caso per caso. Per l'appalto il Codice civile distingue tre casi.
| Chi chiede la modifica | Che cosa dice il Codice civile | Chi la paga, se il prezzo è globale |
|---|---|---|
| Il fornitore, di sua iniziativa | non può farla senza la tua autorizzazione, che si prova per iscritto (articolo 1659) | il fornitore: anche autorizzata, non gli dà diritto a un compenso, salvo patto diverso |
| Nessuno, ma serve a fare il lavoro a regola d'arte | se non vi accordate, variazioni e prezzo li decide il giudice; oltre un sesto del prezzo il fornitore può recedere (articolo 1660) | il prezzo si ridetermina |
| Tu | puoi chiederla fino a un sesto del prezzo complessivo (articolo 1661) | tu: il fornitore ha diritto al compenso per i lavori in più, anche a prezzo globale |
Due conseguenze pratiche. La prima: conta chi ha chiesto la modifica, e lo decide la prova scritta, cioè email, verbali, richieste firmate. La seconda: il limite di un sesto riguarda il tuo potere di imporre le modifiche; oltre, il fornitore non è obbligato ad accettarle, e serve un nuovo accordo.
Il contratto può regolare le modifiche in un altro modo, e l'articolo 1659 lo dice espressamente («salvo diversa pattuizione»): per questo la procedura va scritta. Da noi si apre una richiesta di modifica, valutiamo insieme l'impatto e decidi tu. Se la modifica resta nel perimetro concordato il costo non cambia; se lo supera, lo sai prima di decidere. Nulla viene sviluppato, e nulla viene fatturato, senza la tua approvazione.
Un contributo tecnico
Norme e sentenze sono riassunte dalle fonti elencate in fondo, lette alla data in testa alla pagina. Come le altre guide, questa è un contributo tecnico, non un parere legale; un contratto importante fallo leggere al tuo avvocato.
Un esempio: un gestionale a prezzo fisso che chiede 15.000 € in più
Il caso è inventato, ed è una delle domande che abbiamo posto ai motori di ricerca per scrivere questa guida. Un'azienda firma un preventivo a prezzo fisso di 40.000 € per un gestionale su misura. A metà progetto il fornitore chiede altri 15.000 €, perché alcune richieste erano fuori perimetro, e sposta la consegna di due mesi. Chi ha ragione?
Nessuno dei due, in automatico. Si guarda richiesta per richiesta.
| Richiesta | Esempio | Chi paga |
|---|---|---|
| Compresa nel perimetro, ma stimata male | un report che il capitolato elenca | il fornitore, che nell'appalto lavora a proprio rischio (articolo 1655) |
| Ambigua, perché il capitolato la descrive in modo vago | «gestione degli ordini», senza dire quali | si tratta, sulla base di email, verbali e prototipi approvati |
| Nuova, chiesta da te | un collegamento al magazzino che il capitolato non prevede | tu, per i lavori in più (articolo 1661) |
| Nuova, decisa dal fornitore senza la tua autorizzazione scritta | una parte rifatta che nessuno ha chiesto | il fornitore (articolo 1659) |
Poi, in quest'ordine:
- Non firmare e non pagare l'extra subito. Chiedi la scomposizione voce per voce: la richiesta originale, quella nuova, il costo e l'effetto sulle date.
- Separa prezzo e ritardo. I due mesi si giustificano solo con le richieste nuove; le altre non spostano la data.
- Fai il conto del sesto. Un sesto di 40.000 € è circa 6.667 €: richieste nuove per 15.000 € sono più del doppio, quindi non sono modifiche che potevi imporre, ma un nuovo accordo. Se un accordo scritto non c'è, è il primo punto da chiarire.
- Proponi una fase 2. Le richieste nuove che non servono subito si spostano dopo il rilascio, con un preventivo a parte.
- Prima di sospendere i pagamenti o di contestare per iscritto, fai leggere contratto e allegati a un avvocato.
Si poteva evitare con un perimetro scritto con le esclusioni, una procedura che fa conoscere il costo di una modifica prima di svilupparla e un avviso sul ritardo appena diventa probabile. Da noi una richiesta fuori perimetro la conosci con il suo costo e la sua data prima di decidere, non dopo che è stata sviluppata.
Che cosa deve dire il contratto?
Che cosa è compreso e che cosa no, come si collauda e come si approva una modifica. Poi come si paga, di chi è il codice, che cosa succede se una data salta, che cosa copre la garanzia e come si esce. Il prezzo è una riga; il resto del contratto decide che cosa succede quando il progetto cambia, cioè quasi sempre.
| Clausola | Che cosa scrive | Il rischio che copre |
|---|---|---|
| Perimetro | funzioni, utenti e ruoli, integrazioni, e che cosa è escluso | la lite su che cosa era compreso |
| Accettazione | come si collauda, con quali prove, entro quando | il difetto scoperto quando è tardi |
| Modifiche | richiesta scritta, stima di costo e tempi, approvazione prima di sviluppare e di fatturare | lo sforamento a sorpresa |
| Prezzo | la forchetta con il massimo, o il tetto, e che cosa succede quando si raggiunge | la spesa senza limite |
| Pagamenti | milestone legate a software funzionante, saldo dopo l'accettazione | pagare lavoro che non vedi |
| Codice | la cessione scritta, milestone per milestone, con accessi e documentazione | la dipendenza dal fornitore |
| Ritardi | un avviso appena una data è a rischio, con una proposta di ripianificazione | il ritardo scoperto alla consegna |
| Garanzia | che cosa copre e per quanto, separando difetti e nuove funzioni | la lite su che cosa è un difetto |
| Uscita | recesso, preavviso, consegna di codice e dati | restare legato a un fornitore che non va |
Le penali per ritardo compaiono in quasi tutte le risposte che i motori generativi danno a questa domanda, con cifre diverse fra loro. Due cose da sapere. Il fornitore risponde del ritardo anche senza penale, se non prova che il ritardo viene da una causa che non gli è imputabile (articolo 1218, come spiega Canella Camaiora). E una penale, se il contratto non prevede anche il danno ulteriore, limita il risarcimento alla cifra pattuita (articolo 1382): una penale bassa può proteggere più il fornitore di te. Se una data conta davvero per la tua azienda, scrivi perché, e che cosa succede se salta.
Da noi si paga a milestone: un acconto alla firma dal 25% al 35%, pagamenti legati alle fasi e il saldo dopo la sessione di accettazione. Ogni milestone pagata ti trasferisce la proprietà della parte di progetto che copre, come spiega la guida sui costi nella sezione Come si paga, e quando il codice diventa tuo.
Che cosa farsi consegnare, e che cosa dice la legge sul codice scritto da un fornitore, è nella guida Come scegliere una software house. Una sentenza recente va nella direzione di chi commissiona. Il 24 giugno 2025 il Tribunale di Venezia ha applicato per analogia al software commissionato in appalto la regola del software scritto dai dipendenti, dando i diritti economici al cliente. Ha anche ordinato in via cautelare la consegna dei codici sorgente, perché senza il cliente non poteva affidare la manutenzione ad altri. Resta una decisione di un tribunale, non una regola: la cessione va scritta comunque.
Come si tengono fermi i tempi?
Con date che nascono dall'analisi, consegne frequenti e una persona della tua azienda che decide. Le date nascono da un'analisi rigorosa di perimetro, tempi e figure necessarie, e preferiamo perdere una trattativa in fase di stima che mancare una scadenza inventata per vincerla.
- Le consegne sono incrementali e vedi software funzionante lungo tutto il percorso: un progetto tipico dura in media circa quattro mesi, e non li passi al buio.
- Si rilascia per primo il punto che fa più male, e le priorità successive le decide l'uso reale invece di un'ipotesi fatta a tavolino. Una fase breve si stima meglio di un progetto lungo, ed è quello che dice anche il dato di McKinsey sulla durata.
- Da parte tua serve qualcuno che conosce il processo e può rispondere in giorni, non in settimane: una domanda che aspetta è un ritardo, anche se non è del fornitore.
- Se un ritardo diventa probabile lo sai subito, con una proposta di ripianificazione, non il giorno della consegna. E se una scadenza ci sembra impossibile, proponiamo un perimetro più piccolo o una data diversa.
Che cosa succede se il software ha difetti, o se vuoi fermarti?
Un difetto va denunciato entro 60 giorni dalla scoperta in un appalto, entro 8 in un contratto d'opera, e puoi chiedere che il fornitore lo elimini a sue spese. Se vuoi fermarti, puoi recedere in ogni momento pagando spese, lavoro fatto e mancato guadagno. I termini per i difetti sono questi.
| Regola | Appalto | Contratto d'opera |
|---|---|---|
| Denuncia del difetto | entro 60 giorni dalla scoperta (articolo 1667) | entro 8 giorni dalla scoperta (articolo 2226) |
| Azione contro il fornitore | entro 2 anni dalla consegna | entro 1 anno dalla consegna |
| Difetti noti all'accettazione | non coperti, se li conoscevi o erano riconoscibili | non coperti, se li conoscevi o erano facilmente riconoscibili |
| Che cosa puoi chiedere | l'eliminazione a spese del fornitore o una riduzione del prezzo; la risoluzione se il software è del tutto inadatto (articolo 1668) | lo stesso, perché l'articolo 2226 rinvia al 1668 |
Il collaudo quindi non è una formalità: un difetto che vedi e non segnali quando accetti il software non è più coperto. E se salti i test o cambi le richieste senza tracciarle, Canella Camaiora ricorda che il giudice può vederci un concorso di colpa (articolo 1227), che riduce il risarcimento. Da noi il controllo qualità prima del rilascio coinvolge entrambe le parti, e nella garanzia dopo il rilascio la regola è netta: i bug sono coperti dalla garanzia, le nuove funzionalità si quotano.
Puoi anche fermare il progetto in ogni momento, a lavori iniziati, tenendo indenne il fornitore delle spese, del lavoro fatto e del mancato guadagno (articolo 1671). Il mancato guadagno può pesare: per questo conviene che il contratto dica come si esce, con quale preavviso e che cosa ti viene consegnato. Con la proprietà trasferita a ogni milestone, se cambi fornitore il codice pagato è già tuo.
Fonti e approfondimenti
- Codice civile, articolo 1655, nozione di appaltobrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 1659, variazioni concordate del progettobrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 1660, variazioni necessarie del progettobrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 1661, variazioni ordinate dal committentebrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 1667, difformità e vizi dell'operabrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 1668, contenuto della garanzia per difetti dell'operabrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 1671, recesso unilaterale dal contrattobrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 2222, contratto d'operabrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 2226, difformità e vizi nel contratto d'operabrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 1382, effetti della clausola penalebrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 1218, responsabilità del debitorebrocardi.it, consultato il 24 ottobre 2026
- Codice civile, articolo 1227, concorso del fatto colposo del creditorebrocardi.it, consultato il 24 ottobre 2026
- Tribunale di Venezia, 24 giugno 2025, «Software commissionato in appalto: titolarità del committente e consegna cautelare dei codici sorgente», Giurisprudenza delle impresegiurisprudenzadelleimprese.it, consultato il 24 ottobre 2026
- Margherita Manca, «La software house è responsabile se il software “su misura” non funziona?», Canella Camaiora, 18 giugno 2025canellacamaiora.it, consultato il 24 ottobre 2026
- CGF Legal, «Contratto di sviluppo del software: tutele e garanzie», aggiornato il 12 febbraio 2026cgflegal.it, consultato il 24 ottobre 2026
- Michael Bloch, Sven Blumberg e Jürgen Laartz, «Delivering large-scale IT projects on time, on budget, and on value», McKinsey, ottobre 2012mckinsey.com, consultato il 24 ottobre 2026
- Bent Flyvbjerg e Alexander Budzier, «Why Your IT Project May Be Riskier than You Think», Harvard Business Review, settembre 2011arxiv.org, consultato il 24 ottobre 2026
- Cabinet Office del Regno Unito, «Contracting for Agile Guidance Note», aggiornata il 20 giugno 2023gov.uk, consultato il 24 ottobre 2026
Meglio prezzo fisso o time and material?
Prezzo fisso se perimetro e requisiti sono scritti, time and material se il lavoro è ancora da esplorare, e allora con un tetto di spesa. Il prezzo fisso ti protegge solo se dice anche che cosa è escluso; il time and material ti lascia il rischio della stima. Noi lavoriamo a progetto, con una forchetta e il massimo scritto nel contratto, oppure a capacity quando le specifiche sono ancora in movimento.
Il fornitore può chiedere più soldi su un progetto a prezzo fisso?
Sì, ma per le modifiche che hai chiesto tu, non per una sua stima sbagliata. Il Codice civile gli riconosce un compenso per le variazioni ordinate dal committente anche a prezzo globale (articolo 1661), non per quelle decise da lui (articolo 1659). Per questo conta la prova scritta di chi ha chiesto che cosa.
Che cos'è una richiesta di modifica?
È la richiesta scritta di cambiare qualcosa rispetto al perimetro concordato. Chi la riceve stima l'effetto su costi e tempi, e chi compra decide se farla subito, cambiare le priorità o rimandarla. Da noi nulla viene sviluppato, e nulla viene fatturato, senza la tua approvazione.
Che cosa succede se il costo supera la stima?
Da noi non succede. Se i requisiti iniziali non cambiano, il prezzo si ferma al massimo della forchetta, già scritto nel contratto, e l'eccedenza la assorbiamo noi. Se cambiano, l'impatto su costi e tempi lo conosci prima di decidere.
Entro quanto devo segnalare un difetto del software?
In un appalto entro 60 giorni dalla scoperta, e l'azione contro il fornitore si prescrive in 2 anni dalla consegna (articolo 1667 del Codice civile). In un contratto d'opera, con un professionista, i termini sono 8 giorni e 1 anno (articolo 2226). Un difetto che conoscevi, o che era riconoscibile, quando hai accettato il software non è coperto.
Posso interrompere un progetto software a metà?
Sì. Chi commissiona può recedere in ogni momento, anche a lavori iniziati, pagando al fornitore le spese, il lavoro fatto e il mancato guadagno (articolo 1671 del Codice civile). Il contratto può dire come si esce e che cosa ti viene consegnato; con la proprietà trasferita a ogni milestone pagata, il codice già pagato resta tuo.
Un progetto su misura con il prezzo sotto controllo?
Raccontaci che cosa ti serve. Dopo l'analisi ricevi il perimetro con le esclusioni e una forchetta con il massimo scritto nel contratto, non una cifra al volo.
- Non parli con un commerciale
- NDA prima di entrare nel merito
- Il codice resta di tua proprietà
Articoli sugli stessi temi.
Data quality: decidono i dati o il modello?
Quando l'AI sbaglia, la colpa è quasi sempre dei dati, non del modello. Come identificare, sanificare e aggiornare le tue fonti perché l'AI funzioni davvero.
Leggi
Small is the new big: SLM per l'enterprise
L'AI enterprise non richiede modelli giganti. Scopri come gli Small Language Models (SLM) riducono i costi di inferenza e garantiscono la privacy dei dati.
Leggi
Agenti AI: ciclo di sviluppo
Gartner prevede AI Agent nel 40% delle app Enterprise entro il 2026, ma solo l'11% delle aziende li ha in produzione. Tre pattern architetturali per arrivarci.
Leggi