Aspetti generali
La gestione dei requisiti stabilisce i desideri e i bisogni degli stakeholder, che sottopone poi a revisione per creare un insieme di requisiti baseline da utilizzare nello sviluppo delle soluzioni e nella gestione dei benefici. Gli obiettivi propri di questa funzione sono:
- Assicurare che tutti gli stakeholder pertinenti abbiano la possibilità di esprimere i propri desideri e i propri bisogni;
- Effettuare la riconciliazione dei requisiti dei molteplici stakeholder per creare un unico insieme fattibile di obiettivi;
- Ottenere il consenso degli stakeholder su un insieme di requisiti baseline.
Una formulazione chiara e concordata dei requisiti e dei loro criteri di accettazione è essenziale per il successo di qualsiasi progetto, programma o portfolio. I requisiti possono essere espressi come deliverable fisici, benefici di business, aspirazioni, funzioni o necessità di carattere tecnico.
Il passo di pianificazione definirà le tecniche e gli approcci che saranno utilizzati per lavorare con gli stakeholder al fine di individuare e concordare i requisiti. Il passo di inizio assicurerà che siano mobilitate le risorse necessarie e che possa partire la gestione dei requisiti.
I passi di pianificazione ed inizio sono di solito eseguiti come parte di una più generale procedura di gestione dell’ambito, ma possono anche essere gestiti separatamente nei casi in cui i requisiti siano particolarmente complessi o estesi.
Il primo passo specifico della procedura è l’acquisizione di tutti i tipi di requisiti. La maggior parte sarà generata dagli stakeholder interni ed esterni (come i clienti e gli utenti), ma ci potrebbe anche essere un retroterra di requisiti legali o normativi che devono essere ugualmente inclusi.
I requisiti devono essere analizzati per assicurare che siano pratici, raggiungibili e definiscano ‘cosa’ è richiesto piuttosto che ‘come’ sarà ottenuto. Un requisito ben specificato ha le seguenti caratteristiche:
- unico: riguarda solo un requisito fondamentale;
- attuale: è aggiornato e attinente alla necessità di business;
- coerente: non confligge con altri requisiti;
- comprensibile: è chiaro e univoco;
- verificabile: la conformità dei prodotti progettati per soddisfare il requisito può essere verificata per mezzo di un’ispezione, una dimostrazione o un collaudo;
- tracciabile: il requisito può essere tracciato a partire dal bisogno che lo ha originato, lungo il processo di consegna fino ad arrivare al prodotto realizzato;
- messo in ordine di priorità: la sua importanza è compresa in relazione agli altri requisiti.
I passi restanti saranno intrapresi in base al contesto del lavoro. Per esempio l’approccio per lo sviluppo di un software che utilizza un ciclo di vita parallelo e un approccio agile non potrà che essere diverso da quello che utilizza un ciclo di vita seriale; la gestione dei requisiti finalizzata ad una trasformazione del business sarà diversa da quella in ambito edilizio.
La individuazione dei requisiti può essere fatta nei modi più svariati, che vanno dalle interviste personali, ai sondaggi e workshop, fino ai focus group, alla modellazione e alla simulazione.
Alcune metodologie di sviluppo, compresa quella agile, sono progettate per rendere possibile la continua acquisizione e rifinitura dei requisiti, partendo dal presupposto che gli stakeholder all’inizio potrebbero non essere sicuri di quali siano i propri bisogni.
L’analisi dei requisiti comprende la ricerca di qualsiasi lacuna, sovrapposizione o conflitto fra ciò che hanno richiesto i vari stakeholder. Questo tipo di analisi necessiterà di un principio di sviluppo delle soluzioni, di pianificazione e di gestione dei benefici a grandi linee, per rendersi conto di quali siano le implicazioni dei requisiti. Il risultato è una comprensione accurata dei requisiti stessi e del modo in cui questi contribuiscono all’obiettivo complessivo.
Il passo della consultazione riguarda soprattutto il feedback agli stakeholder e la costruzione del consenso. I risultati dell’analisi sono comunicati attraverso consultazioni individuali o workshop di gruppo. Questo porta ad una discussione sulle funzionalità e genera idee alternative.
Dalla consultazione può emergere l’acquisizione e l’analisi di ulteriori requisiti. Il risultato eventuale è una gamma di opzioni baseline per i requisiti funzionali. Queste possono poi essere usate per esaminare soluzioni alternative durante il processo di sviluppo delle soluzioni.
Una tecnica ben affermata riguardo alla gestione dei requisiti, allo sviluppo delle soluzioni e ad alcuni aspetti della gestione dei benefici è la gestione del valore. Anche se il termine valore è soggettivo e ha significati diversi per persone differenti, nell’ambiente dei progetti, programmi e portfolio è un mezzo di massimizzazione del valore dell’investimento ed è rappresentato dal rapporto:
La finalità della gestione del valore non è di massimizzare la soddisfazione dei requisiti, né di minimizzare l’uso delle risorse, ma di stabilire il bilanciamento che massimizza il rapporto fra i due.
Progetti, programmi e portfolio
I requisiti iniziali del progetto sono definiti durante il processo di identificazione e richiedono solo quel minimo di dettaglio necessario a identificare la probabile soluzione e a completare il brief. La gestione dei requisiti è eseguita nel dettaglio durante il processo di definizione unitamente allo sviluppo delle soluzioni, per arrivare alla stesura di una valutazione dell’investimento e di un business case completi.
Nei progetti piccoli con obiettivi relativamente chiari queste attività possono essere compiute tutte dal project manager. Quando i requisiti diventano più complessi, c’è bisogno di coinvolgere degli specialisti. Anche nei progetti piccolo “la mancata piena comprensione dei requisiti degli stakeholder” è una delle cause più comuni del fallimento di un progetto. Questa non è quindi un’attività che può essere svolta in maniera casuale.
Per i progetti che fanno parte di un programma o che sono realizzati da un appaltatore per conto di un cliente, i requisiti discenderanno dai requisiti del programma o dal brief del cliente. I requisiti saranno correlati ad un prodotto e, in base a quanto bene sono descritti, può discenderne una riduzione dell’impegno necessario.
Qualora si abbia intenzione di utilizzare tecniche di tipo agile, la procedura di gestione dei requisiti deve essere efficiente e dinamica. Questa deve utilizzare un meccanismo di prioritizzazione rigoroso, del tipo MoSCoW, per assicurare che in ciascun pacchetto di lavoro siano inclusi solo requisiti validi e giustificabili.
Una questione da risolvere presto riguarda il fatto se i requisiti vengano espressi come prodotti, come risultati o come benefici. Questo aspetto determinerà se il progetto includerà la realizzazione dei benefici come parte di un ciclo di vita esteso del progetto stesso. Se i requisiti comprendono molteplici benefici che coinvolgono più di un’area di cambiamento del business e molti prodotti, il lavoro viene diretto meglio sotto forma di programma piuttosto che di progetto.
I requisiti del programma saranno espressi tipicamente come una combinazione di prodotti e benefici. Questi possono avere relazioni abbastanza complesse che possono essere descritte in una mappa dei benefici.
La relazione fra la gestione dei requisiti e le susseguenti funzioni di sviluppo delle soluzioni e di gestione dei benefici non è completamente sequenziale. Soprattutto nel processo di identificazione e nel processo di definizione del ciclo di vita, i requisiti degli stakeholder richiederanno una qualche quantificazione dei benefici e valutazione delle soluzioni a grandi linee prima di arrivare al complesso dei requisiti baseline. Il team di gestione del programma è responsabile di come la gestione dei requisiti si applica ai benefici del programma e deve decidere quanta parte di responsabilità della gestione dei requisiti dei prodotti di progetto sarà delegata ai team di progetto.
Un’utile linea di demarcazione fra il programma e i progetti è data dal fatto che il programma esprime i requisiti funzionali necessari per un prodotto. Spetta poi ai team di progetto gestire i requisiti tecnici che realizzeranno le funzionalità richieste.
Se utilizza la gestione del valore, il team di gestione del programma deve bilanciare il valore fra i vari progetti. Per esempio, la riprioritizzazione e la ridistribuzione delle risorse possono portare ad un valore complessivo maggiore per il programma, anche se questo può sottrarre valore ad un singolo specifico progetto.
Un portfolio standard è composto di progetti e programmi che hanno requisiti fra loro indipendenti. I requisiti del portfolio riguardano l’uso efficiente delle risorse per l’organizzazione sede e il miglioramento nella disciplina del Project, Programme e Portfolio management. Una volta che questi requisiti sono fissati nel processo di inizio del portfolio rimarranno abbastanza stabili.
I requisiti iniziali di un portfolio strutturato saranno espressi in termini di obiettivi strategici dell’organizzazione. Questi saranno una miscela di requisiti indipendenti e interrelati. La procedura di gestione dei requisiti di un portfolio strutturato valuta gli obiettivi strategici e li chiarisce con il consiglio di amministrazione.
La valutazione dei requisiti partirà durante il processo di inizio del portfolio. Si dovrebbero identificare gli obiettivi correlati che potrebbero essere riuniti all’interno di un programma con obiettivi indipendenti realizzati attraverso progetti. L’attività di progettazione sarà costantemente rivista come parte delle attività di prioritizzazione e bilanciamento nell’ambito del processo di gestione del portfolio.
Gran parte dell’attività di gestione dei requisiti sarà delegata ai team di gestione del progetto e del programma, ma il team di gestione del portfolio deve eseguire due funzioni chiave.
In primo luogo, deve agire da interfaccia fra i progetti e i programmi da una lato e il consiglio di amministrazione che è titolare della strategia dall’altro. Per conto del consiglio di amministrazione, il team di gestione del portfolio deve assicurare che i requisiti siano correttamente tradotti in progetti e programmi. Per conto dei team di gestione del progetto e del programma, deve assicurare che i requisiti strategici siano definiti in maniera adeguata in modo tale che i progetti e i programmi abbiano informazioni sufficienti per realizzare i corretti prodotti e benefici.
In secondo luogo, deve coordinare i progetti e i programmi per assicurare che i tanti specifici processi di gestione dei requisiti lavorino in armonia. Questo aspetto è parte del processo di coordinamento del portfolio e può comprendere l’assunzione di una responsabilità centrale per trattare con gli stakeholder. Esso riguarda in definitiva l’esame dei requisiti dettagliati del progetto e del programma per monitorare lacune, sovrapposizioni e conflitti.
Grazie a E-quality Italia e a Project Management Europa per la traduzione
