Statement of Work

Quanto è importante lo statement of work?

Wikipedia definisce così lo statement of work (SOW) .

Il PMBOK(r) definisce il SOW come una descrizione “narrata” del prodotto/servizio che il progetto dovrà realizzare e  che  solitamente dovrebbe contenere:

• le motivazioni di business che spingono l’azienda ad istanziare il progetto (strategia commerciale, adeguamenti legali, avanzamenti tecnologici, ecc.)
• decrizione dell’ambito del prodotto/servizio: verranno qui descritte le funzionalità, caratteristiche e gli attributi che il prodotto dovrà possedere, preferibilmente messe in relazione alle motivazioni di business sopra descritte
• piano strategico: gli obiettivi e i tempi che si vogliono perseguire attraverso la realizzazione del progetto

Il PMBOK(r) definisce inoltre che tale documento dovrebbe essere frutto di sforzi fatti internamente all’azienda.

Questo, dal mio punto di vista, è ovvio in quanto chi conosce le reali esigenze che ha l’azienda, quali le necessità da soddisfare e in quale modo, sono solo le persone interne all’azienda stessa.

Il documento compilato potrà quindi essere inoltrato ai fornitori in gara, per poter procedere alla compilazione dell’offerta.

La mia esperienza quotidiana, ahimé, mi dice che quanto sopra scritto non è sempre vero.

Spesso il cliente ci convoca quando ancora non sono definiti completamente strategia e caratteristiche del prodotto, ma semplicemente quando è nata un’idea che lui stesso non ha avuto ancora il tempo di sviluppare, se non in maniera generica.

Ed è proprio a questo punto che capita di incappare in una prima situazione di stallo.
Il cliente crede che la chiacchierata di qualche ora in cui ci ha spiegato per sommi capi cosa desidera, possa essere sufficiente a redigere un’accurata offerta.
Quando poi accenniamo, data la mancanza di dettaglio, alla necessità di esporre in fase di offerta la fatidica “forbice di prezzo” più o meno ampia a copertura dei rischi e delle incertezze date dal mancato dettaglio, nascono spesso le prime incomprensioni.

A quel punto per riappianare la situazione, sfoderiamo la carta della consulenza che noi, in quanto project manager, possiamo erogare al cliente per aiutarlo nella fase di prima analisi e  redazione  congiunta dell fatidico statement of work che servirà, quindi, anche alla redazione di un’offerta più mirata.

Ecco il secondo punto di stallo: il cliente, con fare piuttosto scocciato, ci chiederà “Perché mai ti dovrei pagare per permetterti di farmi un’offerta?”.

Il cliente raramente capisce che quel documento dovrebbe redarlo da solo.

Questo gli permetterebbe realmente di analizzare, capire in profondità, strutturare e dare risposte alle reali esigenze aziendali, creando condivisione tra le persone interne coinvolte e ponendo una prima importantissima pietra miliare per il successo del progetto.

Ecco, questo è lo scenario.
Ovviamente ogni regola esiste per essere smentita o per permettere alle eccezioni di manifestarsi, fiere e splendenti.
Ecco quindi, che nel giro di due settimane mi si sono presentate non una ma due eccezioni a quanto appena raccontato.

La prima riguarda la progettazione di un portale piuttosto corposo, rivolto ad un mercato relativamente nuovo, portale che richiede particolari attenzioni stilistiche, funzionali, navigazionali.

La seconda, diametralmente opposta, riguardante la creazione di un’applicazione aziendale volta ad automatizzare articolati processi di gestione del ciclo di vita dei prezzi di prodotti di una importante azienda multinazionale, in cui entrano in gioco meccanismi composti di approvazione delle richieste, di integrazione con sistemi pre-esistenti, vincoli stringenti di facilità d’uso, necessità avanzate di reporting e business intelligence.

Bene, per entrambi oltre alla richiesta di quotazione, ho ricevuto un dettagliato ed esaustivo statement of work.

In entrambe vengono descritte: la situazione di lavoro iniziale, le motivazioni per cui si vuole intraprendere quello sviluppo, le diverse funzionalità del prodotto, il tutto corredato da esempi mirati e particolareggiati, meccanismi di calcolo, modalità di approccio in funzione delle utenze previste.

Insomma un SOW come “disciplina comanda”.

Certamente quanto fatto dai pm delle due aziende li ha visti impegnati per parecchio tempo, nella revisione dei processi esistenti, in tentativi “infiniti” di coinvolgimento dei colleghi in diverse riunioni, nella redazione dei suddetti documenti e nel rendere partecipe il management.

Quanto fatto da loro, sicuramente permetterà all’azienda di meglio indirizzare i propri investimenti nel perseguire le strategie di business, ottenere quotazione mirate dai singoli fornitori e indirettamente aumentare le possibilità di successo del progetto, dovuta ad una generale maggiore chiarezza intorno ai requisiti di progetto.

Quindi non importa da che parte stiate: se siete il committente dedicate il tempo opportuno per la compilazione del SOW la vostra azienda se ne gioverà, se siete invece chi ha l’incarico di eseguire il progetto, insistete perché il SOW vi venga fornito.

La WBS (work breakdown structure)

Il PMBOK terza edizione, suggerisce la seguente definizione:
“Scomposizione gerarchica orientata verso i deliverable del lavoro che deve essere eseguito dal gruppo di progetto, per realizzare gli obiettivi del progetto e creare i deliverable richiesti. Organizza e definisce l’ambito complessivo del progetto. Ogni livello discendente rappresenta una definizione sempre più dettagliata del lavoro del progetto. La WBS viene scomposta in Work Package.”

In sostanza una sorta di scomposizione delle funzionalità previste, ma anche di tutte quelle parti non riconducibili a caratteristiche di prodotto ma che rappresentano attività di progetto vere e proprie (test, redazione help, meeting, rilasci, ecc.). Ciò appena descritto rappresenta la differenza principale tra WBS di progetto e WBS di prodotto.

 Una volta scoperto “l’arcano”, mi risollevai considerando che sino a quel momento avevo, involontariamente, sempre incluso una WBS nelle analisi di dettaglio e che semplicemente la chiamavo “scomposizione delle funzionalità”.

 Ad oggi ho utilizzato tre diversi layout per rappresentare una WBS: grafica, tabellare e di testo.

 

 In generale trovo più comodo utilizzare la WBS in formato grafico, quando mi rapporto con il team e sto conducendo una review: riesco meglio a comprendere a che punto siamo arrivati e quail rami stiamo sviluppando.
Quella tabellare, forse più elegante, la utilizzo nel project plan per garantire a me stesso e al cliente massima chiarezza nella suddivisione del lavoro attraverso la codifica chiara e strutturata, che poi porta all’identificazione univoca delle deliverable.
Quella più diretta in formato testo, tendo ad utilizzarla in documenti draft propedeutici alla formalizzazione del project plan finale.

Poi, procedendo negli studi e soprattutto grazie a mr Kerzner, e nella pratica grazie ai miei clienti, mi sono reso conto di quanto fosse centrale la WBS anche per le seguenti tematiche:

1. Assegnazione delle responsabilità
2. Totalizzazione dei costi per attività, work package, deliverable
3. Contabilizzazione dei costi per centri di costo (appunto)
4. Definizione di un roll-out plan per deliverable
5. Utilizzo delle attività scomposte per favorire le stime tempi/costi
6. Analisi degli stakeholders e loro influenza rispetto alla WBS
7. Risk analysis
8. Issue log communication

A breve fornirò maggiori indicazioni su come utilizzo la WBS come strumento base per procedere ai punti sopra esposti.

Have fun!