SOW agile vs waterfall : quale struttura per i vostri progetti IT?

Introduzione : perché il modello di SOW condiziona il successo contrattuale

Nell'universo del consulting IT e dello sviluppo software, il Statement of Work (SOW) non è un semplice documento amministrativo : è la spina dorsale contrattuale che regola la relazione tra il fornitore e il suo cliente. Nel 2026, la quasi totalità dei progetti IT oscilla tra due filosofie radicalmente diverse — agile e waterfall — e questa distinzione ha repercussioni concrete sulla redazione di ogni clausola del SOW : deliverable, milestone, modalità di pagamento, criteri di accettazione e gestione delle modifiche. Comprendere la differenza tra un SOW agile e un SOW waterfall significa evitare i contenziosi contrattuali che costano in media il 15 % del budget del progetto secondo le indagini settoriali del PMI. Questo articolo dettaglia le strutture, i rischi e le buone pratiche per ciascun approccio.

---

Cos'è un SOW waterfall e come strutturarlo?

Il modello waterfall — o ciclo a V — si basa su una logica sequenziale : ogni fase (inquadramento, progettazione, sviluppo, test, implementazione) si sussegue in modo lineare. Un SOW waterfall riflette questa logica definendo a priori e in modo esaustivo l'intero perimetro.

Caratteristiche strutturali del SOW waterfall

Un SOW waterfall tipico comprende :

• Una descrizione dettagliata del perimetro funzionale : ogni funzionalità è descritta, spesso accompagnata da specifiche funzionali generali (SFG) o da un cahier des charges allegato.
• Milestone contrattuali fermi : consegna del mockup validato, collaudo funzionale, messa in produzione, periodo di garanzia. Ogni milestone è associato a una data di calendario e a una percentuale del forfait.
• Un prezzo globale forfettario (fixed-price) : la controprestazione finanziaria è determinata in anticipo. Il fornitore assume il rischio di sforamento se il perimetro non è ben calibrato.
• Criteri di accettazione precisi : le condizioni di validazione di ogni deliverable sono definite contrattualmente, riducendo i contenziosi al collaudo.

Vantaggi e limiti del SOW waterfall per i progetti IT

Il modello waterfall offre una prevedibilità budgetaria totale per il cliente, il che lo rende la scelta privilegiata per i progetti a perimetro stabile : integrazione ERP, migrazione di dati strutturati, sviluppo di un'applicazione le cui specifiche sono fissate. D'altro canto, si adatta male alle evoluzioni dei bisogni nel corso del progetto. Ogni modifica deve essere oggetto di una modifica contrattuale (Change Request), un processo spesso lento e fonte di tensione. Secondo i dati del Standish Group Chaos Report 2024, i progetti waterfall superano il budget iniziale nel 45 % dei casi, proprio a causa della sottostima del perimetro alla firma.

Per approfondire la redazione e la firma di questo tipo di documento, l'hub SOW di Certyneo centralizza modelli, clausole tipo e buone pratiche.

---

Cos'è un SOW agile e in che cosa differisce strutturalmente?

Il SOW agile rompe con la logica del perimetro fisso. Contrattualizz una capacità di consegna (velocità di un team, numero di sprint, profili messi a disposizione) piuttosto che una lista esaustiva di funzionalità.

I pilastri di un SOW agile : sprint, backlog e criteri di valore

Un SOW agile strutturato intorno a Scrum o Kanban integra tipicamente :

• Una descrizione dei ruoli e dei team : Product Owner da parte del cliente, Scrum Master e sviluppatori da parte del fornitore, con i tassi giornalieri o mensili associati (modello Time & Materials o forfait per sprint).
• Un backlog iniziale priorizzato : non contrattualmente fisso, ma che serve come base di partenza. Evolve ad ogni sprint review con l'accordo delle due parti.
• Sprint come unità di fatturazione : ogni sprint (2-4 settimane) costituisce un ciclo fatturabile, con le sue cerimonie agile definite (planning, daily, review, retrospettiva).
• Criteri di Definition of Done (DoD) : condizioni tecniche e funzionali che ogni story deve soddisfare per essere considerata consegnata, sostituendo i criteri di accettazione monolitici del waterfall.
• Una clausola di revisione budgetaria periodica : dopo N sprint, le parti possono revisionare il perimetro globale senza modifica formale, entro i limiti di un'enveloppe budgetaria globale definita.

Modelli di prezzo in un SOW agile : Time & Materials vs forfait per sprint

Due modelli coesistono nella pratica :

Time & Materials (T&M) : il cliente paga il tempo effettivamente consumato dai team, secondo i tassi giornalieri contrattualizzati. Questo modello massimizza la flessibilità ma trasferisce il rischio budgetario al cliente. È adatto ai progetti esplorativi o alle fasi di ideazione.

Forfait per sprint (Sprint Box) : il fornitore si impegna su una capacità di consegna fissa per sprint (numero di punti o giorni/uomo), per un prezzo fisso. Questo modello ibrido combina la prevedibilità finanziaria del waterfall con la flessibilità del backlog agile. È oggi il modello dominante nelle ESN francesi per i progetti di sviluppo web e mobile.

I modelli di contratti disponibili su Certyneo includono template SOW adatti a ciascuno di questi modelli di prezzo, pronti per essere personalizzati e firmati elettronicamente.

---

Tabella comparativa : SOW agile vs waterfall, le differenze chiave

| Criterio | SOW Waterfall | SOW Agile | |---|---|---| | Perimetro | Fisso ed esaustivo dalla firma | Evolutivo, gestito via backlog priorizzato | | Deliverable | Definiti contrattualmente e datati | Definiti per sprint, validati continuamente | | Milestone | Milestone fermi con date di calendario | Revisioni di sprint periodiche | | Prezzo | Forfait globale fisso | T&M o forfait per sprint | | Gestione dei cambiamenti | Modifica formale (Change Request) | Repriorizzazione del backlog | | Rischio budget | Fornitore (perimetro fisso) | Cliente (T&M) o condiviso (sprint box) | | Criteri di accettazione | Collaudo formale a milestone definiti | Definition of Done per story | | Ideale per | Perimetro stabile, vincoli normativi | Evoluzione continua, innovazione |

---

Come scegliere tra SOW agile e waterfall per il vostro progetto IT consulting?

Analizzare la stabilità del perimetro e la maturità del cliente

Il primo criterio di scelta è la stabilità del bisogno espresso. Se il cliente dispone di un cahier des charges validato, di wireframe finali e di una DSI capace di condurre un collaudo formale, il SOW waterfall minimizza il rischio contrattuale. D'altro canto, se il progetto è in fase di discovery, se i bisogni aziendali evolvono rapidamente o se il cliente desidera coinvolgere gli utenti finali nelle validazioni iterative, il SOW agile è strutturalmente più adatto.

Un indicatore concreto : se il cahier des charges iniziale supera l'80 % di stabilità funzionale stimata, optate per il waterfall. Al di sotto del 60 %, l'approccio agile ridurrà significativamente le modifiche e i sforamenti.

Tenere conto del contesto normativo e settoriale

Alcuni settori impongono vincoli che influenzano la scelta del modello di SOW. I progetti nel settore sanitario (certificazione HDS, hosting di dati sanitari), finanziario (conformità DORA, audit ISO 27001) o negli appalti pubblici (Codice della commande pubblica) richiedono spesso una tracciabilità documentale e una validazione formale dei deliverable più vicina al modello waterfall, anche se i metodi di sviluppo sono agili internamente.

In questo contesto ibrido, un SOW detto ScrumFall — o Agile at Scale — combina un perimetro macro contrattualmente fisso (fasi del progetto, budget globale) con un'esecuzione agile interna. Questo approccio è oggi ampiamente documentato nei framework SAFe (Scaled Agile Framework) e LeSS.

Proteggere la firma del SOW indipendentemente dal modello scelto

Indipendentemente dal modello scelto, il valore giuridico del SOW dipende dalla sua firma secondo le regole. In Francia, la firma elettronica avanzata o qualificata conforme al regolamento eIDAS garantisce il valore probante del documento in caso di contenzioso. Per le modifiche agile (repriorizzazioni formali, estensioni di sprint), la firma elettronica accelera considerevolmente i tempi di validazione : laddove una firma manoscritta richiede 3-7 giorni, una soluzione come Certyneo consente di completare la validazione in meno di 24 ore, senza spostamenti.

I team di consulting che gestiscono molti SOW simultaneamente possono affidarsi al generatore di contratti tramite IA di Certyneo per produrre SOW adatti a ogni contesto (agile, waterfall, ibrido) in pochi minuti, quindi inviarli alla firma in flusso integrato.

Quadro legale applicabile ai SOW in progetto IT e consulting

Lo Statement of Work è un contratto a sé stante, soggetto al diritto comune dei contratti e alle normative settoriali specifiche. In Francia, diversi testi regolano la sua redazione, validità ed esecuzione.

Codice civile e diritto dei contratti

Il SOW rientra in primo luogo nel Codice civile, e più precisamente nelle disposizioni derivanti dalla riforma del diritto dei contratti del 2016 (ordinanza n°2016-131, codificata agli articoli 1101 e seguenti). L'articolo 1194 del Codice civile ricorda che i contratti vincolano non solo a ciò che vi è espresso, ma anche a tutte le conseguenze che ne derivano secondo l'equità, l'uso o la legge — il che include le pratiche riconosciute del settore IT (Agile Manifesto, standard PMI/PMBOK).

L'articolo 1353 regola l'onere della prova in caso di contenzioso : in assenza di clausola contraria, spetta al fornitore provare che ha rispettato i suoi obblighi. Un SOW ben redatto, con criteri di accettazione precisi (DoD o milestone waterfall), inverte praticamente questo onere.

Firma elettronica e valore probante : eIDAS e Codice civile

La firma elettronica del SOW è regolata dal Regolamento europeo eIDAS n°910/2014, il cui articolo 25 dispone che la firma elettronica qualificata ha lo stesso valore giuridico di una firma manoscritta in tutti gli Stati membri. In Francia, gli articoli 1366 e 1367 del Codice civile recepiscono questo principio riconoscendo il valore probante dello scritto elettronico non appena l'autore può essere identificato con certezza e la sua integrità è garantita.

Per un SOW che impegna importi superiori a 1 500 € (soglia dell'articolo 1359 del Codice civile per l'obbligo di un documento scritto), la firma elettronica avanzata (livello 2 eIDAS) costituisce il minimo consigliato. Per progetti sensibili o pluriennali, la firma qualificata (livello 3) con certificato rilasciato da un Prestatore di Servizi di Fiducia (PSC) qualificato ai sensi dell'allegato II del regolamento eIDAS s'impone.

Protezione dei dati e RGPD nei progetti IT

Ogni SOW che includa trattamenti di dati personali deve integrare una clausola di subaffidatario conforme all'articolo 28 del RGPD n°2016/679. Questa clausola deve dettagliare : la natura e la finalità dei trattamenti, le categorie di dati interessate, gli obblighi del subaffidatario (il fornitore IT), le misure di sicurezza tecniche e organizzative, e le condizioni di restituzione o distruzione dei dati al termine del progetto.

Nei progetti agile, dove i perimetri evolvono, è consigliato allegare al SOW un registro dei trattamenti previsionale aggiornato a ogni sprint importante, conformemente alle raccomandazioni del Garante della privacy.

Commande pubblica e vincoli settoriali

Per i SOW conclusi nell'ambito di appalti pubblici, il Codice della commande pubblica (CCP) impone regole specifiche in materia di contenuto, modifica (articoli L.2194-1 e seguenti) e risoluzione delle controversie. Le modifiche agile devono rimanere entro le soglie autorizzate (generalmente 10-15 % dell'importo iniziale) per non costituire un nuovo appalto soggetto a messa in concorrenza.

Scenari d'uso : SOW agile vs waterfall nella pratica

Scenario 1 — ESN di medie dimensioni, progetto di refactoring ERP (modello waterfall)

Un'ESN di circa 150 consulenti vince una gara d'appalto per il refactoring del sistema ERP di un gruppo industriale. Il perimetro funzionale è definito in un cahier des charges di 120 pagine, validato dalla DSI cliente. Il budget è di 480 000 € IVA inclusa, strutturato in 5 milestone contrattuali su 18 mesi.

Il SOW waterfall firmato elettronicamente tramite una soluzione conforme eIDAS definisce : le specifiche funzionali in allegato, i deliverable previsti a ogni milestone (dossier di progettazione, ambiente di collaudo, verbale di messa in produzione), i criteri di accettazione precisi e le penalità di ritardo. Grazie a questo livello di dettaglio, il collaudo finale è completato con soli 3 rilievi minori. La firma elettronica dei 7 avanzamenti Change Request intervenuti nel corso del progetto ha ridotto i tempi di validazione da 5 giorni lavorativi a 18 ore in media, ossia un'economia stimata di 12 000 € di costi di coordinamento.

Scenario 2 — Startup SaaS e squad esterna in modello agile (Sprint Box)

Una startup B2B in fase di scale-up recluta una squad esterna di 5 persone (2 sviluppatori fullstack, 1 designer UX, 1 QA, 1 Scrum Master) per accelerare lo sviluppo della sua piattaforma. Poiché il perimetro è esplorativo e la product roadmap evolve ogni mese, un SOW waterfall sarebbe inadatto.

Il SOW agile firmato contrattualizz : i profili e i tassi giornalieri, la durata degli sprint (2 settimane), il budget massimo per trimestre (plafond T&M di 85 000 € per trimestre), la Definition of Done applicabile a tutte le story, e le condizioni di revisione del backlog. Dopo 6 mesi, la startup ha consegnato 3 volte più funzionalità rispetto a quanto inizialmente stimato, con uno sforamento budgetario di solo l'8 % rispetto all'enveloppe globale — performance impossibile con un modello waterfall data le 23 repriorizzazioni maggiori del backlog intervenute.

Scenario 3 — Cabinet di consulenza in trasformazione digitale, approccio ibrido ScrumFall

Un cabinet di consulenza accompagna un'organizzazione di formazione nella migrazione del suo LMS verso una piattaforma cloud. Il progetto è vincolato da obblighi normativi Qualiopi (tracciabilità dei percorsi, accessibilità RGAA) che impongono una validazione formale, ma i percorsi pedagogici stessi devono essere co-costruiti con i formatori in modo iterativo.

La soluzione scelta è un SOW ibrido : un perimetro macro waterfall (4 fasi contrattuali con milestone fermi e importi forfettari) che incornicia un'esecuzione agile interna (sprint bisettimanali, revisioni con i formatori). I deliverable formali (dossier tecnico Qualiopi, verbale di collaudo di accessibilità) sono contrattualizzati nei milestone, mentre i contenuti pedagogici sono gestiti tramite un backlog agile. Questo modello ha consentito di ridurre del 35 % il numero di modifiche formali rispetto a un progetto LMS simile condotto in puro waterfall l'anno precedente.

Conclusioni

La scelta tra un SOW agile e un SOW waterfall non è una questione di preferenza metodologica : è una decisione contrattuale strutturante che determina la ripartizione dei rischi, la gestione delle modifiche e il valore probante dei vostri impegni in caso di contenzioso. Il waterfall eccelle sui perimetri stabili e sui progetti con forti vincoli normativi ; l'agile massimizza il valore sui progetti evolutivi e innovativi. Il modello ibrido ScrumFall risponde ai contesti intermedi, sempre più frequenti nel consulting IT nel 2026.

Indipendentemente dal modello scelto, la protezione giuridica del SOW passa attraverso una firma elettronica conforme eIDAS. Certyneo vi consente di generare, personalizzare e far firmare i vostri SOW in pochi minuti, con un valore probante riconosciuto in tutta l'Unione europea.

👉 Provate Certyneo gratuitamente e firmate il vostro primo SOW in meno di 10 minuti.