Project Management for Non-Project Managers

✍️ Auctor: Gian Luigi Venturin   🗓️ 12 October 2026

Capire il linguaggio, gli strumenti e le fasi di un progetto senza essere un project manager

Durante la mia attività di Project Manager e di docente mi sono trovato spesso a lavorare con persone che conoscevano molto bene il proprio mestiere, ma che non avevano mai frequentato un corso di Project Management. Persone coinvolte in progetti anche importanti, chiamate a partecipare alle riunioni, a rispettare scadenze, a fornire informazioni o a prendere decisioni, senza avere necessariamente familiarità con il linguaggio e gli strumenti utilizzati per gestire quei progetti.

È a loro che ho pensato scrivendo questo articolo.

Non voglio insegnare a diventare Project Manager, voglio offrire alcune conoscenze di base che permettano di capire che cosa succede all'interno di un progetto, riconoscere i principali strumenti utilizzati e partecipare alle attività con maggiore consapevolezza.

Per farlo, ho organizzato questo approfondimento in cinque parti, seguendo idealmente il percorso di un progetto dall'inizio alla conclusione.

Cominceremo con Entrare nel mondo del Project Management, un breve viaggio nella storia della disciplina, per capire come sia nata l'esigenza di raccogliere e organizzare conoscenze e strumenti che oggi vengono utilizzati in tutto il mondo.

Successivamente passeremo a La mappa per orientarsi, per vedere come si struttura la gestione di un progetto attraverso i cinque gruppi di processo che costituiscono uno dei riferimenti più conosciuti della tradizione PMI.

Con Dall'idea al piano di progetto entreremo nella parte più operativa: partiremo dall'idea iniziale, vedremo come si definiscono gli obiettivi, come si organizza il lavoro, come si assegnano le responsabilità e come si costruisce un piano che permetta di coordinare persone, attività e risorse.

Una volta avviato il progetto, ci chiederemo Il progetto è partito: come capiamo se sta andando bene? Cercheremo quindi di capire come seguirne l'andamento, interpretare le informazioni sull'avanzamento e riconoscere gli scostamenti rispetto a quanto previsto.

Infine arriveremo a Chiudere il progetto e conservare l'esperienza, un momento che non coincide semplicemente con la fine delle attività, ma comprende anche la verifica dei risultati e la raccolta delle esperienze che potranno essere utili nei progetti successivi.

Lungo questo percorso utilizzeremo un unico esempio, l'installazione di una nuova linea produttiva, e incontreremo alcuni strumenti molto conosciuti, come la WBS, il diagramma di Gantt, la baseline e la curva a S: li spiegherò attraverso esempi concreti, senza entrare nei dettagli specialistici necessari a chi deve utilizzarli professionalmente.

In chiusura troverai anche una scheda di consultazione con i principali termini del Project Management, alla quale potrai tornare quando ne incontrerai qualcuno durante il tuo lavoro. L'obiettivo è semplice: quando parteciperai alla prossima riunione di progetto, vorrei che tu riuscissi a comprendere meglio quello che viene detto, a riconoscere gli strumenti utilizzati e, soprattutto, a capire come e quando mettere a disposizione le tue competenze.

Parte I – Entrare nel mondo del Project Management

Il Project Management non è nato ieri

Il 20 luglio 1969 l'Uomo mette piede sulla Luna.

È uno dei momenti più straordinari della storia della tecnologia, ma anche il risultato di un'impresa organizzativa di dimensioni eccezionali: per arrivare a quel risultato è stato necessario coordinare migliaia di persone, aziende, centri di ricerca, fornitori e competenze differenti, affrontando problemi tecnici che spesso non avevano ancora una soluzione conosciuta. Eppure, il successo del programma Apollo non è dipeso soltanto dalla capacità di progettare razzi, motori e sistemi di navigazione, è dipeso anche dalla capacità di organizzare il lavoro, pianificare le attività, coordinare le responsabilità, controllare tempi e costi e gestire i rischi.

In altre parole, da molte delle competenze che oggi riconosciamo come parte del Project Management.

Proprio nel 1969, negli Stati Uniti, nasce il Project Management Institute (PMI®) , un'organizzazione professionale destinata a diventare uno dei principali riferimenti internazionali per la gestione dei progetti. La coincidenza temporale con lo sbarco sulla Luna è interessante, ma non dobbiamo interpretarla come un rapporto diretto di causa ed effetto: il PMI non nasce perché l'uomo è arrivato sulla Luna e, soprattutto, non inventa il Project Management.

Già nei decenni precedenti, grandi programmi industriali, militari, aerospaziali e infrastrutturali avevano portato allo sviluppo di strumenti e tecniche per organizzare attività complesse: pensiamo, per esempio, ai diagrammi di Gantt, utilizzati già nella prima metà del Novecento, oppure alle tecniche di pianificazione reticolare sviluppate negli anni Cinquanta.

Quello che progressivamente emerge è un'esigenza diversa: raccogliere le conoscenze maturate nei diversi settori, confrontare le esperienze, individuare le pratiche più efficaci e renderle disponibili anche ad altre organizzazioni.

In fondo, è un processo che conosciamo bene nel mondo industriale, quando una soluzione ha dimostrato di funzionare, non è necessario reinventarla ogni volta: possiamo studiarla, comprenderne le condizioni di applicabilità, adattarla al nostro contesto e utilizzarla per affrontare problemi simili. Naturalmente, ogni progetto conserva caratteristiche proprie, non esiste una procedura capace di eliminare tutte le incertezze, né una tecnica che garantisca automaticamente il successo. Ma esistono conoscenze ed esperienze che possono essere organizzate e trasmesse.

È proprio in questa direzione che il PMI contribuisce allo sviluppo della disciplina.

Nel corso degli anni, questo patrimonio di conoscenze viene progressivamente raccolto e sistematizzato nel PMBOK, Project Management Body of Knowledge, un primo documento di riferimento che viene pubblicato nel 1987; nel 1996 compare la prima edizione della guida che, attraverso successivi aggiornamenti, diventerà uno dei testi più conosciuti nel settore. La guida continua a evolversi: dopo la sesta edizione del 2017 e la settima del 2021, nel 2025 viene pubblicata l'ottava edizione, che riflette ulteriormente l'evoluzione della disciplina e dei diversi approcci alla gestione dei progetti.

Vorrei chiarire subito un aspetto, perché nel linguaggio corrente questi termini vengono spesso utilizzati come se fossero sinonimi.

Il PMI® è un'organizzazione professionale; Il PMBOK è una guida che raccoglie e organizza conoscenze, principi, pratiche e strumenti del Project Management: non è una procedura obbligatoria da seguire passo dopo passo.

Le organizzazioni possono utilizzare questo patrimonio di conoscenze per costruire modalità di gestione coerenti con le caratteristiche dei propri progetti; ecco perché, quando sentiamo parlare di un progetto gestito secondo il modello PMI, dobbiamo pensare a un insieme strutturato di conoscenze e pratiche professionali, non a una ricetta universale. Questa distinzione ci sarà utile anche più avanti, quando incontreremo i cinque gruppi di processo e alcuni degli strumenti più conosciuti del Project Management.

Un progetto non è semplicemente un insieme di attività

Prima di entrare nel funzionamento del Project Management, però, dobbiamo chiarire una questione apparentemente semplice: che cosa intendiamo quando parliamo di progetto?

Immaginiamo uno stabilimento industriale, in cui ogni giorno vengono prodotti componenti, effettuati controlli di qualità, gestiti ordini, organizzate spedizioni e svolte attività di manutenzione: sono operazioni che possono essere molto complesse, richiedere competenze elevate e coinvolgere numerose persone. Ma, per quanto importanti, non sono necessariamente progetti: sono attività operative, cioè attività che l'organizzazione svolge in modo continuativo o ricorrente per realizzare i propri prodotti e servizi.

Supponiamo invece che l'azienda decida di installare una nuova linea produttiva: occorrerà definire le caratteristiche dell'impianto, valutarne la convenienza economica, progettare il layout, scegliere i fornitori, acquistare le macchine, predisporre gli spazi, organizzare l'installazione, effettuare i collaudi e avviare la produzione.

Questa volta ci troviamo davanti a qualcosa di diverso.

Un progetto è un'iniziativa temporanea intrapresa per creare un prodotto, un servizio o un risultato unico.

Temporanea non significa necessariamente breve: alcuni progetti durano poche settimane, altri richiedono anni, questo significa che hanno un inizio e una conclusione riconoscibili.

Unico non significa che nessuno abbia mai realizzato qualcosa di simile: due aziende possono installare lo stesso modello di linea produttiva, ma cambieranno gli ambienti, le persone coinvolte, le condizioni operative, le risorse disponibili e probabilmente anche alcuni obiettivi.

Ogni progetto presenta quindi caratteristiche che lo distinguono dalle attività ordinarie e dagli altri progetti; nell’esempio che useremo, l'installazione della linea produttiva ha un risultato da raggiungere, una durata prevista, risorse da utilizzare e una serie di vincoli da rispettare.

Tra questi vincoli troviamo normalmente tempi, costi, requisiti di qualità, risorse disponibili e caratteristiche del risultato atteso, modificare uno di questi elementi può avere conseguenze sugli altri: se decidiamo di anticipare l'entrata in funzione della linea, potremmo dover aumentare le risorse impiegate; se durante la progettazione emergono nuovi requisiti tecnici, potrebbero cambiare i costi o i tempi di consegna; se un fornitore ritarda, potremmo essere costretti a riorganizzare alcune attività.

Ed è proprio qui che cominciamo a comprendere perché sia necessario gestire un progetto in modo strutturato. Non basta conoscere tutte le attività da svolgere, occorre capire come sono collegate tra loro, chi ne è responsabile, quali risultati devono produrre e che cosa accade quando qualcosa cambia.

C'è poi un altro elemento che merita attenzione: un progetto raramente coinvolge una sola funzione aziendale.

Nel caso della nuova linea produttiva saranno probabilmente interessati la Direzione, la Produzione, l'Ufficio Tecnico, gli Acquisti, la Manutenzione, la Qualità, la Sicurezza e l'Amministrazione; potrebbero intervenire anche consulenti, progettisti, installatori e fornitori esterni. Ognuno porterà competenze differenti, ma non necessariamente avrà la stessa visione delle priorità.

La Produzione potrebbe essere interessata soprattutto alla capacità produttiva e alla continuità operativa, gli Acquisti dovranno considerare condizioni contrattuali e tempi di fornitura; la Manutenzione valuterà l'accessibilità degli impianti e la loro affidabilità; la Direzione dovrà tenere sotto controllo l'investimento e i benefici attesi; tutte esigenze legittime, ma devono essere coordinate.

Il Project Management serve anche a questo: costruire una visione comune del risultato da raggiungere e organizzare il contributo delle diverse competenze necessarie per ottenerlo.

Vorrei sottolineare un ultimo aspetto, particolarmente importante per chi viene coinvolto in un progetto senza essere un Project Manager.

Partecipare a un progetto non significa necessariamente abbandonare il proprio ruolo professionale: il responsabile della Manutenzione continuerà a essere un esperto di manutenzione; il responsabile della Qualità continuerà a occuparsi di qualità; il tecnico di Produzione continuerà a mettere a disposizione le proprie competenze tecniche. Quello che cambia è il contesto nel quale queste competenze vengono utilizzate. Le attività non sono più considerate soltanto all'interno della singola funzione, ma diventano parte di un risultato comune, con obiettivi, responsabilità, scadenze e relazioni che devono essere comprese e coordinate.

Ed è per questo che conoscere almeno le basi del Project Management può essere utile anche a chi non intende diventare un Project Manager.

Non per sostituirsi a chi governa il progetto, ma per comprendere come il proprio lavoro contribuisce al risultato complessivo.

Ora che abbiamo chiarito che cosa sia un progetto e perché sia nata l'esigenza di gestirlo in modo strutturato, possiamo entrare nella sua organizzazione. Nella prossima parte incontreremo i cinque gruppi di processo, una mappa che ci aiuterà a riconoscere le principali attività di gestione di un progetto e a capire dove si collocano gli strumenti che vedremo successivamente.

Parte II – La mappa per orientarsi

I cinque gruppi di processo: come si organizza la gestione di un progetto

Nella prima parte abbiamo visto che un progetto non è semplicemente un insieme di attività da svolgere, ma un'iniziativa che richiede di coordinare persone, competenze, risorse e decisioni per raggiungere un risultato definito. A questo punto viene naturale chiedersi: come si organizza tutto questo lavoro?

Nel corso degli anni, il Project Management ha sviluppato diversi modelli e strumenti per affrontare questa esigenza: uno dei riferimenti più conosciuti, formalizzato dal PMI, è rappresentato dai cinque gruppi di processo, che costituiscono un modo particolarmente efficace per comprendere le principali attività necessarie a governare un progetto.

1. Avvio (Initiating)
2. Pianificazione (Planning)
3. Esecuzione (Executing)
4. Monitoraggio e controllo (Monitoring and Controlling)
5. Chiusura (Closing)

Prima di entrare nel loro significato, vorrei chiarire una distinzione importante: quando osserviamo questo elenco, siamo portati a immaginare cinque fasi che si susseguono ordinatamente, ovvero prima si avvia il progetto, poi lo si pianifica, successivamente lo si esegue, quindi si controllano i risultati e, infine, lo si chiude. È una rappresentazione intuitiva, ma non del tutto corretta.

I cinque gruppi non sono necessariamente cinque fasi cronologiche del progetto. Sono gruppi di processi di gestione che possono interagire, sovrapporsi e ripetersi durante il suo sviluppo.

La pianificazione, per esempio, non termina necessariamente quando comincia l'esecuzione: durante i lavori possono emergere nuove informazioni che richiedono di aggiornare alcune attività, rivedere le risorse o approfondire determinate scelte. Allo stesso modo, il monitoraggio e controllo non comincia quando il lavoro è stato completato: accompagna il progetto durante il suo svolgimento, permettendo di confrontare ciò che sta accadendo con quanto previsto e di intervenire quando necessario.

Questa precisazione non deve complicarci la vita, possiamo utilizzare i cinque gruppi come una mappa per orientarci nella gestione del progetto, ricordando che nella realtà i loro confini sono meno rigidi di quanto possa suggerire uno schema.

Figura 1 – I cinque gruppi di processo del Project Management. Lo schema rappresenta le principali attività di gestione di un progetto e le loro interazioni. I gruppi non costituiscono fasi rigidamente successive: Pianificazione, Esecuzione e Monitoraggio e Controllo possono interagire durante lo sviluppo del progetto.

Avvio: perché facciamo questo progetto?

Torniamo alla nostra azienda, che sta valutando l'installazione di una nuova linea produttiva. Probabilmente l'idea nasce da un'esigenza concreta: aumentare la capacità produttiva, ridurre i costi, migliorare la qualità dei prodotti oppure introdurre una nuova tecnologia.

Ma avere una buona idea non significa avere già un progetto autorizzato.

Prima di impegnare risorse importanti, qualcuno deve chiarire quali risultati si vogliono ottenere, quali benefici ci si aspetta, quali vincoli esistono e se l'iniziativa sia sufficientemente giustificata per procedere. È in questo contesto che possono essere sviluppate valutazioni preliminari di fattibilità, analisi economiche e confronti tra possibili soluzioni: non si tratta necessariamente di attività svolte tutte dal Project Manager, spesso coinvolgono la Direzione, le funzioni tecniche ed economico-finanziarie e altre persone chiamate a valutare l'investimento.

Nel gruppo di processi di Avvio assume particolare importanza il Project Charter, il documento attraverso il quale il progetto viene formalmente autorizzato e vengono definiti i suoi riferimenti fondamentali. Lo incontreremo nella prossima parte e vedremo che cosa contiene.

Per il momento ci interessa comprendere il principio: prima di organizzare il lavoro dobbiamo sapere perché intendiamo svolgerlo, quale risultato vogliamo raggiungere e chi ha l'autorità per avviare il progetto.

Pianificazione: come pensiamo di raggiungere il risultato?

Il progetto è stato autorizzato, sappiamo che vogliamo installare una nuova linea produttiva e conosciamo gli obiettivi principali dell'investimento, ma non possiamo limitarci a convocare i fornitori e cominciare a lavorare.

Dobbiamo definire più precisamente che cosa sarà realizzato, quali attività saranno necessarie, come verranno organizzate, chi ne sarà responsabile, quanto tempo richiederanno e quali risorse dovremo utilizzare; dovremo inoltre considerare i costi, la qualità attesa, i rischi, le comunicazioni e le relazioni tra le diverse persone e organizzazioni coinvolte.

È questo il compito fondamentale della Pianificazione: trasformare gli obiettivi del progetto in un piano di lavoro coerente e controllabile.

Nel nostro esempio, prima di installare la linea dovremo probabilmente predisporre il layout, definire le caratteristiche delle macchine, verificare le infrastrutture disponibili, concordare le forniture e organizzare le attività di montaggio e collaudo. Molte di queste attività sono collegate tra loro: non possiamo installare una macchina se non è stata consegnata; non possiamo completare determinate predisposizioni se il layout non è stato definito; non possiamo effettuare il collaudo finale se alcune installazioni non sono state completate. Pianificare significa anche riconoscere queste relazioni e organizzarle in modo che il progetto possa procedere con ordine.

In questa parte del lavoro incontreremo alcuni degli strumenti più conosciuti del Project Management: la WBS, la matrice delle responsabilità, il diagramma di Gantt e la baseline. Li approfondiremo successivamente, perché meritano di essere spiegati attraverso esempi.

Vorrei però sottolineare fin da ora un concetto: il piano di progetto non è una previsione infallibile di ciò che accadrà, è un riferimento costruito con le migliori informazioni disponibili, che permette di organizzare il lavoro e governare consapevolmente gli eventuali cambiamenti.

Esecuzione: dal piano al lavoro reale

A un certo punto il progetto entra nella sua fase più visibile: le macchine vengono ordinate e consegnate, gli spazi vengono predisposti, i tecnici intervengono sugli impianti, i fornitori eseguono le installazioni e cominciano le attività di verifica e collaudo. È il momento in cui il lavoro pianificato viene effettivamente realizzato.

Nel gruppo di processi di Esecuzione rientrano le attività di direzione e coordinamento del lavoro previsto dal piano, la gestione delle risorse, delle comunicazioni, della qualità e delle relazioni tra i soggetti coinvolti.

Qui è utile fare una distinzione che, nella mia esperienza, non sempre risulta evidente a chi si avvicina per la prima volta al Project Management: il Project Manager non è necessariamente la persona che possiede tutte le competenze tecniche necessarie a realizzare il progetto.

Nella nostra azienda, per esempio, il responsabile dell'Ufficio Tecnico conoscerà probabilmente le caratteristiche degli impianti meglio del Project Manager; la Manutenzione avrà competenze specifiche sulle macchine e sulle infrastrutture; la Produzione conoscerà le esigenze operative della linea; gli Acquisti sapranno gestire gli aspetti commerciali e contrattuali delle forniture.

Il compito del Project Manager è integrare questi contributi, coordinare le attività e fare in modo che il lavoro proceda verso gli obiettivi concordati. Naturalmente, il grado di autorità del Project Manager e il modo in cui interagisce con le funzioni aziendali dipendono anche dall'organizzazione nella quale opera. In alcuni casi dispone di risorse direttamente assegnate al progetto; in altri deve coordinarle attraverso i rispettivi responsabili funzionali.

In entrambi i casi, il principio rimane lo stesso: le competenze specialistiche realizzano il risultato, mentre il Project Management contribuisce a organizzarle e coordinarle in un insieme coerente.

Ed è proprio durante l'esecuzione che diventa particolarmente importante il gruppo di processi successivo.

Monitoraggio e controllo: stiamo procedendo come previsto?

Immaginiamo di essere arrivati a metà del progetto: alcune macchine sono state consegnate, altre sono ancora in costruzione; le opere di predisposizione sono quasi terminate e il fornitore principale ci comunica che una componente essenziale arriverà con due settimane di ritardo.

Che cosa significa questa informazione? Potrebbe trattarsi di un problema relativamente semplice, se quella componente non è necessaria per le attività previste nell'immediato futuro; oppure potrebbe compromettere una scadenza importante, ritardare il collaudo e spostare la data di avviamento della linea.

Per capire quale delle due situazioni abbiamo davanti, dobbiamo confrontare ciò che sta accadendo con quello che avevamo pianificato.

È questo uno degli obiettivi fondamentali del Monitoraggio e controllo.

Il gruppo comprende le attività necessarie a seguire l'andamento del progetto, misurare i risultati, individuare gli scostamenti, valutare i rischi e gestire le modifiche che si rendono necessarie.

Monitorare significa raccogliere e analizzare informazioni sull'andamento del progetto; controllare significa utilizzare quelle informazioni per valutare gli scostamenti e decidere gli interventi opportuni.

Non è una distinzione puramente teorica: sapere che una consegna è in ritardo è un'informazione, capire se quel ritardo compromette il programma, valutare le possibili alternative e decidere come intervenire significa esercitare il controllo del progetto.

Naturalmente, non tutti gli scostamenti richiedono una modifica del piano: alcuni possono essere assorbiti dall'organizzazione delle attività, altri richiedono azioni correttive e altri ancora possono rendere necessaria una revisione formalmente approvata di determinati elementi del progetto. Per effettuare queste valutazioni abbiamo bisogno di riferimenti e strumenti adeguati.

Ecco perché, più avanti, dedicheremo particolare attenzione alla baseline, che permette di confrontare il piano approvato con l'andamento del progetto, e alla curva a S, una rappresentazione grafica che può aiutarci a leggere l'evoluzione di determinate grandezze nel tempo.

Per ora voglio evidenziare soprattutto un aspetto:

monitoraggio e controllo non sono attività che si svolgono alla fine del progetto, per scoprire se tutto è andato bene: sono attività che accompagnano il lavoro e ci permettono di intervenire quando siamo ancora in tempo per farlo.

Chiusura: quando possiamo dire che il progetto è finito?

La nuova linea produttiva è stata installata: le macchine funzionano, i collaudi previsti sono stati completati e la Produzione può iniziare a utilizzarla.

Possiamo considerare concluso il progetto?

Probabilmente siamo molto vicini alla conclusione, ma prima dobbiamo verificare che siano stati soddisfatti i requisiti concordati, che i risultati siano stati formalmente accettati e che siano state completate le attività necessarie alla chiusura. Potrebbero esserci documenti da consegnare, aspetti contrattuali da definire, risorse da rilasciare e responsabilità operative da trasferire alle funzioni che gestiranno la linea.

Il gruppo di processi di Chiusura serve proprio a formalizzare il completamento del progetto o di una sua fase, verificando che quanto previsto per la chiusura sia stato correttamente eseguito.

Ma c'è un altro aspetto al quale tengo particolarmente: durante il progetto avremo sicuramente imparato qualcosa.

Avremo scoperto che alcune attività richiedevano più tempo del previsto, che determinati fornitori erano particolarmente affidabili, che alcune soluzioni tecniche funzionavano meglio di altre oppure che determinate difficoltà avrebbero potuto essere evitate con una pianificazione diversa. Sarebbe un peccato perdere tutto questo patrimonio di esperienza.

Per questo motivo, tra le pratiche più importanti del Project Management troviamo la raccolta delle Lessons Learned, le lezioni apprese durante lo svolgimento del progetto. Non è necessario aspettare la chiusura per raccoglierle: possiamo farlo anche durante il lavoro, quando le informazioni sono ancora disponibili e le persone ricordano chiaramente che cosa è accaduto.

La conclusione del progetto rappresenta però un momento particolarmente utile per riordinare queste conoscenze e renderle disponibili all'organizzazione.

Un progetto ben gestito non dovrebbe lasciare soltanto il risultato che era stato chiamato a realizzare, ma anche conoscenze ed esperienze utili per affrontare meglio i progetti successivi.

Una mappa, non una procedura rigida

Abbiamo attraversato i cinque gruppi di processo utilizzando il nostro esempio della nuova linea produttiva. Siamo partiti dall'esigenza di realizzare un investimento, abbiamo visto come si organizza il lavoro, come lo si esegue, come se ne controlla l'andamento e come si arriva alla conclusione.

A questo punto vorrei tornare alla precisazione fatta all'inizio:

i cinque gruppi di processo non costituiscono una procedura rigida da applicare meccanicamente dall'inizio alla fine.

Durante l'esecuzione possiamo aver bisogno di pianificare nuovamente alcune attività: il Monitoraggio e controllo accompagna il progetto durante il suo sviluppo; determinati processi possono essere ripetuti e, nei progetti articolati in più fasi, alcuni gruppi possono essere applicati anche alle singole fasi.

È inoltre importante ricordare che i cinque gruppi rappresentano una struttura di riferimento consolidata del PMI, non l'unico modo possibile di organizzare il Project Management. L'evoluzione del PMBOK ha progressivamente dato maggiore spazio anche ai principi, ai domini di prestazione e alla scelta di approcci differenti secondo le caratteristiche del progetto.

Per chi si avvicina per la prima volta alla disciplina, tuttavia, questa mappa rimane estremamente utile: permette di comprendere perché, durante una riunione, qualcuno parla di autorizzazione del progetto, qualcun altro presenta un piano delle attività e un altro ancora chiede informazioni sugli scostamenti rispetto alle scadenze previste; non sono argomenti scollegati, sono aspetti diversi di un unico lavoro di gestione.

Ora che abbiamo questa visione d'insieme, possiamo fare un passo avanti.

Nella prossima parte entreremo concretamente nel nostro progetto della nuova linea produttiva e vedremo quali documenti e strumenti vengono utilizzati per trasformare un'idea in un piano di lavoro organizzato.

Incontreremo termini come Project Charter, Project Scope, WBS, matrice RACI, diagramma di Gantt e baseline, cercando di comprenderne il significato e, soprattutto, di capire a che cosa servono nella pratica.

Parte III – Dall'idea al piano di progetto

Prima di cominciare: perché vogliamo realizzare il progetto?

Torniamo nella nostra azienda, dove la Direzione sta valutando l'installazione di una nuova linea produttiva: potrebbe essere necessario aumentare la capacità dello stabilimento, introdurre una nuova famiglia di prodotti, migliorare la qualità oppure sostituire impianti che stanno diventando tecnologicamente obsoleti. Qualunque sia la ragione, la prima domanda da porsi non è quale macchina acquistare o quanto tempo servirà per installarla.

La prima domanda è: perché vogliamo realizzare questo progetto e quali benefici ci aspettiamo di ottenere?

Sembra una considerazione ovvia, ma nella pratica non sempre riceve l'attenzione che merita: un'azienda, ad esempio, potrebbe decidere di investire in una nuova linea per aumentare la capacità produttiva del 30%, salvo scoprire successivamente che il vero problema non era la capacità degli impianti, ma l'organizzazione dei turni, la disponibilità dei materiali o l'efficienza delle macchine esistenti. Prima di avviare un investimento importante è quindi necessario comprenderne le motivazioni, valutare le alternative disponibili e verificare che la soluzione proposta sia coerente con le esigenze dell'organizzazione.

In questa fase possono essere sviluppati studi di fattibilità, valutazioni tecniche, analisi dei costi e dei benefici e stime preliminari dei rischi. Uno dei documenti che possiamo incontrare è il Business Case, nel quale vengono raccolte le motivazioni che giustificano l'iniziativa, i benefici attesi, le possibili alternative e gli elementi economici necessari per valutarne la convenienza. Non è necessariamente il Project Manager a predisporlo: spesso queste valutazioni vengono sviluppate dalla Direzione e dalle funzioni aziendali interessate, anche prima che il progetto venga formalmente autorizzato.

Nel nostro esempio, il Business Case potrebbe mostrare che la nuova linea permetterà di aumentare la produzione, ridurre gli scarti e migliorare il costo unitario dei prodotti, a fronte di un investimento che dovrà essere recuperato attraverso i benefici economici attesi.

Una volta valutata positivamente l'iniziativa, occorre però compiere un ulteriore passaggio: trasformare la decisione di investire in un progetto formalmente riconosciuto dall'organizzazione. Ed è qui che incontriamo uno dei documenti più importanti del Project Management.

Il Project Charter: il documento che autorizza il progetto

Il Project Charter è il documento che autorizza formalmente l'esistenza del progetto e attribuisce al Project Manager l'autorità necessaria per utilizzare le risorse organizzative secondo le modalità previste. Non dobbiamo immaginarlo necessariamente come un documento di decine di pagine: la sua struttura e il suo livello di dettaglio dipendono dalla complessità del progetto e dalle regole dell'organizzazione.

Normalmente contiene alcuni elementi fondamentali:

• le motivazioni del progetto, cioè le ragioni per cui l'organizzazione ha deciso di realizzarlo;
• gli obiettivi, con l'indicazione dei risultati che si intendono raggiungere;
• i principali requisiti e risultati attesi, descritti a un livello ancora generale;
• i vincoli iniziali, come le scadenze principali, il budget indicativo e le condizioni da rispettare;
• i rischi più significativi già riconoscibili al momento dell'avvio;
• l'individuazione del Project Manager e il livello di autorità che gli viene attribuito;
• l'identificazione dello sponsor, cioè della figura che sostiene il progetto a livello organizzativo e ne promuove l'autorizzazione.

Nel nostro esempio, il Project Charter potrebbe indicare che l'obiettivo è installare e rendere operativa una nuova linea entro una determinata data, rispettando un limite di investimento e raggiungendo specifici requisiti di capacità produttiva e qualità; potrebbe inoltre individuare il Project Manager incaricato di coordinare il lavoro e il dirigente che agirà come sponsor del progetto.

Attenzione però a non confondere il Project Charter con il piano di progetto: il Project Charter autorizza il progetto e ne definisce le coordinate fondamentali; il piano di progetto descriverà in modo molto più approfondito come intendiamo realizzarlo.

È una distinzione semplice, ma importante.

Durante questa fase potremmo incontrare anche il termine Statement of Work (SOW), che descrive il lavoro richiesto, i risultati da fornire e, secondo il contesto, le condizioni che ne regolano l'esecuzione; può essere utilizzato, per esempio, per definire le prestazioni richieste a un fornitore. Non dobbiamo però confonderlo con il Project Charter: i due documenti hanno finalità differenti e possono essere utilizzati in momenti e contesti diversi.

A questo punto il progetto è autorizzato, il Project Manager è stato individuato e conosciamo gli obiettivi generali, ma siamo ancora lontani dal poter iniziare a installare la nostra linea. Dobbiamo innanzitutto stabilire con precisione che cosa dovrà essere realizzato.

Definire il perimetro: che cosa dobbiamo realizzare?

Immaginiamo di convocare una riunione con Produzione, Ufficio Tecnico, Qualità, Manutenzione e Sicurezza per discutere la nuova linea. Probabilmente ciascuna funzione porterà esigenze specifiche: la Produzione potrebbe richiedere una determinata capacità oraria; la Qualità potrebbe indicare i sistemi di controllo necessari; la Manutenzione potrebbe chiedere spazi adeguati per accedere alle macchine; la Sicurezza dovrà verificare i requisiti applicabili all'impianto e alle condizioni di utilizzo. Tutte queste richieste possono essere legittime, ma non possiamo limitarci a raccoglierle senza definire che cosa entrerà effettivamente nel progetto.

Dobbiamo quindi stabilire quali risultati siamo tenuti a realizzare, quali caratteristiche dovranno possedere e quali attività saranno necessarie per ottenerli.

Nel Project Management questo insieme di definizioni viene ricondotto al concetto di Project Scope, cioè l'ambito del progetto.

A questo punto è utile distinguere due aspetti:

il primo riguarda il Product Scope, ossia le caratteristiche e le funzionalità del prodotto o del risultato che vogliamo ottenere; nel nostro caso, per esempio, la capacità produttiva della linea, le tipologie di componenti che dovrà realizzare, le prestazioni richieste e le caratteristiche tecniche dell'impianto;

il secondo è il Project Scope, cioè il lavoro necessario per realizzare e consegnare quel risultato; potrebbe comprendere la progettazione del layout, le predisposizioni impiantistiche, gli acquisti, l'installazione, il collaudo e la formazione del personale.

I due concetti sono collegati, ma non coincidono: le caratteristiche del risultato definiscono che cosa vogliamo ottenere; l'ambito del progetto definisce il lavoro necessario per ottenerlo.

Un altro termine importante è deliverable.

Un deliverable è un risultato verificabile che deve essere prodotto nell'ambito del progetto. Può essere un oggetto fisico, un documento, un sistema installato o un altro risultato chiaramente identificabile. Nel nostro esempio, potrebbero essere deliverable il layout approvato, l'impianto installato, la documentazione tecnica e il collaudo completato con esito positivo.

Per ciascun risultato significativo è utile definire anche i criteri di accettazione, cioè le condizioni che permetteranno di stabilire se quanto realizzato corrisponde a ciò che era stato richiesto. Se la nuova linea deve produrre una determinata quantità di pezzi all'ora, non basterà affermare che funziona: occorrerà verificare che raggiunga le prestazioni concordate nelle condizioni previste.

Definire il perimetro significa anche chiarire che cosa non fa parte del progetto.

Supponiamo, per esempio, che l'investimento riguardi esclusivamente una nuova linea di assemblaggio e non comprenda il rifacimento dell'intero reparto: se questa esclusione non viene chiarita, qualcuno potrebbe aspettarsi interventi che non sono mai stati autorizzati o finanziati.

Durante lo svolgimento del progetto potrebbero inoltre comparire nuove richieste: la Produzione potrebbe proporre un sistema aggiuntivo di automazione; la Qualità potrebbe chiedere un ulteriore controllo; la Direzione potrebbe decidere di aumentare la capacità prevista. Non è detto che queste richieste siano sbagliate, alcune potrebbero migliorare sensibilmente il risultato. Ma ogni modifica deve essere valutata considerando gli effetti su costi, tempi, risorse e obiettivi.

Quando l'ambito del progetto si espande progressivamente senza un adeguato controllo, parliamo di scope creep.

È uno dei fenomeni che possono mettere in difficoltà un progetto: il lavoro aumenta, ma le risorse, il budget e le scadenze potrebbero rimanere invariati.

Definire correttamente il perimetro non significa impedire i cambiamenti, significa sapere che cosa abbiamo concordato, così da poter valutare consapevolmente le modifiche che si renderanno necessarie.

Una volta chiarito che cosa dobbiamo realizzare, nasce un'altra esigenza: organizzare il lavoro in modo che possa essere pianificato, assegnato e controllato; ed è qui che entra in scena uno degli strumenti più caratteristici del Project Management.

La WBS: trasformare un progetto complesso in parti gestibili

Se chiedessi a una persona di organizzare l'installazione di una nuova linea produttiva, probabilmente comincerebbe a preparare un elenco delle attività necessarie: progettare il layout, contattare i fornitori, ordinare le macchine, predisporre gli impianti, effettuare l'installazione e organizzare i collaudi.

È un inizio ragionevole, ma possiamo fare qualcosa di più strutturato: possiamo prendere il lavoro complessivo del progetto e scomporlo progressivamente in elementi più piccoli, fino a ottenere parti sufficientemente definite da poter essere pianificate, assegnate e controllate.

Questo è il principio alla base della WBS, Work Breakdown Structure.

Il nome può sembrare complicato, ma il concetto è semplice: una WBS rappresenta una scomposizione gerarchica del lavoro complessivo del progetto, organizzata intorno ai deliverable da realizzare.

Torniamo alla nostra linea produttiva, dove al livello più alto della WBS troveremo il progetto nel suo insieme: la nuova linea produttiva installata e pronta per l'utilizzo secondo i requisiti concordati.

Possiamo quindi suddividerlo in alcuni grandi elementi, per esempio:

• • progettazione e documentazione tecnica;
• • macchine e attrezzature;
• • infrastrutture e predisposizioni impiantistiche;
• • linea installata e integrata;
• • collaudi, formazione e documentazione di consegna.

Ciascuno di questi elementi può essere ulteriormente scomposto: le infrastrutture, per esempio, potrebbero comprendere le predisposizioni elettriche, pneumatiche e meccaniche; la parte dedicata ai collaudi potrebbe essere articolata nelle verifiche funzionali, nelle prove di prestazione e nella documentazione di accettazione. Procedendo in questo modo arriviamo a elementi che possono essere descritti, stimati e assegnati a una responsabilità organizzativa.

Questi elementi terminali prendono il nome di work package, cioè pacchetti di lavoro.

Figura 2 – Work Breakdown Structure (WBS). Il progetto viene scomposto in elementi progressivamente più specifici. I riquadri appartenenti allo stesso ramo sono allo stesso livello gerarchico: la loro posizione non indica una sequenza temporale.

Vorrei soffermarmi su una distinzione, perché è essenziale per comprendere correttamente questo strumento: la WBS non è un calendario e non rappresenta la sequenza temporale delle attività: non ci dice ancora che cosa dobbiamo fare lunedì, che cosa martedì e che cosa la settimana successiva; ci aiuta prima di tutto a identificare e organizzare l'intero lavoro necessario per realizzare il progetto. La sequenza delle attività e le relative scadenze verranno definite successivamente.

Perché è così importante? Innanzitutto perché ci aiuta a non dimenticare parti significative del lavoro: ad esempio, se la WBS comprende l'installazione delle macchine ma non le infrastrutture necessarie a farle funzionare, potremmo accorgerci troppo tardi che manca una componente essenziale del progetto.

In secondo luogo, perché facilita le stime: valutare quanto costerà e quanto durerà l'intero progetto può essere difficile, mentre valutare singoli pacchetti di lavoro, sufficientemente definiti, è generalmente più gestibile.

Infine, la WBS permette di collegare le parti del lavoro alle responsabilità, ai costi e alle successive attività di pianificazione.

C'è un principio spesso richiamato quando si costruisce una WBS: la scomposizione deve comprendere il 100% del lavoro necessario per realizzare l'ambito concordato del progetto.

Questo non significa che ogni minimo dettaglio debba essere conosciuto fin dall'inizio, significa che la struttura deve rappresentare in modo completo l'ambito definito al livello di dettaglio necessario per governarlo, evitando sia le omissioni sia le duplicazioni.

Per il nostro lettore: non è indispensabile imparare a costruire professionalmente una WBS, è però importante saperla riconoscere e comprendere che cosa rappresenta. Quando qualcuno, durante una riunione, parlerà del pacchetto di lavoro relativo alle predisposizioni elettriche, sapremo che non sta indicando genericamente un'attività, ma una componente definita dell'ambito complessivo del progetto. E a questo punto possiamo porci la domanda successiva.

Abbiamo individuato il lavoro da svolgere: ma chi se ne occuperà?

Chi fa che cosa? La matrice delle responsabilità

Un progetto può essere pianificato con grande attenzione e incontrare comunque difficoltà perché le persone non hanno compreso chiaramente le proprie responsabilità.

Pensiamo a una situazione abbastanza comune, durante una riunione viene deciso che il layout della nuova linea dovrà essere approvato prima di procedere con alcune predisposizioni: l'Ufficio Tecnico prepara il disegno, la Produzione lo esamina, la Manutenzione chiede alcune modifiche e il Project Manager sollecita una decisione.

Ma chi deve approvarlo definitivamente?

Se questa responsabilità non è stata chiarita, la discussione può proseguire per giorni, oppure qualcuno può assumere una decisione senza possedere l'autorità necessaria: sapere quali attività devono essere svolte non basta, occorre sapere chi le esegue, chi ne risponde e chi deve essere coinvolto nelle decisioni.

Uno degli strumenti che possiamo utilizzare è la matrice di assegnazione delle responsabilità, spesso rappresentata nella forma della matrice RACI.

RACI è un acronimo formato da quattro lettere:

• R – Responsible: chi esegue materialmente il lavoro o contribuisce direttamente alla sua realizzazione;
• A – Accountable: chi ha la responsabilità ultima del risultato e ne risponde;
• C – Consulted: chi deve essere consultato, perché possiede informazioni o competenze necessarie;
• I – Informed: chi deve essere informato sull'attività o sulle decisioni, pur non partecipando direttamente alla loro esecuzione.

La distinzione tra Responsible e Accountable merita particolare attenzione, perché non sempre è intuitiva: una persona può svolgere un'attività senza essere quella che possiede la responsabilità finale del risultato. Nel nostro esempio, l'Ufficio Tecnico potrebbe essere incaricato di predisporre il layout, mentre il responsabile individuato per la sua approvazione potrebbe appartenere a un'altra funzione, secondo l'organizzazione e le deleghe stabilite.

Normalmente, in una matrice RACI ben costruita, ogni attività o risultato dovrebbe avere un unico Accountable, mentre possono esserci più persone o funzioni Responsible, se il lavoro lo richiede.

Tabella 1 – Esempio semplificato di matrice RACI. La matrice mette in relazione le attività e i risultati del progetto con le funzioni aziendali coinvolte, evidenziando il ruolo e le responsabilità di ciascuna. Le assegnazioni sono illustrative e dipendono dall'organizzazione del progetto.

Per chi viene coinvolto in un progetto senza essere un Project Manager, comprendere la matrice RACI può essere particolarmente utile: permette di sapere quando occorre eseguire un'attività, quando bisogna esprimere un parere, quando è necessario fornire informazioni e quando invece una decisione appartiene a un'altra persona. Naturalmente, non tutti i progetti utilizzano una matrice RACI, alcune organizzazioni adottano strumenti differenti o definiscono le responsabilità direttamente nei propri documenti di pianificazione. Ma il principio non cambia.

Le responsabilità devono essere chiare, conosciute e coerenti con l'autorità effettivamente attribuita alle persone.

Ora abbiamo definito il perimetro del progetto, lo abbiamo scomposto in parti gestibili e abbiamo individuato le responsabilità: è arrivato il momento di organizzare il lavoro nel tempo.

Dal lavoro al calendario: attività, dipendenze e Gantt

Quando cominciamo a pianificare un progetto, una delle domande più frequenti è: quando sarà finito?

È una domanda legittima, ma per rispondere in modo attendibile dobbiamo affrontarne altre. Quali attività sono necessarie? Quanto dureranno? Quali risorse serviranno? Quali attività possono procedere contemporaneamente e quali, invece, devono necessariamente attendere il completamento di altre?

Partiamo dalla WBS che abbiamo appena costruito: i pacchetti di lavoro ci permettono di identificare le attività necessarie per produrre i rispettivi risultati. Per esempio, per completare le predisposizioni impiantistiche dovremo eseguire verifiche tecniche, preparare i materiali, realizzare i collegamenti e svolgere i controlli previsti. Una volta individuate le attività, occorre stimarne la durata e definire le relazioni che le collegano.

Queste relazioni vengono chiamate dipendenze.

Nel nostro progetto, il completamento del layout potrebbe essere necessario prima di avviare determinate opere di predisposizione; la consegna delle macchine dovrà precedere la loro installazione; il collaudo finale richiederà il completamento delle attività necessarie a rendere funzionante la linea.

Altre attività, invece, potranno procedere contemporaneamente: mentre un fornitore costruisce le macchine, lo stabilimento potrebbe preparare le infrastrutture necessarie a riceverle.

Riconoscere queste relazioni è importante, perché la durata complessiva del progetto non dipende semplicemente dalla somma delle durate delle singole attività, ma anche dal modo in cui esse sono collegate e organizzate.

Il diagramma di Gantt: leggere il programma dei lavori

Uno degli strumenti più conosciuti per rappresentare il programma temporale di un progetto è il diagramma di Gantt.

Il suo principio è molto semplice: le attività vengono normalmente riportate lungo l'asse verticale, mentre sull'asse orizzontale troviamo il tempo, suddiviso in giorni, settimane o mesi. Ogni attività è rappresentata da una barra orizzontale, la cui posizione indica quando è previsto che inizi e termini. In questo modo possiamo vedere immediatamente quali attività devono essere svolte, quando cominceranno, quanto dureranno e quali potranno sovrapporsi.

Figura 3 – Diagramma di Gantt semplificato. Le barre orizzontali rappresentano la durata e la collocazione temporale delle attività, mentre le frecce indicano le dipendenze tra di esse; il rombo identifica una milestone, cioè un traguardo significativo del progetto.

Quando osserveremo il nostro diagramma, potremo riconoscere anche un altro elemento importante: le milestone.

Una milestone è un punto significativo del progetto, utilizzato per rappresentare il raggiungimento di un risultato, una decisione importante o un evento rilevante. Nel nostro esempio, potrebbero essere milestone l'approvazione del layout, la conclusione dell'installazione o l'accettazione finale della linea.

A differenza di un'attività, una milestone ha normalmente durata pari a zero: rappresenta un evento o un traguardo, non un lavoro che richiede un determinato periodo di tempo. È una distinzione utile perché, durante le riunioni, sentiremo spesso parlare di milestone rispettate, anticipate o posticipate. Quando qualcuno afferma che una milestone è slittata di due settimane, sta dicendo che un evento significativo del progetto è previsto due settimane più tardi rispetto alla data di riferimento.

Non sappiamo ancora, però, quali conseguenze produrrà quello slittamento: per comprenderlo dobbiamo conoscere anche le relazioni tra le attività.

Il percorso critico: perché alcuni ritardi sono più pericolosi di altri

Immaginiamo che il fornitore comunichi un ritardo di cinque giorni nella consegna di una componente: significa necessariamente che l'intero progetto terminerà cinque giorni più tardi? Non sempre.

Potremmo avere attività che dispongono di un certo margine temporale e che possono subire un ritardo senza modificare la data finale prevista; altre attività, invece, potrebbero trovarsi lungo il percorso critico, chiamato in inglese Critical Path.

In un programma di progetto costruito attraverso le relazioni tra le attività, il percorso critico è la sequenza che determina la durata minima prevista del progetto e che, nelle condizioni considerate, non dispone di margine temporale complessivo. Se un'attività sul percorso critico subisce un ritardo e non vengono adottate misure compensative, anche la data finale del progetto tenderà a slittare.

Questo non significa che tutte le altre attività siano meno importanti: significa che, dal punto di vista della programmazione temporale, alcune attività richiedono particolare attenzione perché influenzano direttamente la data di completamento. Per chi partecipa a un progetto è un'informazione preziosa.

Un ritardo di tre giorni su un'attività con un margine disponibile di due settimane può essere gestibile senza conseguenze sulla scadenza finale; lo stesso ritardo su un'attività critica potrebbe richiedere un intervento immediato.

Non è soltanto l'entità del ritardo a determinarne la gravità, ma anche la sua posizione all'interno del programma di progetto.

Non entreremo nei calcoli utilizzati per individuare il percorso critico: ci interessa comprendere che cosa significa quando il Project Manager segnala che una determinata attività è critica e chiede particolare attenzione al rispetto della sua scadenza.

A questo punto abbiamo finalmente un programma temporale: sappiamo che cosa dobbiamo realizzare, chi ne è responsabile, quali attività sono previste e quando dovrebbero essere completate. Ma come faremo, durante lo svolgimento del progetto, a capire se stiamo rispettando il piano? Per rispondere ci serve un riferimento condiviso.

La baseline: il riferimento con cui confrontare la realtà

Immaginiamo che il progetto sia stato pianificato e che il diagramma di Gantt preveda il completamento dell'installazione entro una determinata data. Dopo alcune settimane, il Project Manager aggiorna il programma perché un fornitore ha comunicato un ritardo. Successivamente vengono modificate altre scadenze e alcune attività vengono riprogrammate.

Se ogni volta sostituissimo semplicemente il programma precedente con quello aggiornato, dopo qualche mese potremmo trovarci davanti a un problema: come facciamo a sapere se il progetto sta rispettando quanto avevamo originariamente approvato, se il riferimento cambia continuamente?

È qui che entra in gioco il concetto di baseline.

Nel Project Management, una baseline è una versione approvata di un elemento del piano di progetto, utilizzata come riferimento per misurare e controllare l'andamento del lavoro.

Possiamo avere, in particolare:

• Scope Baseline, che definisce l'ambito approvato del progetto attraverso i relativi elementi di riferimento;
• Schedule Baseline, che costituisce il riferimento approvato per il programma temporale;
• Cost Baseline, che rappresenta il riferimento approvato per il budget distribuito nel tempo.

Questi elementi, considerati insieme, sono spesso indicati come Performance Measurement Baseline, quando vengono integrati per misurare le prestazioni del progetto. Per il momento concentriamoci sulla baseline temporale, perché è la più semplice da comprendere attraverso il nostro esempio.

Supponiamo che il piano approvato preveda il completamento dell'installazione della nuova linea il 30 settembre: quella data diventa un riferimento. Durante il progetto possiamo aggiornare le previsioni, registrare ritardi e modificare la programmazione operativa, ma, confrontando le nuove date previste con la baseline, possiamo capire quanto ci stiamo allontanando dal programma approvato.

Se ora prevediamo di terminare il 15 ottobre, sappiamo che esiste uno scostamento rispetto alla data di riferimento.

Naturalmente, la baseline non è necessariamente immutabile: possono verificarsi modifiche importanti, autorizzate dall'organizzazione, che rendono necessario approvare una nuova versione del riferimento. Pensiamo, per esempio, alla decisione della Direzione di ampliare il progetto aggiungendo una seconda stazione automatizzata: in questo caso potrebbero cambiare l'ambito, i costi e le scadenze. Sarebbe quindi ragionevole valutare e, se approvata la modifica, aggiornare le baseline interessate secondo le procedure previste.

La baseline non serve a dimostrare che il progetto sta andando bene; serve a misurare in modo attendibile quanto la realtà si discosta da ciò che era stato approvato.

Durante il lavoro incontreremo probabilmente anche il termine Change Request, cioè una richiesta di modifica.

Si tratta di una proposta formalizzata per modificare un elemento del progetto, che deve essere valutata e gestita secondo le regole stabilite dall'organizzazione. Non ogni piccolo aggiustamento operativo richiede necessariamente lo stesso livello di autorizzazione, ma i cambiamenti che incidono sui riferimenti approvati devono essere controllati.

Un'ultima considerazione: avere una baseline non significa che il Project Manager debba difendere il piano a qualunque costo, anche quando le condizioni sono cambiate; significa disporre di un riferimento affidabile per comprendere gli scostamenti, valutarne le conseguenze e prendere decisioni consapevoli. Ed è proprio questo che ci permetterà di passare dalla pianificazione al controllo.

Adesso abbiamo un piano, ma che cosa succede quando cominciamo a lavorare?

Ripensiamo al percorso che abbiamo seguito: siamo partiti da un'esigenza aziendale e abbiamo valutato perché fosse opportuno investire nella nuova linea produttiva; abbiamo autorizzato il progetto attraverso il Project Charter, definito il suo ambito, organizzato il lavoro con la WBS, chiarito le responsabilità e costruito un programma temporale attraverso il diagramma di Gantt. Infine, abbiamo introdotto la baseline, che ci permetterà di confrontare l'andamento reale con i riferimenti approvati.

Non abbiamo ancora realizzato nulla, almeno dal punto di vista dell'installazione vera e propria della nostra linea, ma abbiamo costruito le condizioni per poter governare il lavoro che ci attende. Naturalmente, anche la pianificazione richiede attività, tempo, competenze e risorse, non è una parentesi burocratica che precede il lavoro: è essa stessa una parte essenziale del lavoro di progetto.

Vorrei però ribadire un concetto: tutti gli strumenti che abbiamo incontrato devono essere utilizzati con un livello di dettaglio proporzionato alle caratteristiche del progetto; la pianificazione di una piccola modifica impiantistica non avrà necessariamente la stessa complessità di quella richiesta per realizzare un intero stabilimento produttivo.

Lo scopo del Project Management non è produrre documenti: è rendere il progetto comprensibile, organizzabile e governabile.

Adesso, però, le macchine devono arrivare, le predisposizioni devono essere realizzate e le persone devono cominciare a lavorare secondo il programma. E sappiamo bene che, quando si passa dal piano alla realtà, non tutto procede necessariamente come previsto.

Nella prossima parte vedremo quindi come si gestisce l'esecuzione, come si controlla l'avanzamento e come alcuni strumenti, tra cui la curva a S, possono aiutarci a capire se il progetto sta procedendo nella direzione desiderata.

Parte IV – Il progetto è partito: come capiamo se sta andando bene?

Esecuzione: dal piano al lavoro reale

La nuova linea produttiva è stata progettata, i fornitori sono stati selezionati, gli ordini sono partiti e il programma dei lavori è stato approvato: adesso comincia la parte più visibile del progetto.

Nello stabilimento vengono predisposti gli impianti elettrici e pneumatici, si preparano gli spazi destinati alle macchine, arrivano le prime attrezzature e i tecnici cominciano le operazioni di installazione. La Produzione deve coordinarsi con le imprese che lavorano nel reparto, la Manutenzione verifica le predisposizioni, l'Ufficio Tecnico segue gli aspetti progettuali e gli Acquisti mantengono i rapporti con i fornitori per quanto riguarda le condizioni contrattuali e le consegne. È il momento in cui il progetto comincia a trasformarsi da un insieme di documenti e programmi in qualcosa di concreto.

Potremmo pensare che, avendo pianificato correttamente il lavoro, adesso sia sufficiente eseguire le attività previste; in realtà, un piano non si realizza da solo. Le persone devono ricevere le informazioni necessarie, le attività devono essere coordinate, i materiali devono essere disponibili al momento giusto e le decisioni devono essere prese in tempo utile per non ostacolare il lavoro di chi viene dopo.

È proprio questo uno degli aspetti fondamentali del gruppo di processi di Esecuzione.

Il Project Manager deve contribuire a garantire che il lavoro proceda secondo il piano, coordinando le persone e le risorse coinvolte, gestendo le comunicazioni e affrontando i problemi che emergono durante lo svolgimento delle attività. Ma torniamo per un momento al nostro stabilimento.

Supponiamo che il responsabile della Manutenzione segnali che una delle macchine in arrivo richiederà un collegamento elettrico diverso da quello previsto inizialmente: è una questione tecnica, e saranno gli specialisti competenti a individuare la soluzione corretta. Il Project Manager, però, dovrà capire quali conseguenze quella modifica potrà avere sul progetto. Serviranno nuovi materiali? Sarà necessario modificare il programma delle predisposizioni? Occorrerà coinvolgere il fornitore? La nuova soluzione avrà un costo aggiuntivo? Potrà influire sulla data prevista per l'installazione?

Il Project Manager non deve necessariamente conoscere la soluzione tecnica migliore, ma deve assicurarsi che le conseguenze della decisione siano comprese e gestite all'interno del progetto.

Naturalmente, le competenze tecniche e quelle di Project Management possono anche convivere nella stessa persona; ma ciò che conta è riconoscere la differenza tra la responsabilità di realizzare un'attività specialistica e quella di coordinarla con tutte le altre attività necessarie al raggiungimento del risultato. Questo è particolarmente importante nelle organizzazioni funzionali, dove le persone coinvolte nel progetto continuano a dipendere dai propri responsabili aziendali.

Il Project Manager potrebbe non avere un'autorità gerarchica diretta su tutte le risorse impegnate. Dovrà quindi coordinarsi con la Direzione e con i responsabili delle diverse funzioni per ottenere le disponibilità necessarie, risolvere eventuali conflitti di priorità e garantire che gli impegni assunti vengano rispettati.

In pratica, gestire l'esecuzione significa fare in modo che molte attività differenti contribuiscano a un unico risultato, senza perdere di vista le relazioni che le collegano.

Ma mentre le attività procedono, dobbiamo anche capire se il progetto sta rispettando quanto previsto; ed è qui che entra in gioco un'altra parte fondamentale del Project Management.

Monitoraggio e controllo: misurare per poter decidere

Immaginiamo di essere arrivati alla sesta settimana del nostro progetto: il programma prevede che le predisposizioni impiantistiche siano terminate e che alcune macchine siano già state consegnate. Le predisposizioni elettriche sono effettivamente completate, quelle pneumatiche sono ancora in corso e il fornitore principale comunica che una macchina arriverà con dieci giorni di ritardo. Nel frattempo, la Produzione segnala che alcune attività di installazione potrebbero interferire con il funzionamento di una linea esistente.

Il progetto sta andando bene oppure male? La risposta non è così immediata. Potremmo avere attività in ritardo e altre in anticipo; alcuni problemi potrebbero essere recuperabili senza conseguenze sulle scadenze principali, mentre altri potrebbero compromettere la data di avviamento della nuova linea. Per comprendere ciò che sta accadendo abbiamo bisogno di informazioni attendibili e, soprattutto, di confrontare la situazione reale con il piano che avevamo approvato.

Nella Parte III abbiamo incontrato la baseline, cioè il riferimento rispetto al quale possiamo misurare gli scostamenti: adesso cominciamo a utilizzarla.

Il Monitoraggio e controllo comprende le attività necessarie a raccogliere informazioni sull'avanzamento, confrontarle con i riferimenti previsti, individuare gli scostamenti e valutare gli eventuali interventi.

È utile distinguere due momenti:

• • monitorare significa conoscere e interpretare ciò che sta accadendo;
• • controllare significa utilizzare quelle informazioni per decidere come intervenire.

Sapere che una macchina arriverà con dieci giorni di ritardo è un'informazione; verificare se il ritardo influenzerà il percorso critico, valutare quali attività possano essere anticipate e concordare con il fornitore eventuali azioni di recupero significa utilizzare quell'informazione per governare il progetto. Il controllo, quindi, non coincide semplicemente con la verifica che le persone abbiano rispettato le scadenze: è un'attività più ampia, che riguarda l'andamento complessivo del progetto.

Che cosa significa misurare l'avanzamento?

Durante le riunioni di progetto sentiremo spesso affermazioni come: «L'installazione è completata al 70%»; oppure: «Abbiamo realizzato l'80% delle attività previste». Sono informazioni potenzialmente utili, ma richiedono una domanda: come è stata calcolata quella percentuale?

Immaginiamo che l'installazione della linea comprenda dieci attività: se ne abbiamo completate sette, possiamo affermare che il lavoro è al 70%? Non necessariamente: le sette attività completate potrebbero essere relativamente semplici, mentre le tre rimanenti potrebbero richiedere la maggior parte delle ore di lavoro, dei costi o delle competenze specialistiche.

Contare le attività concluse non equivale automaticamente a misurare la quantità di lavoro realizzato.

Possiamo utilizzare criteri differenti: quantità fisiche completate, ore di lavoro riconosciute, deliverable accettati, traguardi raggiunti oppure altre misure coerenti con la natura del progetto; ciò che conta è che il criterio sia definito e condiviso.

Una percentuale di avanzamento è significativa soltanto se sappiamo che cosa misura e come viene determinata.

Lo stesso vale per i costi. Supponiamo che il budget previsto per il progetto sia di un milione di euro e che, a una certa data, siano stati spesi 400.000 euro: possiamo concludere che il progetto sia completato al 40%? No. Potremmo aver sostenuto costi elevati per acquistare macchine che devono ancora essere installate, oppure aver completato una quantità significativa di lavoro con una spesa inferiore a quella prevista.

La spesa sostenuta e l'avanzamento del lavoro non sono la stessa cosa. Questa distinzione sarà particolarmente importante quando parleremo della curva a S.

Rischi, problemi e modifiche: non sono la stessa cosa

Durante il monitoraggio incontreremo anche tre termini che è utile distinguere: rischio, problema e modifica.

Un rischio è un evento o una condizione incerta che, se si verifica, può influire sugli obiettivi del progetto, con effetti negativi oppure positivi. Per esempio, sappiamo che il fornitore di una macchina potrebbe avere difficoltà a rispettare la data concordata: il ritardo non si è ancora verificato, ma possiamo valutarne la probabilità, le possibili conseguenze e le azioni da predisporre. Possiamo registrare queste informazioni in un Risk Register, cioè un registro dei rischi, che aiuta il gruppo di progetto a identificare, valutare e seguire i principali elementi di incertezza.

Un problema, invece, è una situazione che si è già manifestata e che richiede di essere gestita; se il fornitore comunica che la macchina arriverà effettivamente in ritardo, non stiamo più parlando soltanto di una possibilità futura: abbiamo un problema concreto da affrontare.

Una modifica, infine, riguarda il cambiamento di un elemento del progetto: potremmo decidere, per esempio, di cambiare la sequenza di alcune installazioni oppure di introdurre una soluzione tecnica differente. Se la modifica interessa elementi soggetti al controllo formale, potrà essere necessario presentare e valutare una Change Request, secondo le responsabilità e le procedure stabilite.

Non ogni problema richiede una modifica della baseline, così come non ogni modifica nasce necessariamente da un problema: una variazione può essere proposta anche perché, durante il lavoro, è stata individuata un'opportunità di miglioramento.

Gestire correttamente un progetto non significa evitare ogni cambiamento, ma comprendere quali conseguenze produce e decidere consapevolmente se e come attuarlo.

Ecco perché il monitoraggio non deve essere vissuto come un'attività burocratica, ma come uno strumento che permette di mantenere il progetto sotto controllo.

La curva a S: vedere l'avanzamento del progetto

Finora abbiamo parlato di informazioni, misure e confronti con il piano: ma come possiamo rappresentare questi dati in modo che risultino immediatamente comprensibili?

Uno degli strumenti grafici che possiamo incontrare nel Project Management è la curva a S: il nome deriva dalla forma che spesso assume l'andamento cumulato di una grandezza durante lo sviluppo di un progetto.

Nelle fasi iniziali il lavoro procede generalmente con un'intensità relativamente contenuta, perché si stanno predisponendo le condizioni necessarie per le attività successive; durante la parte centrale, quando molte attività entrano nel vivo, l'avanzamento tende ad aumentare più rapidamente; verso la conclusione, infine, il ritmo può rallentare nuovamente, perché rimangono attività di verifica, collaudo, completamento e chiusura.

Se rappresentiamo graficamente l'andamento cumulato, possiamo ottenere una curva che ricorda, appunto, la lettera S. Non tutti i progetti producono necessariamente questa forma, ma è un andamento abbastanza frequente da aver dato il nome alla rappresentazione.

Che cosa rappresenta la curva?

Qui vorrei richiamare una distinzione importante: la curva a S non identifica una sola misura, è una modalità di rappresentazione grafica di una grandezza cumulata nel tempo.

Possiamo costruire curve riferite ai costi, alle ore di lavoro, alle quantità realizzate o ad altre grandezze; per questo motivo, prima di interpretare una curva a S, dobbiamo sempre verificare che cosa rappresentino i suoi assi. Sull'asse orizzontale troviamo normalmente il tempo; sull'asse verticale troviamo invece la grandezza cumulata che abbiamo deciso di rappresentare.

Nel nostro esempio utilizzeremo una misura dell'avanzamento del lavoro espresso in termini percentuali, in modo da rendere immediata la lettura del grafico.

Supponiamo che il progetto della nuova linea produttiva abbia una durata prevista di sette mesi: in base al programma approvato, alla fine del quarto mese avremmo dovuto aver realizzato il 60% del lavoro complessivo, misurato secondo un criterio di avanzamento prestabilito; la situazione effettiva, però, ci dice che ne abbiamo completato soltanto il 45%. Abbiamo quindi uno scostamento di 15 punti percentuali rispetto all'avanzamento pianificato.

La rappresentazione grafica ci permette di vedere immediatamente questa differenza.

Figura 4 – Curva a S dell'avanzamento del progetto. Confronto tra avanzamento pianificato ed effettivo. Al quarto mese si registra uno scostamento di 15 punti percentuali rispetto al piano previsto.

A questo punto potremmo essere tentati di concludere che il progetto è in ritardo, è una prima indicazione ragionevole, ma occorre fare attenzione: uno scostamento nell'avanzamento cumulato non ci dice, da solo, di quanto slitterà la data finale del progetto.

Per valutarlo dobbiamo considerare anche la sequenza delle attività, le dipendenze, il percorso critico e le possibilità di recupero: potremmo avere un avanzamento complessivo inferiore al previsto, ma essere ancora in grado di rispettare la data finale grazie ai margini presenti nel programma o a interventi correttivi; oppure potremmo avere una percentuale complessiva apparentemente soddisfacente e trovarci comunque davanti a un ritardo importante su un'attività critica.

La curva a S, quindi, non sostituisce il diagramma di Gantt e non elimina la necessità di analizzare le cause degli scostamenti: è uno strumento complementare, che permette di osservare l'andamento complessivo e di individuare situazioni che meritano attenzione.

E se vogliamo confrontare anche i costi?

La curva a S può essere utilizzata anche per rappresentare l'andamento economico di un progetto: in questo caso possiamo incontrare una tecnica più articolata, chiamata Earned Value Management (EVM) , che mette in relazione il lavoro pianificato, quello effettivamente realizzato e i costi sostenuti.

Tre termini sono particolarmente importanti:

• Planned Value (PV) : il valore di budget attribuito al lavoro che, a una certa data, avremmo dovuto completare;
• Earned Value (EV) : il valore di budget attribuito al lavoro effettivamente completato alla stessa data;
• Actual Cost (AC) : il costo effettivamente sostenuto per il lavoro realizzato.

Non dobbiamo necessariamente imparare a calcolare questi indicatori per comprendere il funzionamento di un progetto; è però utile riconoscere la differenza tra i tre concetti:

• • il Planned Value ci dice quanto lavoro, espresso in termini di budget, avevamo previsto di completare;
• • l'Earned Value ci dice quanto lavoro abbiamo effettivamente completato, valutandolo secondo il budget previsto;
• • l'Actual Cost ci dice quanto è realmente costato il lavoro svolto.

Valore del lavoro pianificato, valore del lavoro realizzato e costo effettivo sono tre grandezze differenti.

Questa distinzione permette di evitare un errore piuttosto comune, ovvero pensare che spendere meno del previsto significhi necessariamente che il progetto stia andando bene: potremmo aver speso meno semplicemente perché abbiamo realizzato meno lavoro, allo stesso modo, potremmo aver sostenuto costi superiori alle previsioni senza aver completato una quantità di lavoro proporzionalmente maggiore.

Non entreremo nelle formule e negli indicatori utilizzati dall'Earned Value Management: richiederebbero un approfondimento specifico e andrebbero oltre gli obiettivi di questo articolo.

Per il nostro lettore è sufficiente comprendere che una rappresentazione grafica può rendere visibili gli scostamenti, ma per interpretarli correttamente dobbiamo conoscere il significato delle grandezze utilizzate.

Ed è proprio per questo che, durante una riunione di avanzamento, non basta guardare un grafico: occorre capire che cosa ci sta raccontando.

Dentro una riunione di avanzamento

Siamo arrivati a un momento che considero particolarmente importante per chi partecipa a un progetto senza possedere una formazione specifica di Project Management.

Immaginiamo di entrare nella sala riunioni del nostro stabilimento, dove è prevista la riunione periodica di avanzamento del progetto della nuova linea produttiva, e sono presenti il Project Manager e alcuni rappresentanti delle funzioni coinvolte: Produzione, Ufficio Tecnico, Acquisti, Manutenzione e Qualità.

Sul monitor viene proiettato il diagramma di Gantt aggiornato; il Project Manager apre la riunione spiegando che le predisposizioni impiantistiche sono quasi completate, ma che la consegna di una macchina subirà un ritardo di dieci giorni.

Aggiunge poi: «La consegna interessa un'attività sul percorso critico: se non interveniamo, rischiamo di posticipare la milestone di completamento dell'installazione».

Fermiamoci su questa frase: qualche pagina fa avremmo probabilmente riconosciuto soltanto la parola ritardo, adesso sappiamo interpretare un'informazione molto più precisa.

Il ritardo riguarda un'attività che può influire direttamente sulla data finale del progetto e potrebbe compromettere il raggiungimento di un traguardo significativo.

Il Project Manager chiede quindi agli Acquisti di verificare con il fornitore se sia possibile anticipare almeno una parte della consegna; all'Ufficio Tecnico chiede di valutare se alcune operazioni possano essere eseguite modificando la sequenza prevista; alla Produzione chiede di verificare la disponibilità degli spazi per un'eventuale riorganizzazione delle attività di installazione.

Notiamo un aspetto importante: il Project Manager non sta chiedendo a tutti di risolvere lo stesso problema nello stesso modo, sta coordinando competenze differenti per valutare le possibili alternative e comprenderne le conseguenze sul progetto.

Durante la riunione interviene il responsabile della Manutenzione: segnala che una modifica alla sequenza di installazione potrebbe richiedere di anticipare alcune predisposizioni, per le quali occorrerà rendere disponibili due tecnici specializzati. A questo punto il Project Manager dovrà verificare se quelle risorse siano effettivamente disponibili e quali conseguenze il loro impiego anticipato potrebbe avere sulle altre attività.

Poco dopo viene presentato il rapporto di avanzamento, dove la curva a S mostra che il lavoro effettivamente realizzato è inferiore a quello previsto.

Il Project Manager osserva: «Siamo al 45% dell'avanzamento, contro il 60% previsto alla data di rilevazione». Ora sappiamo che cosa significa: il progetto ha realizzato meno lavoro di quanto fosse previsto dal programma di riferimento, secondo il criterio di misurazione utilizzato.

Non significa automaticamente che abbiamo speso troppo, né che la data finale slitterà necessariamente nella stessa proporzione; significa che dobbiamo comprendere le cause dello scostamento e verificare quali conseguenze possa produrre.

Durante la discussione emerge anche un'altra questione: la Qualità propone di aggiungere un sistema di controllo automatico che non era previsto nella configurazione iniziale della linea; la soluzione potrebbe migliorare il processo produttivo, ma richiederebbe componenti aggiuntivi, una modifica al software e alcune giornate di lavoro supplementari. Il Project Manager chiede quindi di formalizzare la proposta e di valutarne gli effetti su costi, tempi e requisiti. Abbiamo appena incontrato una possibile Change Request.

La richiesta non viene necessariamente respinta, ma nemmeno accettata automaticamente soltanto perché rappresenta un miglioramento tecnico: deve essere valutata secondo le responsabilità e le modalità di approvazione previste.

Infine, il Project Manager torna a parlare dei rischi: chiede se il ritardo del fornitore possa influire anche sulle consegne successive e se siano emerse nuove situazioni da registrare; gli Acquisti segnalano che un secondo componente potrebbe incontrare difficoltà di approvvigionamento. In questo caso il ritardo non si è ancora verificato: siamo quindi davanti a un rischio da valutare, non a un problema già manifestato. La riunione termina con alcune decisioni, la definizione dei responsabili delle azioni concordate e le relative scadenze.

Ecco che cosa abbiamo appena osservato: durante questa normale riunione di avanzamento abbiamo incontrato il Gantt, il percorso critico, le milestone, la baseline, la curva a S, le responsabilità, i rischi e la gestione delle modifiche.

Non erano argomenti scolastici e non erano termini utilizzati per rendere più complicata la conversazione: erano strumenti e concetti necessari per comprendere la situazione, coordinare le persone e prendere decisioni.

E io, che non sono un Project Manager, che cosa devo fare?

Torniamo alla domanda dalla quale siamo partiti all'inizio dell'articolo.

Immaginiamo che tu sia il responsabile della Manutenzione, oppure un tecnico dell'Ufficio Tecnico, un addetto agli Acquisti o un professionista della Qualità: non devi necessariamente essere in grado di costruire un diagramma di Gantt, calcolare il percorso critico o predisporre un sistema di Earned Value Management; ma sapere che cosa rappresentano questi strumenti ti permette di comprendere meglio le informazioni che ricevi e, soprattutto, di riconoscere quando il tuo contributo può influire sull'andamento complessivo del progetto.

Se scopri che un'attività di tua competenza richiederà più tempo del previsto, è importante comunicarlo tempestivamente; se individui un rischio che potrebbe compromettere una consegna, devi segnalarlo quando esiste ancora la possibilità di intervenire, non soltanto quando il problema si è già manifestato; se proponi una modifica tecnica, devi considerare che potrebbe avere conseguenze su altre attività, sui costi e sulle scadenze; se ti viene chiesto di esprimere un parere o fornire un'informazione, conoscere il contesto nel quale quella richiesta si inserisce può aiutarti a rispondere in modo più utile.

Partecipare consapevolmente a un progetto significa comprendere che le proprie attività non sono isolate, ma fanno parte di un sistema di relazioni, dipendenze e responsabilità.

Questo non significa rinunciare alle proprie competenze specialistiche, significa metterle a disposizione del progetto nel momento opportuno e con una migliore comprensione delle conseguenze che le proprie decisioni possono produrre; ed è proprio questo uno degli obiettivi del Project Management: permettere a persone con competenze diverse di lavorare insieme verso un risultato comune.

Il controllo non serve a raccontare il passato, ma a governare il futuro

Prima di concludere questa parte, vorrei soffermarmi su di un ultimo aspetto, sul pensiero che quando parliamo di monitoraggio e controllo potremmo immaginare un'attività rivolta soprattutto al passato: quanto lavoro abbiamo completato? quanto abbiamo speso? quali scadenze abbiamo rispettato e quali no?

Sono domande necessarie, ma non sufficienti: il vero valore del controllo sta nella possibilità di utilizzare ciò che sappiamo oggi per decidere che cosa fare domani.

Se un'attività è in ritardo, la questione non è soltanto registrare lo scostamento: dobbiamo comprenderne le cause, valutarne le conseguenze e decidere se e come intervenire; se emerge un nuovo rischio, non basta inserirlo in un registro: occorre capire se possa essere ridotto, evitato, trasferito oppure accettato consapevolmente, secondo le caratteristiche della situazione; se una modifica può migliorare il risultato, non dobbiamo respingerla automaticamente per difendere il piano originario: dobbiamo valutarne gli effetti e decidere se i benefici giustifichino le conseguenze.

E se le condizioni del progetto cambiano in modo significativo, dobbiamo essere capaci di aggiornare le previsioni e, quando necessario, sottoporre ad approvazione le modifiche ai riferimenti stabiliti.

In altre parole, pianificare significa costruire un riferimento; monitorare significa comprendere ciò che sta accadendo; controllare significa utilizzare quelle conoscenze per mantenere il progetto governabile.

Ora possiamo immaginare che la nostra linea produttiva sia stata finalmente installata, che le attività di verifica siano state completate e che il nuovo impianto sia pronto per entrare in funzione: il lavoro sembra terminato, ma possiamo davvero considerare concluso il progetto?

Nella prossima parte vedremo perché la chiusura non coincide semplicemente con la fine delle attività e perché un progetto dovrebbe lasciare all'organizzazione non soltanto il risultato per il quale è stato realizzato, ma anche un patrimonio di conoscenze ed esperienze da utilizzare in futuro.

Parte V – Chiudere il progetto e conservare l'esperienza

Quando possiamo dire che il progetto è finito?

Torniamo per un'ultima volta nel nostro stabilimento: la nuova linea produttiva è stata installata, i collegamenti sono stati completati, le macchine funzionano e i collaudi hanno dato esito positivo; la Produzione è pronta a utilizzare il nuovo impianto e qualcuno, probabilmente, sta già pensando al prossimo investimento.

Possiamo considerare concluso il progetto? Verrebbe naturale rispondere di sì; del resto, il risultato che volevamo ottenere è davanti ai nostri occhi.

Eppure, aver completato materialmente il lavoro non significa necessariamente aver completato tutte le attività necessarie alla chiusura del progetto.

Prima di dichiararlo concluso dobbiamo verificare che quanto realizzato corrisponda ai requisiti concordati e che i risultati siano stati formalmente accettati dalle persone o dalle funzioni che ne hanno la responsabilità. Nel nostro esempio dovremo verificare che la linea raggiunga le prestazioni richieste, che siano stati completati i collaudi previsti e che tutta la documentazione necessaria sia disponibile; potrebbero esserci manuali da consegnare, attività di formazione da completare, aspetti contrattuali da definire e responsabilità da trasferire dalla struttura di progetto alle funzioni che gestiranno l'impianto; la Manutenzione dovrà disporre delle informazioni necessarie per intervenire sulle macchine, la Produzione dovrà conoscere le modalità operative e la Qualità dovrà poter effettuare i controlli previsti.

Anche le risorse impegnate nel progetto dovranno essere progressivamente rilasciate, secondo le modalità concordate con l'organizzazione. Tutte queste attività fanno parte del processo di chiusura.

Chiudere un progetto significa verificare e formalizzare il completamento degli impegni previsti, consegnare i risultati e assicurare che possano essere utilizzati dall'organizzazione.

C'è però una distinzione che considero importante:, ovvero che il completamento del progetto non coincide necessariamente con il momento in cui l'azienda avrà ottenuto tutti i benefici economici e organizzativi attesi: la nuova linea potrebbe essere stata installata correttamente, rispettando i requisiti concordati, ma serviranno probabilmente alcuni mesi per verificare se l'aumento di produttività, la riduzione degli scarti o il miglioramento dei costi industriali saranno effettivamente raggiunti. Questi benefici potranno essere misurati anche dopo la chiusura del progetto, durante la normale gestione operativa, secondo le responsabilità definite dall'organizzazione.

Il progetto consegna un risultato; i benefici che hanno giustificato l'investimento possono maturare anche successivamente.

È una distinzione che ci aiuta a comprendere perché sia importante definire fin dall'inizio non soltanto che cosa intendiamo realizzare, ma anche quali vantaggi ci aspettiamo di ottenere.

Lessons Learned: perché l'esperienza non deve andare perduta

Abbiamo installato la nuova linea, completato le verifiche, consegnato la documentazione e formalizzato la chiusura del progetto; ma prima di congedare definitivamente il gruppo di lavoro vorrei fermarmi su un'ultima domanda:

che cosa abbiamo imparato?

Durante il progetto avremo probabilmente incontrato difficoltà che non avevamo previsto: un fornitore potrebbe aver consegnato in ritardo, alcune predisposizioni potrebbero aver richiesto modifiche, una soluzione tecnica potrebbe essersi rivelata meno efficace di quanto immaginavamo; ma avremo anche scoperto cose che hanno funzionato particolarmente bene: forse il coinvolgimento anticipato della Manutenzione ha evitato problemi durante l'installazione, forse una diversa organizzazione dei collaudi ha permesso di ridurre i tempi di avviamento, oppure una scelta compiuta dall'Ufficio Tecnico ha semplificato sensibilmente il lavoro dei fornitori.

Tutto questo costituisce un patrimonio di esperienza.

Nel Project Management utilizziamo il termine Lessons Learned, letteralmente lezioni apprese, per indicare le conoscenze ricavate dall'esperienza che possono essere utilizzate per migliorare il lavoro futuro. Non dobbiamo immaginarle come un semplice elenco di errori commessi: le Lessons Learned comprendono ciò che non ha funzionato, ma anche ciò che ha funzionato bene e che merita di essere ripetuto.

Per essere realmente utili, però, queste conoscenze devono essere raccolte in modo comprensibile, indicando le circostanze nelle quali sono maturate, le conseguenze osservate e le indicazioni che possiamo ricavarne: scrivere «il fornitore è arrivato in ritardo» serve a poco; molto più utile sarebbe comprendere perché quel ritardo si è verificato, quali conseguenze ha prodotto e che cosa potremmo fare diversamente nel prossimo progetto: anticipare alcune verifiche tecniche, prevedere controlli intermedi sulla fornitura oppure modificare le modalità con cui vengono definite e monitorate le scadenze contrattuali.

Naturalmente, le Lessons Learned non devono essere raccolte soltanto alla fine: possiamo documentarle durante tutto lo svolgimento del progetto, soprattutto quando un problema è appena stato risolto o quando un'esperienza positiva è ancora ben presente nella memoria delle persone coinvolte. La chiusura rappresenta comunque un'occasione importante per riordinare queste informazioni e renderle disponibili all'organizzazione

E vorrei sottolineare un ultimo aspetto: le conoscenze raccolte producono valore soltanto se qualcuno le utilizza.

Se alla conclusione di ogni progetto prepariamo un documento che viene archiviato e non viene più consultato, abbiamo probabilmente rispettato una procedura, ma non abbiamo sfruttato fino in fondo l'esperienza acquisita. Il vero risultato si ottiene quando, avviando un nuovo progetto, qualcuno recupera quelle informazioni e le utilizza per evitare un problema già conosciuto o ripetere una soluzione che aveva dimostrato di funzionare.

È così che l'esperienza di un gruppo di lavoro può diventare conoscenza condivisa e contribuire al miglioramento dell'intera organizzazione.

Non sei diventato un Project Manager, ma almeno adesso sai dove ti trovi

Siamo arrivati alla fine del nostro percorso: abbiamo cominciato raccontando come il Project Management sia progressivamente diventato una disciplina professionale, capace di raccogliere e organizzare conoscenze sviluppate attraverso decenni di esperienza; abbiamo conosciuto i cinque gruppi di processo e seguito il nostro progetto della nuova linea produttiva dall'idea iniziale fino alla sua conclusione. Lungo il percorso abbiamo incontrato termini che, per chi non ha mai frequentato un corso di Project Management, possono sembrare inizialmente poco comprensibili: Project Charter, Scope, WBS, RACI, Gantt, milestone, percorso critico, baseline, curva a S e Lessons Learned.

Adesso sappiamo che cosa significano e, soprattutto, perché vengono utilizzati e quali informazioni ci permettono di comprendere.

Se domani parteciperai a una riunione di progetto e sentirai parlare di una milestone in ritardo, saprai che non si tratta semplicemente di un'attività non completata, ma di un traguardo significativo il cui slittamento potrebbe avere conseguenze sul programma; se qualcuno presenterà un diagramma di Gantt, saprai riconoscere le attività, le loro durate e le principali relazioni temporali; se il Project Manager parlerà di uno scostamento dalla baseline, comprenderai che sta confrontando la situazione reale con un riferimento precedentemente approvato; e se ti verrà chiesto di contribuire a una valutazione tecnica, fornire un'informazione o segnalare un rischio, avrai qualche elemento in più per capire perché il tuo contributo è importante e quali conseguenze potrebbe avere sulle altre attività.

Non significa che sarai diventato un Project Manager: per svolgere professionalmente quel ruolo servono conoscenze più approfondite, esperienza, capacità organizzative e competenze che non possono essere acquisite attraverso un singolo articolo; ma non era questo il nostro obiettivo.

Volevo aiutarti a comprendere il linguaggio del Project Management e a riconoscere il tuo posto all'interno di un progetto, senza perdere di vista le competenze professionali che già possiedi.

Perché un progetto non ha bisogno soltanto di un bravo Project Manager, ha bisogno anche di persone che conoscano il proprio lavoro, comprendano gli obiettivi comuni e sappiano mettere a disposizione le proprie competenze nel momento in cui sono necessarie.

E se, dopo questa lettura, la prossima riunione di progetto ti sembrerà un po' meno complicata, avremo raggiunto il risultato che ci eravamo proposti.

Le parole del Project Management: una scheda da tenere a portata di mano

Durante questo percorso abbiamo incontrato numerosi termini, molti dei quali in inglese, che fanno parte del linguaggio utilizzato quotidianamente nella gestione dei progetti. Ho pensato quindi di raccogliere quelli più importanti in una scheda di consultazione, con una spiegazione sintetica del loro significato.

Non è un glossario completo del Project Management e non vuole sostituire le spiegazioni che abbiamo sviluppato nell'articolo: è semplicemente uno strumento al quale potrai tornare quando, durante una riunione o leggendo un documento di progetto, incontrerai una parola che non ricordi con precisione.