Una Statement of Work, o S.O.W., è uno dei più importanti documenti nel project management in quanto delinea tutto ciò che deve rientrare in un progetto.
INDICE DEI CONTENUTI
I processi di gestione del progetto includono molti documenti diversi, indipendentemente dal settore, ma nella SOW si può ritrovare una descrizione completa di quello che sarà il progetto.
Non solo schemi dati e numeri previsionali ma un vero e proprio racconto del lavoro progettuale. Verranno descritte le attività da svolgere, i risultati da ottenere e le scadenze, ma anche i prezzi, condizioni e governance del progetto.
In sostanza la Statement of Work è il documento più completo del progetto per avere una visione d’insieme di ciò che ci apprestiamo a realizzare e dei tempi e modi in cui intendiamo farlo.
Vediamo meglio di che si tratta in questo articolo.
Che cos’è una Statement of Work?
Una SOW è un documento di project management formale che ha lo scopo di definire l’intero ambito di lavoro del progetto e chiarire risultati, costi e scadenze.
Questo tipo di documento viene utilizzato nei casi in cui i progetti coinvolgono fornitori e collaboratori esterni e viene generalmente creato come parte di un contratto.
I responsabili di progetto dovrebbero prestare sufficiente attenzione a fornire una SOW chiara a tutti gli stakeholder per evitare controversie riguardanti risultati, budget o scadenze.
Una Statement of Work è praticamente “la Bibbia” per il lavoro che il progetto deve produrre, uno strumento di governance chiave, sia che venga utilizzato per dirigere il lavoro per un fornitore o appaltatore, sia che venga utilizzato per dirigere il lavoro internamente.
Il lavoro contenuto in questo documento fa parte dell’obbligo contrattuale, mentre le attività non contenute saranno svolte solo se concordate reciprocamente o introdotte nel progetto attraverso una richiesta di modifica.
Quando si ha bisogno di una SOW?
Il valore di una SOW risiede nella sua capacità di acquisire tutti gli elementi di lavoro ed attività critiche del progetto ed è particolarmente utile in due situazioni:
- Quando si stipula un contratto con un fornitore o un consulente esterno
- Come fase di pianificazione intermedia per un grande e complesso progetto in cui il lavoro viene svolto internamente.
Non si ha bisogno di una Statement of Work quando il progetto è piccolo e abbastanza semplice da mettere in pratica.
Quando redigere la SOW?
La SOW deve essere redatta dopo la dichiarazione dell’ambito, quindi durante la fase di pianificazione del progetto.
In particolare, la dichiarazione dell’ambito dovrebbe catturare, seppur in termini molto generali, il prodotto del progetto.
Ad esempio, se si vuole lanciare un progetto per sviluppare un software per acquisire e tenere traccia degli ordini, la dichiarazione di ambito includerebbe un elenco degli utenti impiegati per l’immissione degli ordini, gli ingegneri del software e gli impiegati che spediscono gli ordini.
Inoltre, si potranno anche includere le funzionalità desiderate nel sistema, ad esempio se è accessibile su Internet, quali informazioni deve archiviare su ciascun ordine, come il sistema raccoglierà il pagamento per l’ordine, ecc.
La dichiarazione dell’ambito, in poche parole, fornirà informazioni su ciò che è necessario produrre o costruire attraverso il progetto.
Una volta determinato cosa si sta costruendo, è necessario catturare i dettagli su come verrà costruito; ecco quindi che si prepara la SOW.
La Statement of Work definisce le attività da svolgere e deve quindi essere scritto prima che il lavoro possa essere programmato o che venga creata una suddivisione del lavoro.
Cosa si include nella Statement of Work?
Tutti gli elementi catturati nella dichiarazione dell’ambito di progetto dovrebbero apparire anche nella SOW.
Essa dovrebbe contenere informazioni sui risultati finali a un livello più dettagliato.
Ad esempio, se la dichiarazione dell’ambito include un sistema di acquisizione e gestione degli ordini, è possibile suddividere tale risultato in un database per acquisire, archiviare e tenere traccia delle informazioni, un front-end per interfacciarsi con gli utenti e un sistema di reporting per gestire i report.
Ecco un elenco di categorie di informazioni che solitamente si includono nella SOW:
- Introduzione: iniziare con la spiegazione del lavoro svolto. Inoltre, indicare chi è coinvolto nel progetto.
- Qual è lo scopo del progetto, quali sono i risultati, gli obiettivi e il ritorno sull’investimento.
- Scopo del lavoro: quali attività dovranno essere svolte nel progetto e quali processi? Ciò include i risultati, il tempo necessario e persino i passaggi generali necessari per raggiungere questo obiettivo.
- Dove sarà svolto il lavoro: il team lavorerà presso una struttura centrale o da remoto? Qualunque sia il caso, in questa parte è necessario dettagliarlo, oltre che indicare dove saranno posizionati l’apparecchiatura e il software utilizzati.
- Compiti: adottare i passaggi generali delineati nel documento dell’ambito e suddividerli in compiti più dettagliati. Se lo si desidera, suddividere le attività in pietre miliari o fasi.
- Pietre miliari: definire il periodo di tempo previsto per il completamento del progetto, dalla data di inizio alla data di fine proposta. Dettagliare le ore fatturabili alla settimana e al mese e qualsiasi altra cosa si riferisca alla programmazione del progetto, ad esempio, se esiste un numero massimo di ore fatturabili per fornitori e / o contratti.
- Risultati: spiegare cosa è dovuto e quando è dovuto. Descriverlo in dettaglio, come quantità, dimensioni, colore e tutto ciò che potrebbe essere rilevante.
- Pianificazione: includere un elenco dettagliato di quando devono essere presentati i risultati finali, a partire da quale fornitore sarà scelto, il periodo di esecuzione, la fase di revisione, lo sviluppo, l’implementazione, i test, la chiusura del progetto, ecc.
- Standard e test: se ci sono standard di settore che devono essere rispettati, elencarli. Inoltre, se saranno previsti test del prodotto, elencare chi sarà coinvolto in questo processo, quali attrezzature sono necessarie e altre risorse.
- Definire il successo: annotare ciò che lo sponsor e / o le parti interessate si aspettano affinché il completamento del progetto abbia esito positivo.
- Requisiti: elencare qualsiasi altra attrezzatura necessaria per completare il progetto e se è richiesta una laurea o certificazione necessaria per i membri del team.
- Pagamenti: se il budget è stato creato, è possibile elencare i pagamenti relativi al progetto e come verranno elargiti – in anticipo, nel tempo o dopo il completamento.
- Altro: se ci sono parti del progetto che non possono essere ricondotte alle categorie di cui sopra, è possibile aggiungerle in questa fase in modo che tutto sia coperto.
- Chiusura: determinare in che modo verranno accettati i risultati finali e chi consegnerà, esaminerà e firmerà l’accettazione. Inoltre, in questa parte rientrano anche le specifiche sulle funzioni amministrative finali, come la conferma che tutto sia firmato, chiuso e archiviato.
Come è possibile notare, ci sono moltissime informazioni da includere in una SOW.
Il tutto deve essere specifico e definito chiaramente in modo da evitare confusione più avanti nel progetto quando non è possibile permettersi errori di comunicazione o controversie.
Includere elementi visivi nella SOW, grafici o altre illustrazioni, può aiutare a focalizzare meglio l’obiettivo sui vari aspetti del progetto.
Dopo aver redatto la SOW nel dettaglio, il passaggio finale e cruciale è quello di ottenere la sua approvazione.
Per questo, il project manager deve assicurarsi che i responsabili abbiano firmato lo Statement of Work; in caso di controversie in futuro infatti, sarà possibile mostrare il documento firmato a supporto delle proprie azioni.
In conclusione, la SOW aiuta quindi i project manager, in quanto fornisce loro una struttura su cui possono essere costruiti i piani di progetto.
Il documento aiuta inoltre a evitare conflitti durante il ciclo di vita del progetto e mantiene tutti coloro che sono coinvolti sulla stessa pagina oltre ad aiutare a ridurre al minimo la confusione.
