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.
Agile PM, SCRUM | Emiliano Soldi | 
18/03/2011 23:18 | 
Comments (0) 
Subscribe
http://www.inspearit.it/it/
