Il project management (gestione di progetto) corrisponde all'applicazione di conoscenze (knowledge), capacità (skills), strumenti (tools) e tecniche alle attività di progetto per soddisfare i requisiti (requirements).
Wysocki ne dà due, complementari. La prima è operativa e ha la forma di una lista di domande:
Il project management corrisponde a un insieme di strumenti, template e processi studiati per rispondere alle seguenti domande: quale situazione aziendale affronta il progetto? Cosa hai bisogno di fare? Cosa farai? Come lo farai? Come saprai che lo hai fatto? Quanto bene lo hai fatto?
Il project management è un approccio organizzato basato sul «buon senso» (organized common-sense approach) che deve prevedere un adeguato coinvolgimento del cliente al fine di soddisfare i requisiti definiti fornendo l'incremento di business value atteso.
Che cosa intende Wysocki per common-sense approach? Sintetizzando in modo estremo: bisogna sempre adattare l'approccio alla situazione specifica e, soprattutto, al cambiamento. Sul resto la sua posizione è netta e vale la pena discuterla:
| Chi | Di che cosa è responsabile |
|---|---|
| Il cliente | Della definizione del business value, attraverso la specifica dei requisiti. (Siete d'accordo?) |
| Il project manager | Del soddisfacimento dei requisiti, che ha come effetto l'incremento di business value. |
Le sei domande non sono un elenco retorico: percorrono l'intero ciclo di vita del progetto, e ciascuna corrisponde a un blocco di lavoro reale.
La situazione può consistere in un problema da risolvere o in un'opportunità non ancora sfruttata. Se è un problema, va definito chiaramente quale soluzione deve essere fornita; se è un'opportunità, vanno definite chiaramente le modalità con cui la si vuole cogliere.
In molte situazioni non è possibile definire con precisione la soluzione (deliverable) in fase di pianificazione. In questo caso si dovrà scegliere un approccio che consenta iterativamente di acquisire conoscenza sul problema/opportunità e scoprire quale sia la soluzione da fornire. I progetti in cui non è chiaro il deliverable atteso sono ad alto rischio: nonostante l'impegno del cliente e del team, la soluzione potrebbe non essere trovata e il progetto può fallire.
Il deliverable, per soddisfare i criteri di successo stabiliti, deve fornire business value. Il business value a cui si fa riferimento può corrispondere a:
| Componente | Significato | Esempio di metrica |
|---|---|---|
| Increased Revenue | Aumento del fatturato e/o dei margini | aumentare il fatturato del 5% |
| Avoided Cost | Riduzione dei costi | ridurre i costi del 4% |
| Improved Service | Miglioramento del livello di servizio | ridurre i tempi di attesa di un giorno |
Si consiglia di esprimere quantitativamente le componenti del business value: devono essere misurabili. (Nel capitolo 7 questa terna ritorna con l'acronimo IRACIS tra i criteri di successo del POS.)
L'analisi retrospettiva di un progetto è fondamentale per il processo di miglioramento continuo di un'organizzazione. Le domande a cui rispondere sono quattro:
(A) A condition or capability needed by a user (stakeholder) to solve a problem or achieve an objective (scope).
(B) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents (solution).
(C) A documented representation of a condition or capability as in definition (A) and (B).
La stessa definizione è stata fornita anche dall'International Institute of Business Analysis (IIBA) nel testo A Guide to the Business Analysis Body of Knowledge. Wysocki però ne propone una diversa, molto più selettiva:
Un requisito è uno stato finale desiderato, la cui integrazione con successo nella soluzione fornisce all'organizzazione un aumento specifico e misurabile di business value.
Il valore di questa definizione sta nelle sue conseguenze pratiche:
Wysocki sottolinea infine che «it is a working definition»: una definizione di lavoro, non un dogma.
Il ciclo di vita della gestione di un progetto è modellato utilizzando una sequenza di processi che possono essere raggruppati in cinque gruppi: Initiating/Scoping (definizione dell'ambito), Planning (pianificazione), Launching/Execution (avvio ed esecuzione), Monitoring & Controlling (monitoraggio e controllo), Closing (chiusura).
I cinque gruppi contribuiscono al raggiungimento degli obiettivi del progetto e devono comparire almeno una volta nella sequenza. Alcuni di essi possono essere ripetuti anche più volte: è proprio questa libertà di ripetizione che genera i diversi modelli PMLC. Il dettaglio dei cinque gruppi è il contenuto del capitolo 5.
La scelta dell'approccio si fa su una matrice a due variabili: il goal è chiaro o no? La soluzione è chiara o no? Ne escono quattro quadranti, ciascuno con il proprio nome.
Rispondi alle due domande e leggi il quadrante corrispondente.
Dai quattro quadranti si passa a cinque modelli di ciclo di vita: Linear, Incremental, Iterative, Adaptive, Extreme. Fra loro ci sono somiglianze forti e differenze sistematiche.
| Somiglianze |
|---|
| Tutti e cinque i gruppi di processi sono usati in ogni PMLC Model. |
| Ogni PMLC Model inizia con lo Scoping Process Group. |
| Ogni PMLC Model finisce con il Closing Process Group. |
Le differenze seguono un ordine naturale rispetto al grado di incertezza della soluzione — Linear, Incremental, Iterative, Adaptive, Extreme — e all'aumentare di tale incertezza succedono quattro cose insieme.
All'aumentare dell'incertezza sulla soluzione da fornire: 1) il numero di gruppi di processi che devono essere ripetuti aumenta; 2) la pianificazione completa tradizionale del progetto è sostituita da una pianificazione just-in-time; 3) la gestione del rischio (risk management) diventa progressivamente significativa; 4) il bisogno di coinvolgere il cliente direttamente nel progetto aumenta progressivamente.
Nel capitolo 6 vedremo che il criterio operativo per scegliere il modello è uno solo: il grado di completezza della RBS (o del backlog). La matrice goal/solution è la teoria; la RBS incompleta è il termometro che si legge davvero.
Il caso PDQ, proposto da Wysocki in Effective Project Management: Traditional, Agile, Extreme, accompagna il corso e le esercitazioni. Vale la pena leggerlo bene, perché è costruito apposta perché un solo progetto contenga sottosistemi di natura profondamente diversa.
Pizza Delivered Quickly (PDQ) è una catena locale di 40 punti vendita di pizza, con consumo sul posto e consegna a domicilio. Recentemente PDQ ha perso il 30% del fatturato, in gran parte per un calo della consegna a domicilio, attribuito interamente al principale concorrente, che ha promosso un programma che garantisce la consegna in 45 minuti dall'inserimento dell'ordine; PDQ pubblicizza invece la consegna in un'ora. PDQ usa i computer per le operazioni di negozio e le usuali funzioni aziendali, ma per il resto non dipende in modo significativo da sistemi software per ricevere, elaborare e consegnare gli ordini.
Pepe Ronee, Supervisor of Computer Operations, è stato incaricato di sviluppare un'applicazione software per individuare le posizioni delle «pizza factory» e di creare il sistema software necessario a farle funzionare. Nel commissionare il progetto, la presidente Dee Livery ha detto di non risparmiare nulla, aggiungendo che il futuro di PDQ dipende da questo progetto. Vuole che il team studi l'opzione di consegnare la pizza cruda e «pronta per il forno» in 30 minuti o meno, oppure già cotta in 45 minuti o meno.
Le pizza factory non avranno spazi di vendita al dettaglio: la loro unica funzione sarà ricevere ordini, preparare e consegnare le pizze. La factory più vicina al cliente riceverà l'ordine da una struttura di ordinazione centralizzata e lo evaderà entro 30 o 45 minuti dall'inserimento, a seconda della scelta del cliente.
| Sottosistema | Che cosa dice il caso |
|---|---|
| Pizza Factory Locator | Deve trovare le posizioni delle pizza factory. Non si sa quante ne servano né dove vadano collocate: dovrà determinarlo il software. Applicazione molto complessa: il goal può essere definito chiaramente, ma la soluzione non sarà affatto ovvia. Richiede uno strumento di modellazione molto sofisticato; requisiti, funzionalità e feature non sono per nulla ovvi. Una parte della soluzione si può immaginare, ma nel complesso è sfuggente in questa fase iniziale: come modellarla non è noto all'inizio, dovrà essere scoperto mentre il progetto avanza. |
| Order Entry | Supporta le operazioni di negozi e factory. Gli ordini telefonici arrivano a una sola sede, vengono presi lì e poi instradati elettronicamente al negozio o alla factory appropriata. Si concentra su funzioni aziendali di routine e dovrebbe essere facilmente definibile; software commerciale COTS (commercial off the shelf) può costituire buona parte della soluzione finale, da potenziare sul front end per indirizzare l'ordine alla factory più vicina e sul back end per fornire le indicazioni stradali e altri compiti di evasione. I requisiti, le funzionalità e le feature di questo sottosistema potrebbero però risultare problematici. |
| Order Submit | Indirizza l'ordine a un negozio, a una factory o a un pizza van. La logistica di questa assegnazione non è per nulla chiara e la progettazione del sottosistema sarà complessa. |
| Logistics | Il più complesso dei sei. Richiede una visione olistica dell'intero sistema PDQ. La complessità nasce dal fatto che i pizza van sono una struttura mobile di produzione e consegna: assegnare un ordine a un van richiede di tenere conto di dove il van si troverà probabilmente al momento della consegna. |
| Routing | Instradamento dei mezzi di consegna. Applicazione lineare, che probabilmente comporterà l'installazione di sistemi GPS su tutti i furgoni. |
| Inventory Management | Controllo delle scorte in tutti i negozi e le factory, con riordino automatico dall'unico fornitore che PDQ usa dall'inizio dell'attività. Il fornitore ha comunicato che si possono ottenere sconti usando il riordino automatico. Anche questa dovrebbe essere un'applicazione COTS. |
Per ciascun sottosistema di PDQ, scegli il quadrante. Il riscontro riporta l'indizio del testo su cui si fonda il ragionamento.
Le sei applicazioni sono ovviamente progetti di sviluppo software molto diversi tra loro, che richiedono approcci molto diversi. È il motivo per cui il caso è usato per tutto il corso: costringe a smettere di cercare «il metodo» e a scegliere un metodo per ogni pezzo.
Il project manager è la persona incaricata dall'organizzazione di guidare il team responsabile del raggiungimento degli obiettivi del progetto. Il suo ruolo è distinto da quello di functional manager o operations manager; a seconda della struttura organizzativa, i project manager dipendono da manager funzionali oppure da program o portfolio manager responsabili dei progetti a livello aziendale. Collabora inoltre con altri ruoli: business analyst, quality assurance manager, architetti, esperti di dominio.
I progetti sono essenziali per la crescita e la sopravvivenza delle aziende: creano valore sotto forma di processi aziendali migliorati, sono indispensabili per lo sviluppo di nuovi prodotti e servizi e consentono di rispondere più facilmente ai cambiamenti imposti dal mercato e dall'ambiente esterno. Poiché il project management è una disciplina fondamentale per perseguire la strategia aziendale, il project manager diventa il collegamento tra il team e i vertici aziendali che governano la strategia.
| Caratteristica | Significato |
|---|---|
| Knowledge | Il project manager conosce il project management. |
| Performance | Il project manager è capace di applicare la conoscenza del project management. |
| Personal | Il project manager deve sapere come comportarsi durante un progetto, oltre a conoscere e saper applicare le buone pratiche: in particolare deve saper gestire i rapporti interpersonali e possedere i soft skill importanti per guidare il team. |
Gli skill interpersonali principali sono dieci: leadership, team building, motivazione, comunicazione, capacità di influenzare, capacità decisionale, consapevolezza politica e culturale, negoziazione, gestione dei conflitti, coaching.
Notate la struttura: Knowledge (sa), Performance (sa fare), Personal (sa stare con gli altri). Le prime due si imparano dai libri; la terza, che è quella su cui i progetti falliscono davvero, è la lista dei dieci skill interpersonali.
«Il project management corrisponde all'applicazione di conoscenze (knowledge), capacità (skills), strumenti (tools) e tecniche alle attività di progetto per soddisfare i requisiti.» Wysocki aggiunge la dimensione mancante nella sua seconda definizione: è un approccio organizzato basato sul buon senso, che deve prevedere un adeguato coinvolgimento del cliente per soddisfare i requisiti fornendo l'incremento di business value atteso.
1) Quale situazione aziendale affronta il progetto? 2) Cosa hai bisogno di fare? 3) Cosa farai? 4) Come lo farai? 5) Come saprai che lo hai fatto? 6) Quanto bene lo hai fatto? La quinta si risponde con il business value misurabile (IR/AC/IS), la sesta con l'analisi retrospettiva.
Sono le tre forme in cui può presentarsi il business value: aumento del fatturato e/o dei margini; riduzione dei costi; miglioramento del livello di servizio. Vanno espresse quantitativamente e devono essere misurabili: «aumentare il fatturato del 5%», «ridurre i costi del 4%», «ridurre i tempi di attesa di un giorno».
«Un requisito è uno stato finale desiderato, la cui integrazione con successo nella soluzione fornisce all'organizzazione un aumento specifico e misurabile di business value.» Il numero crolla perché la maggior parte di ciò che di solito viene chiamato requisito non porta con sé un incremento misurabile di business value: sono funzioni, sotto-funzioni o feature, che nella RBS staranno ai livelli inferiori. La definizione contempla inoltre che la definizione completa si ottenga iterando, limita la ricerca alle soluzioni che forniscono sufficiente business value e consente un miglior uso delle risorse limitate.
Initiating/Scoping, Planning, Launching/Execution, Monitoring & Controlling, Closing. Devono comparire almeno una volta nella sequenza, e alcuni possono essere ripetuti più volte. Ogni PMLC model li usa tutti e cinque, inizia con lo Scoping e finisce con il Closing.
TPM (Traditional Project Management): goal chiaro, soluzione chiara — esempio: installare un prodotto software standard. APM (Agile Project Management): goal chiaro, soluzione non chiara — esempio: realizzare un sistema di e-commerce. xPM (Extreme Project Management): goal non chiaro, soluzione non chiara — esempio: realizzare un nuovo prodotto innovativo. MPx (Emertxe Project Management): goal non chiaro, soluzione chiara — esempio: trovare un impiego per una nuova tecnologia sviluppata. «Emertxe» è «extreme» al contrario e si dovrebbe pronunciare «E-murt-see».
Quattro cose insieme: aumenta il numero di gruppi di processi ripetuti; la pianificazione completa tradizionale è sostituita da una pianificazione just-in-time; il risk management diventa progressivamente più significativo; aumenta progressivamente il bisogno di coinvolgere il cliente direttamente nel progetto. L'ordine naturale dei modelli rispetto all'incertezza è: Linear, Incremental, Iterative, Adaptive, Extreme.
Iterative: obiettivo noto e stabile, ma requisiti instabili o incompleti; si apprende mentre si implementa, approfondendo la conoscenza dei bisogni del committente; alcune feature non sono ancora identificate. Adaptive: l'obiettivo è noto ma non la soluzione, che è nota solo parzialmente ed è fortemente influenzata dai cambiamenti attesi; ci si aspetta un certo numero di richieste di modifica dal cliente; tipico dello sviluppo di nuovi prodotti o del miglioramento dei processi, con schedula stretta che non consente rilavorazioni.
PDQ è una catena locale di 40 punti vendita di pizza (sul posto e a domicilio) che ha perso il 30% del fatturato, soprattutto sulla consegna a domicilio, a causa di un concorrente che garantisce la consegna in 45 minuti contro l'ora pubblicizzata da PDQ. Pepe Ronee deve individuare le posizioni delle «pizza factory» e creare il sistema per farle funzionare; la presidente Dee Livery vuole che si valuti la consegna della pizza cruda «pronta per il forno» in 30 minuti o meno o già cotta in 45 minuti o meno. Le factory non hanno spazi di vendita: ricevono l'ordine da una struttura di ordinazione centralizzata, preparano e consegnano.
Il Locator perché non si sa quante factory servano né dove collocarle — deve determinarlo il software: il goal può essere definito chiaramente, ma la soluzione non è affatto ovvia, richiede uno strumento di modellazione molto sofisticato, e come modellare non è noto all'inizio: dovrà essere scoperto mentre il progetto avanza. Il Logistics è dichiarato il più complesso dei sei: richiede una visione olistica dell'intero sistema, perché i pizza van sono una struttura mobile di produzione e consegna e l'assegnazione di un ordine deve tener conto di dove il van si troverà al momento della consegna.
L'Order Entry (software commerciale COTS può costituire buona parte della soluzione, da potenziare sul front end per instradare l'ordine alla factory più vicina e sul back end per le indicazioni stradali e gli altri compiti di evasione — anche se i suoi requisiti «potrebbero risultare problematici») e l'Inventory Management (controllo scorte con riordino automatico dall'unico fornitore, che offre sconti proprio per il riordino automatico).
Knowledge: conosce il project management. Performance: è capace di applicare quella conoscenza. Personal: sa come comportarsi durante un progetto, gestisce i rapporti interpersonali e possiede i soft skill per guidare il team. Gli skill interpersonali principali sono leadership, team building, motivazione, comunicazione, capacità di influenzare, capacità decisionale, consapevolezza politica e culturale, negoziazione, gestione dei conflitti, coaching.