Statement of Work: Cos'è e Come Scriverne Uno

Hai vinto il contratto. Tre settimane dopo l'inizio del lavoro, il cliente chiede un secondo giro di design che non hai mai preventivato, e il progetto che avevi stimato in quattro settimane sta silenziosamente slittando a sei. Il statement of work è il documento che impedisce tutto questo. Questa guida spiega cos'è un statement of work, le nove parti che ogni buon documento dovrebbe includere, un esempio compilato e come scriverne uno che regga quando il lavoro si complica.

Un statement of work, o SOW, è un documento che definisce il lavoro in un progetto o in un rapporto di servizio: i deliverable, la tempistica, i termini di pagamento e i criteri di accettazione, oltre a ciò che è esplicitamente fuori scope. Trasforma un accordo in fase di proposta in un documento preciso e firmabile a cui entrambe le parti possono fare riferimento. Il contratto stabilisce il rapporto legale. Il SOW stabilisce il lavoro.

Cos'è un statement of work?

Un statement of work è il documento che un fornitore di servizi e un cliente firmano per concordare esattamente cosa verrà fatto, entro quando, a quale costo e come tutti sapranno quando è finito. I SOW sono più comuni in agenzie, società di consulenza, servizi professionali, IT e costruzioni: ovunque un'azienda consegni un lavoro definito a un'altra.

È il ponte tra la vendita e l'esecuzione. La proposta diceva cosa potevi fare. Il SOW dice cosa farai, con abbastanza dettaglio da non lasciare spazio a interpretazioni successive.

Quel dettaglio è fondamentale. Lo scope creep non è raro: uno studio PMI ha rilevato che il 52% dei progetti ne è affetto, rispetto al 43% di cinque anni prima. Un SOW è l'assicurazione più economica che tu possa sottoscrivere contro questo rischio, perché il lavoro scritto e firmato è un lavoro che nessuno può espandere silenziosamente.

Statement of work vs scope of work, MSA e contratto

Questi quattro termini vengono usati come se significassero la stessa cosa. Non è così.

• Scope of work è una sezione all'interno del statement of work: la descrizione del lavoro effettivo. Spesso si dice "scope of work" intendendo l'intero SOW, ma tecnicamente lo scope è il "cosa" e il SOW è il documento che lo racchiude con tempistiche, pagamenti e accettazione.
• Master service agreement (MSA) è il contratto legale quadro che regola l'intera relazione: responsabilità, riservatezza, termini di pagamento, risoluzione delle controversie. Molti contratti di servizio si basano su un unico MSA e poi su un SOW separato per ogni incarico, in modo che i termini legali vengano concordati una sola volta e cambi solo il lavoro.
• Contratto è l'accordo legale vincolante. Un SOW firmato di solito è un contratto, o ne fa parte. Se stai confrontando i documenti tra loro, la differenza tra una proposta e un contratto è una lettura di approfondimento utile.

Se vuoi conoscere l'origine: il SOW viene dagli appalti pubblici, dove si distingue da un Performance Work Statement e da uno Statement of Objectives. Per il lavoro commerciale raramente hai bisogno di questa distinzione. Hai bisogno che il lavoro sia scritto chiaramente e firmato.

Le 9 parti di un statement of work

La maggior parte dei team sa che dovrebbe documentare lo scope e non lo fa. In un sondaggio di settore, solo circa la metà delle organizzazioni ha dichiarato di creare "per lo più" o "sempre" un documento di scoping durante la pianificazione. Ecco la struttura che rende tutto più rapido. Trattala come uno scheletro da riempire, non come una pagina bianca su cui fissarsi.

1. Background e obiettivi. Perché esiste questo progetto e quale risultato si propone di raggiungere. Come deve essere: un breve paragrafo che un nuovo membro del team possa leggere e capire il senso del lavoro.
2. Scope of work. Il lavoro specifico, scritto come attività concrete. Come deve essere: verbi e sostantivi, non aggettivi. "Progettare cinque landing page," non "realizzare un'ottima presenza web."
3. Deliverable. Le cose tangibili che consegni, ognuna definita. Come deve essere: formato e quantità specificati, ad esempio "cinque design di pagina consegnati come file Figma."
4. Fuori scope. Cosa non farai esplicitamente. Come deve essere: questa è la sezione che salva il progetto. Nomina le richieste adiacenti più ovvie (revisioni extra, copywriting, hosting) ed escludile per iscritto.
5. Tempistica e milestone. Date e punti di controllo. Come deve essere: milestone collegate ai deliverable, in modo che i progressi siano visibili e non siano solo una questione di calendario.
6. Piano dei pagamenti. Importi, trigger e termini. Come deve essere: pagamenti legati alle milestone o all'accettazione, non solo alle date, in modo che ricevere il pagamento sia legato all'approvazione del lavoro.
7. Criteri di accettazione. Come si stabilisce che un deliverable è completato. Come deve essere: oggettivo e verificabile, in modo che "finito" sia un fatto, non una discussione.
8. Assunzioni e dipendenze. Su cosa stai facendo affidamento da parte del cliente: accessi, contenuti, approvazioni tempestive. Come deve essere: nomina i compiti del cliente, in modo che un ritardo causato dal cliente sia attribuibile al cliente.
9. Gestione delle modifiche. Come viene richiesta, valutata economicamente e approvata una modifica allo scope. Come deve essere: un breve processo scritto, firmato nello stesso modo in cui è stato firmato il SOW originale. È questo che trasforma un "potresti anche solo..." in una modifica rapida e pagata, invece di un pomeriggio gratuito.

Un esempio di statement of work

Ecco lo scheletro compilato per un piccolo incarico di sviluppo sito web, ridotto per mostrarne la struttura.

Progetto: Redesign del sito marketing per Northwind Co.
Obiettivi: Sostituire l'attuale sito di cinque pagine con un sito più veloce e coerente con il brand, che supporti la lead capture.
Scope of work: Progettare e sviluppare cinque pagine (home, prodotto, prezzi, chi siamo, contatti). Migrare i testi esistenti. Configurare un form lead collegato al CRM del cliente.
Deliverable: Cinque design di pagina (Figma), un sito sviluppato sul CMS del cliente, un form lead collegato.
Fuori scope: Nuovo copywriting, migrazione del blog, hosting continuativo, attività SEO, più di due cicli di revisione del design.
Tempistica: Kickoff settimana 1, design settimana 3, sviluppo settimane 4-5, lancio settimana 6.
Pagamento: 50% alla firma, 50% all'accettazione del lancio. Pagamento a 14 giorni.
Accettazione: Ogni pagina corrisponde al design approvato e si carica in meno di due secondi con una connessione standard.
Assunzioni: Il cliente fornisce credenziali di accesso, asset del brand e testi entro la fine della settimana 1.
Gestione delle modifiche: Qualsiasi nuova richiesta viene valutata, quotata e aggiunta come modifica firmata prima dell'inizio del lavoro.

Nota come le sezioni "fuori scope" e "accettazione" svolgano gran parte del lavoro di protezione. Sono la differenza tra un progetto che si conclude e uno che deriva senza meta.

Come scrivere un statement of work, passo dopo passo

1. Parti da ciò che hai già concordato. Prendi scope, prezzo e tempistica dalla proposta o dal preventivo. Non reinventare termini che hai già venduto.
2. Scrivi lo scope come attività, poi scrivi cosa è fuori scope. Le esclusioni non sono scortesi. Sono il regalo più chiaro che tu possa fare a un cliente, perché stabiliscono aspettative oneste.
3. Definisci ogni deliverable con i suoi criteri di accettazione. Abbina ogni "consegneremo X" con "X è completato quando Y." Questa singola abitudine previene la maggior parte delle controversie a fine progetto.
4. Collega le milestone ai pagamenti. Associa ogni pagamento a una milestone o a un deliverable accettato, in modo che il flusso di cassa segua l'avanzamento.
5. Aggiungi assunzioni e una clausola di gestione delle modifiche. Indica cosa ti serve dal cliente e il processo esatto per gestire le nuove richieste.
6. Invialo per la firma prima di iniziare il lavoro. Un SOW non firmato è un desiderio. Ottenere la firma prima è parte del motivo per cui i team disciplinati rispettano le consegne: nel settore, solo il 31% dei progetti viene completato nei tempi, nel budget e secondo lo scope previsto, e uno scope non firmato e poco chiaro è una delle ragioni principali.

Gli errori che lasciano entrare lo scope creep

La maggior parte dei problemi di scope si riconduce alle stesse poche lacune:

• Deliverable vaghi. "Un sito web" invita alle discussioni. "Cinque pagine, questi template, questo CMS" no.
• Nessuna sezione fuori scope. Se non dichiari ciò che non farai, il cliente darà per scontato che lo farai.
• Nessun criterio di accettazione. Senza un parametro per definire "completato," ogni deliverable può essere rimesso in discussione.
• Nessun controllo delle modifiche. Senza un processo scritto, ogni nuova richiesta diventa una trattativa, e di solito gratuita.
• Nessuna firma. Un SOW non firmato non tutela nessuno.

Queste lacune costano care. Il PMI ha stimato che le organizzazioni sprecano quasi il 10% di ogni dollaro investito a causa di una scarsa gestione dei progetti. Un SOW più preciso è uno dei modi più economici per recuperare parte di questo valore.

Da un accordo concluso a un SOW firmato, senza riscrivere nulla

La maggior parte dei SOW viene ancora redatta a mano: si apre il documento dell'ultimo cliente, si sostituiscono i nomi, si riscrivono l'ambito e i numeri, si esporta un PDF, lo si invia via email e si insegue la firma. Ogni passaggio è un'opportunità per inviare il dato sbagliato.

I dati di cui hai bisogno sono già nel tuo CRM. Il deal che hai appena chiuso contiene il cliente, le voci, il prezzo e il responsabile. Portant genera il statement of work da un template che già utilizzi, lo compila con i dati del deal e le voci di HubSpot, e aggiunge la firma elettronica integrata, così il documento firmato si sincronizza con il record del deal con il relativo stato aggiornato. Mantieni il tuo template e il tuo formato. Nessuno riscrive un deal che esiste già nel CRM. È la stessa logica alla base della document automation in generale: smetti di ricostruire documenti che hai già.

Domande frequenti

Che cos'è un statement of work nella gestione dei progetti?

Nella gestione dei progetti, il statement of work è il documento che definisce l'ambito, i deliverable, il calendario e i criteri di accettazione del progetto prima che i lavori inizino. È il riferimento a cui tutti tornano quando emerge una domanda sull'ambito.

Chi redige il statement of work?

Di solito è il fornitore di servizi a redigerlo, poiché conosce il lavoro, mentre il cliente lo esamina e lo firma. Per i progetti più grandi, un project manager o un account lead se ne occupa, spesso partendo dalla proposta già concordata dal commerciale.

Un statement of work è legalmente vincolante?

Un SOW firmato è generalmente vincolante, sia come contratto autonomo sia come ordine di lavoro nell'ambito di un master service agreement. Fai revisionare il tuo contract template da un legale almeno una volta, in particolare le clausole relative a pagamento, responsabilità e risoluzione.

Qual è la differenza tra un statement of work e un ordine di acquisto?

Un statement of work descrive il lavoro da svolgere e i criteri con cui verrà giudicato completato. Un ordine di acquisto è l'autorizzazione dell'acquirente a spendere una determinata somma per quel lavoro. Il SOW definisce il lavoro; il PO impegna il budget.

Quanto deve essere lungo un statement of work?

Quanto basta per eliminare ogni ambiguità, e non di più. Un SOW focalizzato sui servizi è spesso di due o quattro pagine. La chiarezza conta più della lunghezza: un SOW conciso di tre pagine vale più di uno gonfiato di dieci.

Se i tuoi SOW vivono in un Google Doc che copi e modifichi per ogni cliente, puoi collegare quel template al tuo CRM e inviarlo per la firma in un unico flusso. Scopri come Portant crea e invia un statement of work da un HubSpot document template.