Dichiarazione di lavoro. Per quanto sembri semplice, ottenerne una giusta non è un compito facile. Ma niente è più fondamentale per il successo di un progetto. Se la dichiarazione di lavoro è troppo vaga, troppo ampia o troppo generica, può lasciare spazio a varie interpretazioni, che possono portare a problemi lungo la strada. Questo è vero per un progetto interno, ed è doppiamente vero quando ci sono fornitori coinvolti.
“L’incapacità di eseguire correttamente una dichiarazione di lavoro è spesso la ragione per cui le parti finiscono in una controversia”, dice David M. Greenberg, un avvocato nel gruppo di pratica di tecnologia, media e telecomunicazioni presso l’ufficio di Greenberg Traurig LLP di New York.
Per ottenere il vostro progetto la prima volta, seguite queste linee guida per scrivere un’efficace dichiarazione di lavoro, o SOW, come viene affettuosamente chiamato.
Capire cos’è un SOW.
Un SOW definisce la portata del lavoro richiesto e il tempo in cui deve essere eseguito. È “la pietra angolare di un accordo”, dice Nick Scafidi, responsabile degli acquisti IT presso il fornitore di energia National Grid USA a Westboro, Mass. “Stabilisce le aspettative, i prodotti da consegnare, ciò che è accettabile, il prezzo, il programma dei prezzi. Senza questo, è come dire a un appaltatore, ‘Costruiscimi una casa’, dicendogli quando, che tipo o quanto grande”.
Sapere cosa includere.
Bruce Russell, che ha firmato numerosi SOW quando era direttore operativo in una società di sviluppo software, dice che uno buono include queste cose:
- I principali deliverable e quando sono attesi.
- I compiti che supportano i deliverable, così come quale parte — l’azienda che assume o il fornitore di servizi — eseguirà questi compiti.
- Il processo di governance del progetto, insieme a quanto spesso i comitati di governo si incontreranno.
- Quali risorse sono richieste per il progetto, quali strutture saranno usate e quali attrezzature saranno necessarie, così come i requisiti di test.
- Chi pagherà quali costi e quando.
“La dichiarazione del lavoro mette insieme tutti gli elementi all’inizio”, dice Russell, ora professore esecutivo al College of Business della Northeastern University a Boston. “E più preciso si può fare, più quantitativo è, meglio è”.
Definire il successo.
Una dichiarazione di lavoro dovrebbe chiarire per tutte le parti ciò che costituisce il successo o il fallimento, dice Melise R. Blakeslee, un avvocato nel gruppo di proprietà intellettuale, media e transazioni tecnologiche presso McDermott Will & Emery LLP a Washington.
“Bisogna descrivere adeguatamente il lavoro e i criteri per come entrambi siete d’accordo” che qualcosa è stato completato con successo, dice Ruth Anne Guerrero, manager degli standard al Project Management Institute Inc. di Newtown Square, Pa., e un ex project manager IT.
Per esempio, dice, se vi aspettate che il vostro fornitore sviluppi i requisiti utente, il vostro SOW dovrebbe dichiarare che il fornitore deve intervistare specifici gruppi di utenti e far approvare i requisiti prima che il lavoro sia considerato fatto. Questo definisce il successo meglio che dire semplicemente: “Il fornitore produrrà i requisiti utente”.
La definizione di successo dipende dal progetto, dice Guerrero. I leader dei progetti IT devono specificare se il successo dell’implementazione è definito dalla velocità, dal tempo di risposta, dalla facilità d’uso o da tutti e tre e poi quantificarli nel SOW.
Non dimenticare una tabella di marcia.
Le implementazioni di successo non possono essere definite solo dalla velocità o dalla reattività del sistema. Dopo tutto, a cosa serve una grande applicazione se ci vuole un decennio per costruirla? Ecco perché un SOW deve includere elementi di tempo. Guerrero raccomanda di usare un linguaggio che permetta una certa flessibilità piuttosto che una data fissa sul calendario. Un SOW dovrebbe specificare, per esempio, che i requisiti dell’utente finale sono dovuti due mesi dopo la firma del contratto — una formulazione che fa ancora andare avanti il progetto mentre accomoda potenziali problemi come un ritardo nella firma del contratto.
Un SOW dovrebbe anche designare tempi specifici per le revisioni formali, in modo che tutte le parti coinvolte possano confermare che sono sulla buona strada, dice Matt Liberatore, un professore nel dipartimento di decisione e tecnologie dell’informazione e la cattedra John F. Connelly in gestione presso il College of Commerce and Finance della Villanova University di Villanova, Pa.
Legare il pagamento alle pietre miliari.
Un’altra componente chiave per mantenere il lavoro in pista è l’impostazione di specifiche pietre miliari nel SOW e legare il pagamento al completamento con successo, dice Blakeslee.
Quando Scafidi scrive un SOW, specifica che i pagamenti ai venditori sono fatti all’accettazione dei deliverable chiave. Egli nota anche che tratterrà una parte della paga fino a quando il fornitore non dimostrerà che tutti i deliverable funzionano insieme.
Usa un linguaggio che tutti possono capire.
Il dipartimento IT e i suoi fornitori non sono gli unici che usano il SOW, dice Blakeslee. Quindi non scrivetelo come se solo le persone IT lo vedranno. “Dovrebbe essere comprensibile agli utenti finali, ai fornitori di servizi, alla gestione e a un giudice”, dice.
Siate specifici.
Anche se numerose parti devono capire la dichiarazione di lavoro, siate precisi nel descrivere l’ambito e i requisiti del progetto, dice Blakeslee. Ha visto documenti che fissano obiettivi vaghi, come “lavoreranno al meglio delle loro capacità”. Lo paragona a un proprietario di casa che assume un pittore con le istruzioni di “usare il miglior sforzo possibile”.
“Se il pittore lo fa ma dipinge la vostra casa di viola invece che di bianco, allora non avreste un reclamo contro di lui”, dice.
Scafidi ha preso a cuore questo consiglio. Invece di dire che un compito richiederà “una quantità ragionevole di tempo”, Scafidi scrive: “Il compito specificato non richiederà più di quattro ore”.
“Gli avvocati si sentono bene quando abbiamo una definizione chiara e non ambigua su cose come questa”, dice.
Ricordate le esigenze di postproduzione.
Guerrero raccomanda di includere i requisiti di postproduzione nel SOW. Dice di specificare i test e il supporto di cui avrete bisogno dal fornitore. E se avete intenzione di far supportare il sistema da personale interno dopo l’installazione, il SOW dovrebbe indicare se il fornitore formerà il vostro personale. Questo linguaggio, dice, garantisce che il fornitore non “consegni il sistema e se ne vada”.
Pratt è uno scrittore che contribuisce a Computerworld a Waltham, Mass. Contattatela all’indirizzo [email protected].
.