Il Project Management Body of Knowledge (PMBOK) è uno standard riconosciuto per la professione del project manager. Uno standard è un documento formale che descrive norme, metodi, processi e pratiche consolidate; come avviene in altre professioni, l'insieme delle conoscenze contenute nel PMBOK si è evoluto a partire dalle buone pratiche riconosciute dai professionisti che hanno contribuito al suo sviluppo. Il PMBOK è approvato da ANSI, e la Guida fornisce le linee guida per gestire singoli progetti.
Esistono alternative: per esempio PRINCE2 (PRojects IN a Controlled Environment) o una delle numerose proposte Agile (Scrum, Kanban…). Il corso si concentra, per il momento, sul PMBOK edizione 6.
| Espressione | Che cosa significa nel PMBOK |
|---|---|
| Generalmente riconosciuto | Le conoscenze e le pratiche descritte sono applicabili alla maggior parte dei progetti e c'è consenso generale sul loro valore e utilità. |
| Buona prassi | C'è accordo generale sul fatto che il corpo di conoscenze proposto può incrementare le possibilità di successo su un'ampia gamma di progetti. |
Il corpo di conoscenze non deve essere applicato in modo uniforme a tutti i progetti, ma adattato a ogni specifico progetto. E il PMBOK è un riferimento base: non è completo né esaustivo. Il suo contributo forse più concreto è un altro — fornire e promuovere un vocabolario comune nell'ambito della professione.
Un progetto è un'iniziativa temporanea intrapresa per creare un prodotto, un servizio o un altro risultato con caratteristiche di unicità.
Due parole reggono tutto il peso. Temporanea: i progetti hanno un inizio e una fine definiti. La fine si raggiunge quando sono stati ottenuti gli obiettivi del progetto, oppure quando il progetto è terminato perché non si riesce a raggiungere tali obiettivi (anche perché non più possibile), oppure quando non sussiste più l'esigenza del progetto. Attenzione però: «temporaneo» non indica necessariamente una breve durata e generalmente non si applica al prodotto, servizio o risultato creato — anzi, la maggior parte dei progetti crea un risultato durevole nel tempo.
Unicità: ogni progetto crea un prodotto, un servizio o un qualsiasi altro risultato che è unico. Elementi ripetitivi possono comparire nei processi e nei deliverable di alcuni progetti, ma questo non modifica la fondamentale unicità del lavoro svolto.
Un progetto è una sequenza unica, complessa e connessa di attività che hanno un obiettivo (goal/purpose) e devono essere completate rispettando le specifiche e i vincoli di tempo e di budget.
Un progetto potrebbe infatti rispettare le specifiche e i vincoli di tempo e budget, e nonostante ciò il risultato finale potrebbe non soddisfare il cliente. Per evitare questa situazione è necessario considerare anche il business value: il valore percepito dal destinatario del prodotto, servizio o altro risultato creato dal progetto (cioè della soluzione).
Definizione di Wysocki focalizzata sul business value: un progetto è una sequenza finita di attività dipendenti tra loro, il cui completamento con successo si traduce nella fornitura del business value atteso. Durante il corso il concetto di business value sarà centrale.
Un progetto non deve essere confuso con un processo aziendale, e un'attività di progetto non deve essere confusa con un'attività operativa. Le definizioni di riferimento vengono dalla WorkFlow Management Coalition (WfMC).
«A description of a piece of work that forms one logical step within a process. An activity may be a manual activity, which does not support computer automation, or a workflow (automated) activity.»
«A workflow activity requires human and/or machine resource(s) to support process execution; where human resource is required an activity is allocated to a workflow participant.»
Un'attività operativa è un impegno di lavoro continuo che generalmente corrisponde a un processo ripetitivo, che segue le procedure esistenti in un'organizzazione (i processi aziendali, business processes). I processi aziendali e le loro attività sono predefinite e devono essere sempre eseguite nello stesso modo: ogni possibile opzione è già stata predeterminata.
Un'attività di progetto identifica del «lavoro» che deve essere svolto e che ha caratteristiche di unicità, ed è inserito in un processo anch'esso unico e specifico per ogni progetto.
L'automobile. Consideriamo un progetto per una nuova automobile, il suo impianto di produzione, il relativo servizio di assistenza clienti. Avremo poi dei processi aziendali (attività operative) per produrre ogni auto impiegando l'impianto, per consegnare l'auto al cliente, per fornire i ricambi per la manutenzione. Ma se vogliamo fare un restyling dell'auto oppure migliorare il servizio clienti, dobbiamo iniziare un nuovo progetto.
Il ristorante. Serve un progetto per realizzare un nuovo ristorante, la sua cucina, il sistema di prenotazione, il servizio take-away; servono processi aziendali per raccogliere gli ordini, preparare le portate, consegnare gli ordini, gestire le prenotazioni. E il menu? La domanda è più sottile di quanto sembri:
Alcuni approcci possono combinare attività operative (Operations) e di progetto (Development): è esattamente il caso di DevOps, che ritroveremo nel capitolo 12.
Classifica ciascun caso. Il discrimine è sempre lo stesso: le opzioni sono già tutte predeterminate?
Il risultato di un progetto non è per forza un prodotto finito. Può essere:
Altri esempi di progetti (elenco non esaustivo): apportare cambiamenti o miglioramenti a un'organizzazione modificando struttura, processi e personale; implementare o migliorare un processo aziendale; sviluppare, acquisire o aggiornare un nuovo Sistema Informativo (hardware e/o software); svolgere una ricerca per creare un brevetto, scrivere una pubblicazione scientifica, individuare nuovi materiali; costruire un edificio, un impianto industriale, un'infrastruttura.
Un programma è un insieme di progetti correlati, gestiti in modo coordinato al fine di ottenere benefici e un controllo non possibili nella gestione individuale dei singoli progetti.
Un portfolio è un insieme di progetti o programmi che vengono raggruppati solo per facilitare la gestione efficace ed efficiente del lavoro complessivo, per raggiungere gli obiettivi strategici dell'azienda.
I programmi possono contenere elementi di lavoro correlati ma esterni all'ambito dei singoli progetti che li compongono. I progetti di un programma sono collegati da un risultato comune o da una specifica caratteristica comune: l'esempio classico è il Programma Apollo, che ha portato il primo uomo sulla Luna. Spesso i progetti di un programma concorrono a creare le «componenti» di un certo risultato finale — il risultato del programma.
Il program management consiste nella gestione centralizzata e coordinata dei progetti di un programma per il raggiungimento di obiettivi e benefici strategici, e si focalizza sulle interdipendenze tra progetti, aiutando a determinare l'approccio ottimale per gestirle. Le azioni relative alle interdipendenze possono includere:
Se la relazione esistente tra i progetti è solo quella della condivisione di un cliente, di un fornitore, di una tecnologia o di una risorsa, allora non si dovrà gestire un programma, ma un portfolio.
Nel portfolio, infatti, i progetti e i programmi possono non essere interdipendenti né direttamente collegati. Possono appartenere allo stesso portfolio, per esempio: progetti assegnati alla stessa business unit; progetti di sviluppo di nuovi prodotti e/o R&S; progetti di miglioramento dei processi aziendali; progetti assegnati alle stesse risorse; progetti con lo stesso budget.
I progetti sono spesso utilizzati come mezzo per realizzare il piano strategico di un'organizzazione. Sono solitamente autorizzati come risultato di una o più delle seguenti considerazioni strategiche:
| Origine | Esempio tipico |
|---|---|
| Richiesta del mercato | Un segmento chiede una funzionalità che oggi non esiste. |
| Richiesta di un cliente | Una commessa specifica. |
| Opportunità o esigenze aziendali | Un'occasione da cogliere o un bisogno interno. |
| Progresso tecnologico | Una tecnologia rende possibile ciò che prima non lo era. |
| Requisiti legali | Un adeguamento normativo obbligatorio. |
| Soluzione di «problemi» | Un malfunzionamento o un'inefficienza da rimuovere. |
Lo scope (ambito) di un progetto definisce i confini del progetto in termini di ciò che deve essere fatto e ciò che non deve essere fatto.
| Tipo | A che cosa si riferisce |
|---|---|
| Qualità del prodotto | Alla qualità del deliverable del progetto. «Prodotto» può essere un bene tangibile come un software, ma anche processi aziendali o altro. |
| Qualità del processo | Alla qualità dei processi di gestione del progetto, ma anche dei processi di produzione. Qui si vuole misurare la bontà dei processi per individuare eventuali miglioramenti. |
La corretta gestione della qualità — del prodotto e del processo — permette di garantirsi la soddisfazione del cliente e consente all'organizzazione (software house o altro) di usare le proprie risorse in modo più efficace ed efficiente, riducendo sprechi e revisioni.
Lo scope triangle — noto anche come iron triangle, triple constraint, triangle of constraints, project management triangle — è un sistema che deve essere mantenuto in equilibrio.
Il concetto di scope triangle aiuta a ripristinare l'equilibrio attraverso due strumenti:
Il cliente chiede una variazione. Regola i tre lati e osserva che cosa succede all'area, cioè a scope e qualità.
Lo scope triangle permette di porsi una domanda operativa: «Who owns what?». La risposta individua il percorso di soluzione, che può partire dal team di progetto, passare dal manager che gestisce le risorse e arrivare fino al cliente.
| Chi | Che cosa possiede |
|---|---|
| Cliente e senior management | Il controllo del tempo, del budget e delle risorse. |
| Team di progetto | La conoscenza di come sono usati il tempo, il budget e le risorse. |
Da questa asimmetria discende una scala a tre gradini, da percorrere nell'ordine.
L'ordine non è burocrazia: ogni gradino consuma credibilità. Chi arriva al cliente al primo problema non avrà argomenti quando il problema sarà serio. Questa scala verrà ripresa e dettagliata nel capitolo 11, dove diventa la escalation strategy hierarchy del monitoring & controlling.
Nel contesto del project management il termine creeps identifica tutti quei cambiamenti, tanto impercettibili quanto insidiosi, che si possono riscontrare in un progetto e che sono spesso dovuti all'azione dei membri del team stesso. Spesso ci si rende conto di questi cambiamenti solo quando nel tempo si accumulano gli effetti. Wysocki ne individua quattro di cui bisogna essere consapevoli per poterli gestire.
Si riferisce a ogni cambiamento nel progetto rispetto a quanto previsto nel piano originario. Poiché «il cambiamento è una costante», è necessario prepararsi a gestirlo. Le modifiche di scope possono avere ragioni diverse, alcune delle quali non sono dovute a negligenze del cliente, del project manager o dei membri del team: alcune possono essere decise per far fronte a cambiamenti del mercato, come la disponibilità di nuove tecnologie o nuove versioni dei prodotti dei concorrenti.
Il classico esempio è il membro del team che, trovandosi in ritardo rispetto a quanto pianificato, nasconde la situazione e dichiara che sta rispettando i tempi previsti. È una situazione molto ricorrente, perché nessuno vuole dare brutte notizie al project manager: si nasconde la situazione convinti di poter recuperare nei giorni o nelle settimane successive. Purtroppo, solitamente non si riesce a recuperare e la situazione può anche peggiorare (ricordate: Effort ≠ Progress). Il project manager deve monitorare con molta attenzione lo stato di avanzamento e usare strumenti efficaci.
Si incorre in effort creep quando un membro del team non ha una produttività adeguata, cioè non ottiene progressi proporzionati alla quantità di lavoro fatto. Per esempio: viene riportato un completamento dell'attività al 95%, e nella settimana successiva non ci sono ancora progressi e l'attività continua a non essere completata. Escludendo di essere incorsi in un hope creep, le cause probabili sono errato monitoraggio dell'attività, scarsa organizzazione del lavoro, inesperienza, incapacità.
È strettamente correlata allo scope creep, ma riguarda più un comportamento scorretto di un membro del team. Mentre lo scope creep è spesso intenzionale e necessario per conservare o aumentare il business value, la feature creep riguarda l'aggiunta di funzionalità non concordata con cliente, project manager e architetto (o concordata solo con alcuni di essi). Il membro del team le aggiunge convinto che possano essere utili al cliente, ma spesso non è così: se il cliente non ha chiesto delle funzionalità a volte c'è un motivo; l'applicazione può diventare inutilmente complicata; l'aggiunta ha un costo aggiuntivo che, con tutta probabilità, nessuno riconoscerà.
Se un membro del team è convinto che sia assolutamente necessario aggiungere una funzionalità, deve richiedere l'autorizzazione, seguendo un iter ben preciso definito dal project manager. L'autorizzazione dovrà essere concessa: dal project manager per gli aspetti gestionali; dall'architetto per gli aspetti architetturali (tra cui la conservazione dell'integrità concettuale); dal cliente, che potrebbe anche accettare di riconoscere un valore economico alla nuova funzionalità.
Un caso alla volta: quale dei quattro creeps stai osservando?
Wysocki sostiene che chi pensa di adottare un approccio unico valido per tutti i progetti è semplicemente in cerca di guai. L'approccio da utilizzare per gestire ciascun progetto deve essere definito e adattato alle caratteristiche peculiari del progetto — e classificare i progetti può essere molto utile per fare la scelta corretta.
I progetti possono essere classificati in molti modi. Per esempio:
Un esempio di classificazione rispetto al tipo, in ambito informatico: sviluppo di un'applicazione; installazione di software; installazione di hardware presso un'azienda; software selection (individuare i fornitori, raccogliere le offerte, valutare e selezionare); aggiornamento delle procedure aziendali; reclutamento e assunzione di personale.
Si possono anche classificare i progetti in base alla complessità o al livello di incertezza, oppure rispetto alle loro caratteristiche: rischio (alto, medio, basso); business value (livelli); durata (categorie, per esempio 3 mesi, 3–6 mesi…); complessità (livelli); tecnologia impiegata (standard, usata occasionalmente, usata raramente, mai usata); numero di reparti impegnati (uno, pochi, numerosi, tutti); costi (livelli).
| Classe | Durata | Rischio | Complessità | Tecnologia | Probabilità di problemi |
|---|---|---|---|---|---|
| Type A | > 18 mesi | High | High | Breakthrough | Certain |
| Type B | 9–18 mesi | Medium | Medium | Current | Likely |
| Type C | 3–9 mesi | Low | Low | Best of Breed | Unlikely |
| Type D | < 3 mesi | Very Low | Very Low | Practical | Few |
La classificazione ha una conseguenza operativa immediata: seleziona i processi di gestione da eseguire. Nella tabella, R = Required, O = Optional.
| Fase | Processo | A | B | C | D |
|---|---|---|---|---|---|
| Define | Conditions of Satisfaction | R | R | O | O |
| Project Overview Statement | R | R | R | R | |
| Approval of Request | R | R | R | R | |
| Plan | Conduct Planning Session | R | R | O | O |
| Prepare Project Proposal | R | R | R | R | |
| Approval of Proposal | R | R | R | R | |
| Launch | Kick-Off Meeting | R | R | O | O |
| Task Schedule | R | R | R | R | |
| Resource Assignments | R | R | R | O | |
| Statements of Work | R | O | O | O | |
| Monitor / Control | Status Reporting | R | R | R | R |
| Project Team Meetings | R | R | O | O | |
| Approval of Deliverables | R | R | R | R | |
| Close | Post-implementation Audit | R | R | R | R |
| Project Notebook | R | R | O | O |
Imposta le caratteristiche e leggi la classe e i processi che diventano obbligatori.
«Un progetto è un'iniziativa temporanea intrapresa per creare un prodotto, un servizio o un altro risultato con caratteristiche di unicità.» Temporanea significa inizio e fine definiti: la fine arriva quando gli obiettivi sono raggiunti, o quando non si riesce più a raggiungerli (anche perché non più possibile), o quando non sussiste più l'esigenza del progetto. Non indica necessariamente breve durata e generalmente non si applica al risultato creato, che anzi è durevole. Unicità: elementi ripetitivi possono comparire nei processi e nei deliverable, ma questo non modifica la fondamentale unicità del lavoro svolto.
La prima definizione («una sequenza unica, complessa e connessa di attività che hanno un obiettivo e devono essere completate rispettando le specifiche e i vincoli di tempo e di budget») ignora il business value: un progetto può rispettare specifiche, tempi e budget e nonostante ciò non soddisfare il cliente. La versione corretta: un progetto è una sequenza finita di attività dipendenti tra loro, il cui completamento con successo si traduce nella fornitura del business value atteso. Il business value è il valore percepito dal destinatario della soluzione.
Un'attività operativa è un impegno di lavoro continuo che corrisponde a un processo ripetitivo, segue le procedure esistenti in azienda, ed è predeterminata: ogni possibile opzione con cui eseguirla è già stata decisa. Un'attività di progetto ha caratteristiche di unicità ed è inserita in un processo anch'esso unico. Il menu del ristorante: se le opzioni sono già definite, aggiornarlo usando una di esse è operativo; se si vogliono inserire nuove portate, serve probabilmente un progetto, perché va sviluppata una nuova «soluzione».
Un programma è un insieme di progetti correlati, gestiti in modo coordinato per ottenere benefici e un controllo non possibili gestendo i progetti singolarmente: sono collegati da un risultato comune o da una caratteristica comune (esempio: il Programma Apollo). Un portfolio è un insieme di progetti o programmi raggruppati solo per facilitare la gestione ed esaudire gli obiettivi strategici: possono non essere interdipendenti. Il discrimine operativo: se l'unica relazione è la condivisione di cliente, fornitore, tecnologia o risorsa, si gestisce un portfolio, non un programma.
Sulle interdipendenze tra progetti, per determinare l'approccio ottimale con cui gestirle. Le azioni includono: risolvere vincoli legati alle risorse e conflitti che impattano più progetti dello stesso programma; allineare la direzione organizzativa e strategica (senior management) che influenza gli obiettivi; risolvere le questioni di gestione del cambiamento in una struttura di governance condivisa.
Lo scope definisce i confini del progetto in termini di ciò che deve essere fatto e ciò che non deve essere fatto. Nel software è spesso riferito direttamente alle specifiche funzionali. Va definito prima di iniziare l'implementazione perché è il riferimento fondamentale per garantire il rispetto dell'integrità concettuale: senza un confine dichiarato, non c'è modo di dire che una funzionalità è «fuori». È inoltre strettamente correlato alle Conditions of Satisfaction, e bisogna mettere in conto che possa cambiare.
È un sistema da mantenere in equilibrio. Le lunghezze dei tre lati corrispondono alle quantità di risorse disponibili (tempo, costo, risorse) e limitano esattamente lo scope e la qualità del progetto, che sono l'area racchiusa. Una modifica delle variabili può portare il sistema fuori equilibrio; per ripristinarlo si usano il Project Impact Statement (valuta le modalità con cui affrontare le modifiche richieste) e la Problem Escalation Strategy.
Primo: il project manager tenta di trovare una soluzione entro i vincoli dettati dall'uso del tempo, del budget e delle risorse che gli sono state concesse. Secondo: il project manager chiede aiuto al manager che gestisce le risorse per ottenere una variazione delle risorse assegnate. Terzo: si contatta il cliente per rinegoziare uno degli aspetti sotto il suo controllo — un incremento del tempo, un incremento del budget, oppure una rinegoziazione dello scope. La logica sottostante: cliente e senior management possiedono il controllo di tempo, budget e risorse; il team possiede la conoscenza di come vengono usati.
Scope creep (ogni cambiamento rispetto al piano originario), hope creep (chi è in ritardo lo nasconde e dichiara di essere in linea), effort creep (lavoro senza progressi proporzionati), feature creep (funzionalità aggiunte senza accordo). L'unico che può essere intenzionale e necessario è lo scope creep, spesso indispensabile per conservare o aumentare il business value: può nascere da cambiamenti del mercato, nuove tecnologie, nuove versioni dei prodotti dei concorrenti.
È ricorrente perché un membro del team non vuole dare brutte notizie al project manager: nasconde il ritardo convinto di poter recuperare nei giorni o nelle settimane successive. È pericoloso perché di solito non si riesce a recuperare e la situazione peggiora, e perché falsa l'informazione su cui si basa ogni decisione di controllo. La contromisura è monitorare con molta attenzione lo stato di avanzamento con strumenti efficaci.
Deve richiedere l'autorizzazione seguendo l'iter definito dal project manager. L'autorizzazione va concessa dal project manager per gli aspetti gestionali, dall'architetto per gli aspetti architetturali (inclusa la conservazione dell'integrità concettuale) e dal cliente, che potrebbe anche riconoscere un valore economico alla nuova funzionalità. Il motivo: se il cliente non ha chiesto una funzionalità a volte c'è un motivo, l'applicazione rischia di diventare inutilmente complicata e il costo aggiuntivo con tutta probabilità non verrà riconosciuto.
A scegliere l'approccio giusto: chi pensa di adottare un approccio unico valido per tutti i progetti «è semplicemente in cerca di guai». La classificazione può avvenire per dimensione, applicazione, tipo, complessità o livello di incertezza, oppure per caratteristiche (rischio, business value, durata, complessità, tecnologia, reparti coinvolti, costi). L'esito operativo è la selezione dei processi di gestione da attivare: nell'esempio a quattro classi (Type A–D), processi come le Conditions of Satisfaction, la planning session, il kick-off meeting o il project notebook sono Required per i progetti A e B e diventano Optional per C e D.