Il Piano di Gestione dell'Ambito (Scope Management), la sostanza intorno a cui tutto ruota
Antonio Giannico
MScEng, Project Manager UNI 11648, PMP®, SMC™ Scrum Master, Accredited Senior Project Management Teacher (ISIPM), ISIPM-Prado® Assessor
Quando si pianifica il progetto è già abbastanza chiaro, almeno a grandi linee, cosa ci si aspetta che esso produca. Ciò tuttavia non basta. Sviluppato il Piano di Project Management, occorre esploderne aspetti specifici. Occorre esplodere gli obiettivi del progetto, definendo i deliverable specifici che contribuiranno a comporne i risultati, occorre in altri termini definire e strutturare, in maniera più ampia ed esaustiva, il cosiddetto ambito del progetto (in inglese scope).
L’ambito del progetto è ciò che esso deve produrre e solo quello.
Può apparire un concetto ovvio eppure intorno alla gestione dell’ambito ruotano spesso le indeterminazioni più distruttive che possono annidarsi in un progetto. Infatti, il come produrre i risultati e il cosa produrre sono due aspetti che viaggiano all’unisono e ciò che di deleterio si annida in uno si propaga inevitabilmente nell’altro. Ecco che sviluppare un piano specifico per l’ambito è un approccio tutt’altro che scontato e assolutamente necessario.
L’ambito è la sostanza intorno a cui tutto ruota, dal momento che senza di esso il progetto semplicemente non esisterebbe.
La gestione dell’ambito del progetto si concretizza in una serie di processi che come project manager siamo chiamati a conoscere e percorrere al fine di garantire che il progetto comprenda tutto il lavoro necessario ed esclusivamente quello.
La corretta gestione dell’ambito contribuisce a comporre i risultati corretti e a garantire le migliori performance globali del progetto stesso.
Non di rado l’ambito del progetto soffre di “patologie varie” di cui il fenomeno dello scope creep, cioè la deformazione incontrollata dell’ambito, è solo uno dei molteplici effetti che finiscono per rendere oltremodo tortuoso e dispendioso il raggiungimento degli obiettivi.
L’ambito è per questo, quanto di più esplicito occorre definire nel progetto. Una definizione anche parzialmente implicita dell’ambito è qualcosa di relativamente comune ma allo stesso tempo più deleteria di quanto si possa immaginare. Molto spesso, ciò accade in progetti che già a monte soffrono di una genesi inadeguata che rende difficoltosa la definizione prima ancora che la reale gestione dell’ambito.
Può sembrare una visione poco ottimistica ma resta un dato di fatto: possiamo pianificare l’ambito in maniera più o meno formale ma non possiamo sfuggire alla necessità di definire correttamente e in maniera esaustiva, chiara, esplicita ciò che è incluso nel progetto e ciò che non lo è.
Pigrizia, superficialità, eccessivo ottimismo, incapacità di applicare i processi, inesperienza, ci portano spesso a gestire l’ambito del progetto maniera vaga e poco definita.
Spesso si motiva (o giustifica!) questo approccio con la necessità di non dover o poter perdere tempo, dalla presunzione di essere pratici, concreti, salvo a conti fatti renderci conto, senza peraltro ammetterlo, di aver dilapidato molte più risorse di quanto un corretto approccio avrebbe richiesto.
Senza una corretta analisi di questa dinamica si rischia inoltre di cadere nel tranello rassicurante del “fare come si è sempre fatto” reiterando tanto l’approccio all’ambito quanto gli errori che ne conseguono. Operare sempre allo stesso modo ci fa infatti apparentemente perdere meno tempo e meno risorse nell’immediato, ci appare rassicurante, pratico. Ma lo è davvero?
Il processo Pianificare la Gestione dell’Ambito
Pianificare la Gestione dell’Ambito significa prima di tutto definire in che modo strutturare l’ambito. Infatti, un project manager mediamente preparato e mediamente esperto sa bene che l’ambito non può essere strutturato sempre allo stesso modo ma va strutturato in funzione dello specifico progetto. In funzione di ciò occorrerà anche definire in che modo tenerlo sotto controllo e in che modo validarlo ovvero in che modo validarne risultati, intermedi e finali, lungo l’intero ciclo di vita del progetto.
Il progetto, a seconda della sua natura, può necessitare di approcci prevalentemente predittivi piuttosto che adattivi o agile. Ciò vale anche e soprattutto per l’ambito, il resto è una conseguenza. Gestire un progetto, e il suo ambito in particolare, in maniera adattiva deve essere diretta conseguenza della natura del progetto stesso e non discendere dalla cattiva abitudine di lasciare l’ambito del progetto indefinito oltre le reali necessità.
Un buon Piano di Gestione dell’Ambito porta alla definizione di un’adeguata e corretta baseline dell’ambito, composta da seguenti elementi: una efficace e univoca descrizione dell’ambito, una specifica struttura di scomposizione del lavoro (WBS-Work Breakdown Structure) e un dizionario della WBS che la accompagna. Esso guida inoltre l’ufficiale approvazione e revisione in corso d’opera della baseline medesima.
Occorre a questo punto chiederci:
- al di là della documentazione che formalmente dovremmo produrre, abbiamo cognizione e consapevolezza di cosa sia l’ambito e il suo piano?
- abbiamo consapevolezza di quale sia il corretto approccio all’ambito del progetto?
- e degli effetti di un errato approccio?
Il successo del progetto, il suo stato di avanzamento in corso d’opera, le sue performance, dipendono dal grado di completamento del suo ambito e ciò è qualcosa che non può essere efficacemente controllato se l’ambito non è formalmente e correttamente strutturato.
La definizione dell’ambito dipende d’altronde fortemente dall’interpretazione delle richieste e delle necessità degli stakeholder tutti, non solo dell’utente finale e/o del cliente del progetto. Ciò presuppone un adeguato coinvolgimento degli stakeholder.
Erroneamente invece molto spesso, soprattutto in certi contesti, si ritiene di sapere di cosa il cliente o l’utente abbia bisogno, salvo scoprire a posteriori che la nostra definizione dell’ambito non corrisponde alle reali aspettative del cliente o dell’utente o che genera contestazioni di determinati stakeholder.
Ci siamo mai posti il problema di quantificare economicamente, in termini di effetti diretti (perdite economiche) e indiretti (per esempio di immagine) le conseguenze di una gestione di questo tipo? Se non lo abbiamo mai fatto forse è il caso di cominciare a fare questo semplice ma utilissimo esercizio pratico.
La gestione dell’ambito prevede, prima di tutto, una corretta gestione dei requisiti del prodotto o servizio che dovrà scaturire dal progetto e non può essere altrimenti.
Così come l’ambito va gestito lungo l’intero ciclo di vita del progetto la stessa cosa vale evidentemente per i requisiti.
- Ne siamo coscienti?
- In quali nostre azioni si rispecchia effettivamente questa consapevolezza?
- Essi, i requisiti, vengono realmente e correttamente raccolti, tracciati, analizzati in forma adeguatamente strutturata o piuttosto spesso si è già alla realizzazione del prodotto quando ancora non si sono compresi i requisiti?
Il Piano di Gestione dell’Ambito deve per questo definire per lo specifico progetto anche come gestire i requisiti: dove reperirli, da cosa farli scaturire, come tracciarli. Molto spesso questa parte del piano trova posto in un documento specifico: il Piano di Gestione dei Requisiti.
In progetti incerti per loro natura, spesso l’ambito non è sufficientemente definito in partenza ma si va definendo più chiaramente nel corso del progetto man mano che determinati requisiti emergono più chiaramente. In questo caso l’approccio si basa su metodi agili ed è frequente che, per definire i requisiti e renderli stabili, si disegnino esperimenti, si realizzino prototipi, si eseguino indagini, si affinino i requisiti, se ne riformulano alcuni, se ne aggiungano di nuovi.
Il processo Pianificare la Gestione dell’Ambito normalmente viene percorso una sola volta solo per progetti fortemente predittivi, altamente standardizzati. In tutti gli altri casi è quasi sempre necessario rivedere in momenti successivi il piano e riaggiornarlo ripercorrendo più volte il processo stesso.
Ciò premesso, di seguito descriviamo brevemente gli ingressi, gli strumenti e le uscite tipiche del processo.
Ingressi
Le informazioni più di alto livello, su cosa il progetto debba realizzare, sono contenute nel project charter, pertanto è abbastanza logico immaginare che il project charter sia ingresso del processo Pianificare la Gestione dell’Ambito (Figura 1).
Degli ingressi fanno parte, anche e inevitabilmente, il più generale Piano di Project Management, essendo questo di coordinamento e integrazione per i piani ausiliari, compreso quello dell’ambito.
Allo stesso modo, nel Piano di Project Management possono rientrare indicazioni di massima, gestionali e operative, che si rifanno alla politiche della qualità e agli standard di qualità dell’organizzazione. Del resto, il progetto realizzato all’interno di un’organizzazione non è un corpo estraneo all’organizzazione stessa quanto piuttosto qualcosa che è destinato a produrre valore per l’organizzazione, non solo attraverso gli obiettivi espliciti ma anche attraverso il più generale aggiornamento dell’asset aziendale conseguente all’acquisizione indiretta di know-how, informazioni, competenze e quant’altro sia legato al progetto.
La descrizione del ciclo di vita del progetto fatta inizialmente dipende molto dalla sua natura più o meno predittiva piuttosto che adattiva, incrementale o agile e ha inevitabili implicazioni sull’approccio allo sviluppo del progetto in tutti i suoi aspetti, compreso l’ambito e il Piano di Gestione dell’Ambito.
Fattori ambientali aziendali e asset dei processi organizzativi, ovviamente, influenzano inevitabilmente anch’essi il piano.
Tutto quanto qui espresso circa gli ingressi è sinteticamente riassunto nello schema di Figura 1.
Strumenti e tecniche
Come per lo sviluppo del Piano di Project Management, anche per lo sviluppo di un adeguato Piano di Gestione dell’Ambito, è necessario l’apporto di esperti. Tra gli strumenti compare pertanto, in accordo con lo standard del PMBOK, il cosiddetto parere di esperti già discusso in precedenti articoli.
Stessa cosa dicasi per le riunioni e l’analisi dei dati. Per la verità, in questo frangente del progetto si avvia, più che una semplice raccolta di dati una vera e propria analisi dei dati utile alla pianificazione dell’ambito. In particolare, è ricorrente l’analisi di alternative, analisi che si riproporrà più volte come necessaria anche durante altri i processi di pianificazione. Si tratta di analizzare alternative su requisiti di prodotto, su come creare il prodotto, su come controllare e validare l’ambito alla luce di tutto quanto è fino a questo momento noto sul progetto.
Alle riunioni per la pianificazione dell’ambito dovrebbero partecipare, oltre al PM, i componenti del team di project management, alcuni componenti del più ampio team di progetto che hanno specifiche competenze tecniche e specifici altri stakeholder chiave tra cui potrebbe rientrare lo sponsor.
Uscite
Questo processo produce, ovviamente, il Piano di Gestione dell’Ambito e fissa quindi in che modo dovrà essere descritto, sviluppato, monitorato, controllato e validato l’ambito. Il documento definisce anche alcuni altri aspetti cui spesso non si pensa ma che hanno effetto sull’efficace gestione dell’ambito:
- fino a che livello di dettaglio descrivere l’ambito (in un progetto standardizzato potrebbe essere superfluo definire in dettaglio l’ambito, in un progetto nuovo e incerto o rischioso si pone sicuramente maggiore attenzione);
- come strutturare la WBS (Work Breakdown Structure, ovvero struttura di scomposizione del lavoro di progetto) e fino a che livello di dettaglio;
- come strutturare il dizionario della WBS;
- quali saranno le modalità di approvazione della baseline dell’ambito (chi approva, chi è consultato, chi è delegato, come vengono gestite le revisioni a livello documentale, chi revisiona, ecc…)
- quale è il processo di accettazione cioè di validazione dei deliverable di progetto intermedi e finali che compongono l’ambito.
In generale, il piano può essere più o meno formale, più o meno dettagliato, purché sufficiente a definire in maniera adeguata come gestire correttamente ed in maniera efficace l’ambito del progetto.
Generalmente, insieme al Piano di Gestione dell’Ambito viene definito un Piano di Gestione dei Requisiti. I requisiti sono infatti strettamente legati all’ambito, dal momento che i deliverable intermedi e finali di progetto dovranno rispondere a specifici requisiti che occorrerà definire e tracciare. I requisiti hanno infatti dirette implicazioni sulla gestione della configurazione del prodotto e dei servizi che il progetto è chiamato a produrre.
Figura 1-Il processo “Pianificare la gestione dell’ambito”: ingressi, strumenti, uscite
Figura 2-Interconnessioni tra il processo “Pianificare la gestione dell’ambito” e gli altri processi di project management
Conclusioni
A volte il cliente e gli utenti dei prodotti e dei servizi che il progetto dovrà realizzare non guardano a come abbiamo gestito il progetto ma guardano piuttosto il prodotto o il servizio che abbiamo realizzato, lo accettano o lo rifiutano in base al fatto che risponda o meno ai requisiti definiti e concordati e comunque alle loro esigenze (non quelle di chi ha realizzato il progetto!). Molte altre volte richiedono qualcosa in più, richiedono di avere visione del progetto stesso e di come viene gestito, perché consci del fatto che la qualità dell’ambito che consegneremo dipende dalla qualità del progetto tecnico e di quella della sua gestione. Questo secondo approccio è ormai sempre più ricorrente, soprattutto in determinati ambiti, e andrebbe preso per assodato.
Analoghe aspettative ha lo sponsor. Se non gestiamo correttamente l’ambito pertanto, non potremo gestire alcuna aspettativa, né esterna né interna al progetto.
Se non abbiamo chiaramente strutturato l’ambito del progetto sarà difficile raggiungerne gli obiettivi e creare soddisfazione così come sarà difficile creare valore per l’organizzazione e proiettare il suo asset verso il futuro.
La gestione strutturata e documentata dell’ambito è quindi fondamentale. Come al solito tuttavia, non si tratta di produrre documenti, quanto piuttosto di utilizzare i giusti strumenti per “dominare", in questo caso, l’ambito del progetto.
Chiudiamo chiedendoci:
- Come gestiamo solitamente l’ambito dei nostri progetti?
- Ne definiamo un piano più o meno formalmente?
- E’ un piano condiviso con il team e altri stakeholder?
- Normalmente chi è responsabile del suo sviluppo?
- E della sua approvazione?
- Viene allo scopo pianificata una corretta raccolta e gestione strutturata dei requisiti?
- Questa gestione è estesa all’intera durata del progetto o si limita alla sola fase iniziale e perché?
In altre parole:
- la gestione dell’ambito è consapevolmente pianificata e strutturata o è relativamente implicita e in parte improvvisata?
- Siamo ben coscienti che una gestione improvvisata dell’ambito nulla ha a che vedere con una gestione agile?
Non si tratta di eccessivi formalismi, quanto piuttosto di padroneggiare realmente l’ambito del progetto, la sostanza intorno a cui, in effetti, tutto ruota e senza la quale il progetto, semplicemente non esisterebbe, compresi i suoi obiettivi.
INDICE
ACCESSO:
SE LA TUA APP MOBILE NON RISPONDE AL LINK ACCEDI DA BROWSER MOBILE