Aspetti generali
Lo sviluppo delle soluzioni stabilisce il modo migliore per soddisfare i requisiti di un prodotto. Le sue finalità sono:
- valutare i requisiti baseline e le soluzioni alternative per ottenerli;
- selezionare la soluzione ottimale;
- creare una specifica della soluzione.
La gestione dei requisiti produce un insieme chiaro dei requisiti degli stakeholder ma non spiega come soddisfare tali requisiti. Lo sviluppo delle soluzioni studia le opzioni tecniche per la soddisfazione dei requisiti e lavorerà congiuntamente alla valutazione dell’investimento per sviscerare le implicazioni finanziarie delle diverse opzioni.
Proprio come qualsiasi altra funzione, lo sviluppo delle soluzioni ha bisogno di una pianificazione e di un inizio. Poiché i passi dello sviluppo delle soluzioni seguono logicamente quelli della procedura di gestione dei requisiti, sarebbe insolito che avessero fasi di pianificazione e inizio separate. Tuttavia, potrebbe accadere per particolari situazioni contrattuali che la gestione dei requisiti e lo sviluppo delle soluzioni siano sotto la responsabilità di organizzazioni differenti, nel qual caso le procedure saranno separate.
La fase di esame studia gli approcci alternativi e valuta quanto saranno buone le loro prestazioni rispetto ai criteri stabiliti, come il costo di investimento, la velocità di consegna e il grado di rischio. Le tecniche utilizzate variano da semplici considerazioni di realizza o acquista fino alla vera e propria modellazione e simulazione di soluzioni innovative. Per aiutare nella scelta delle opzioni di miglior valore può essere utilizzato un approccio di gestione del valore.La verifica dei prodotti è parte del controllo di qualità e della gestione della configurazione. La validazione è simile ad una continua conferma del fatto che gli obiettivi restano giustificabili così come stabilito nel business cas
Quando dall’esame viene fuori una soluzione che viene selezionata come quella ottimale, la stessa verrà sviluppata in una specifica. In alcuni casi gli elementi dettagliati della specifica copriranno solo le prime fasi dello sviluppo, mentre quelle successive saranno rifinite man mano che il lavoro va avanti. Lo sviluppo di proposte che migliorano il valore può avere luogo in qualunque fase del processo di consegna.
La soluzione dovrà essere controllata regolarmente rispetto ai requisiti (che possono essere loro stessi soggetti a cambiamenti). Questo controllo assume due forme. Si usa il termine ‘verifica’ quando si deve assicurare che si sta costruendo la soluzione giusta; si usa il termine ‘validazione’ quando si deve assicurare che si sta costruendo il prodotto giusto. La verifica attiene alle specifiche; la validazione attiene ai requisiti.
Progetti, programmi e portfolio
La grande maggioranza dei progetti è chiamata a consegnare un prodotto e null’altro. Laddove i requisiti sono relativamente semplici, e si usa una tecnologia provata e testata, il tipo di soluzione sarà compreso implicitamente dagli stakeholder e dal team di gestione; per esempio, il mio requisito è di tenere la mia macchina all’asciutto e fuori dalla strada – la soluzione è costruire un garage.
Lo sviluppo delle soluzioni diventa allora semplicemente la produzione di una specifica senza farla precedere da considerazioni sulle opzioni, come potrebbero essere affittare un garage o vendere la macchina e spostarsi in autobus. Il project manager dovrà giudicare in quale misura si dovranno mettere in dubbio gli assunti degli stakeholder per suggerire soluzioni più radicali.
I progetti tradizionali descrivono il prodotto con una specifica. Questa è contenuta nella documentazione di definizione e sottoposta all’approvazione alla fine del processo di definizione. La specifica può essere supportata da informazioni aggiuntive come una struttura di scomposizione del prodotto o del lavoro.
I metodi agile danno molta meno importanza alla specifica dettagliata di una soluzione all’inizio del ciclo di vita.
Viceversa, si concentrano sulle funzioni ordinate per priorità, da realizzare in maniera incrementale in una serie di time box o sprint. Il dettaglio del prodotto evolve durante le iterazioni e risolve il problema tipico dei progetti IT, nei quali è difficile per uno stakeholder accettare le componenti del sistema prima di vederlo realmente in azione.
L’equivalente della specifica per un programma di cambiamento di business è il blueprint. Questo descrive l’effetto cumulativo del cambiamento sull’organizzazione. È un quadro di tutti i prodotti creati dal programma.
Ciascun progetto all’interno del programma punta a consegnare un prodotto che contribuisce al blueprint. Nella maggior parte dei casi il grado di dettaglio del blueprint lascerà ampio spazio alla considerazione da parte dei team di gestione del progetto di soluzioni alternative per i prodotti richiesti. Tuttavia, il team di gestione del programma deve coordinare le soluzioni di progetto e rivedere le proposte. Ci saranno degli elementi come i componenti comuni e le piattaforme tecnologiche che possono essere trasferiti da un progetto all’altro, per cui dovrà essere controllata la compatibilità delle soluzioni proposte dai diversi progetti.
Lo sviluppo delle soluzioni è prevalentemente materia del progetto e del programma, ma in ogni caso il team di gestione del portfolio può fissare un insieme di linee guida circa l’innovazione e il rischio che vincolano i tipi di soluzione considerati.
Grazie a E-quality Italia e a Project Management Europa per la traduzione
