Perché la maggior parte dei progetti fallisce prima ancora di iniziare
A posteriori, il fallimento di un progetto raramente è una sorpresa. Le cause profonde sono quasi sempre visibili nel piano originale, o nella sua assenza. Un elenco di attività con date e senza una dichiarazione dell'ambito. Una tempistica definita prima di comprendere le dipendenze. Responsabilità distribuite nel team senza una RACI che le renda esplicite. Rischi discussi una volta durante una riunione di avvio e mai messi per iscritto. Non sono fallimenti dell'esecuzione. Sono fallimenti della pianificazione che l'esecuzione deve poi assorbire.
Le ricerche sui fallimenti dei progetti individuano costantemente le stesse cause: un ambito poco chiaro che consente ai requisiti di espandersi indefinitamente, tempistiche irrealistiche definite senza comprendere l'intero lavoro, responsabilità ambigue che creano lacune e duplicazioni e rischi prevedibili ma non mitigati. Ognuna di queste è un problema di pianificazione, non di esecuzione, e ciascuna è prevenibile applicando il framework giusto fin dall'inizio.
Paul - l'agent di project management di KissMySkills - applica questo framework in una sola sessione iniziale. Il risultato è un piano di progetto completo costruito sulla metodologia applicata dai project manager esperti: dichiarazione dell'ambito con esclusioni esplicite, struttura di scomposizione del lavoro, tempistica delle milestone sul percorso critico, matrice RACI, registro dei rischi con azioni di mitigazione e piano di comunicazione con gli stakeholder. Elaborato all'inizio, prima dell'avvio di una sola attività.
Paul definisce la dichiarazione dell'ambito, la struttura di scomposizione del lavoro, la matrice RACI, la tempistica sul percorso critico e il registro dei rischi: un piano di progetto completo in una sola sessione.
Visualizza Paul →Cosa include davvero un piano di progetto completo
La maggior parte dei documenti chiamati "piani di progetto" sono elenchi di attività con date e un nome in cima. Un piano di progetto completo ha sei componenti che l'approccio basato sull'elenco delle attività omette, ciascuna delle quali affronta una diversa modalità di fallimento.
Una dichiarazione dell'ambito che definisce cosa rientra nell'ambito e, cosa altrettanto importante, cosa ne è esplicitamente escluso. Senza esclusioni esplicite, l'ambito si espande fino a occupare tutto il tempo e il budget disponibili, spinto da richieste degli stakeholder ragionevoli prese singolarmente ma disastrose per le tempistiche nel loro insieme.
Una struttura di scomposizione del lavoro che suddivide i deliverable del progetto in flussi di lavoro e poi in attività, finché ogni elemento di lavoro non è assegnato e dimensionato. La WBS è lo strumento che porta alla luce il lavoro sempre sottostimato perché si colloca tra le principali milestone: i test di integrazione, il processo di approvazione, la documentazione, la formazione e le attività di transizione.
Un cronoprogramma delle milestone costruito sul percorso critico: la sequenza di attività in cui ogni ritardo posticipa la data di conclusione del progetto. La maggior parte dei cronoprogrammi di progetto viene costruita a ritroso partendo da una data di fine desiderata, senza identificare quale percorso attraverso il lavoro sia realmente critico. Quando slitta un’attività non critica, è un problema. Quando slitta un’attività del percorso critico, slitta l’intero progetto.
Una matrice RACI che assegni i ruoli di Responsible, Accountable, Consulted e Informed per ogni deliverable significativo. Lo strumento che rende esplicita la responsabilità prima dell’inizio dell’esecuzione, invece di scoprire alla quarta settimana che due persone pensavano che l’altra fosse responsabile di un deliverable che nessuno ha completato.
Un registro dei rischi che documenti i rischi identificati, ne valuti probabilità e impatto, assegni azioni di mitigazione e indichi un responsabile per il monitoraggio di ciascun rischio durante tutto il progetto.
Un piano di comunicazione con gli stakeholder che specifichi chi riceve quale aggiornamento e con quale frequenza, così che gli stakeholder non siano mai sorpresi dallo stato del progetto e il project manager non si trovi mai senza un aggiornamento preparato per una riunione importante.
Ambito prima del cronoprogramma: la regola più violata nella gestione dei progetti
I cronoprogrammi creati senza un ambito chiaro non sono cronoprogrammi: sono stime con una falsa precisione. Il motivo più comune per cui i progetti non rispettano le scadenze non è una scarsa esecuzione da parte del team. È che il cronoprogramma è stato creato prima di comprendere appieno l’ambito, o prima di identificare tutte le dipendenze, o prima che qualcuno ponesse le domande capaci di far emergere il lavoro che non compare nei requisiti iniziali.
Paul chiede informazioni su deliverable, dipendenze, vincoli ed esclusioni esplicite prima di costruire qualsiasi cronoprogramma. La dichiarazione dell’ambito è il primo output: viene confermata e approvata prima di fissare anche una sola data di milestone. Prevenire lo scope creep è significativamente più facile che gestirlo dopo che è iniziato, e le esclusioni esplicite nella dichiarazione dell’ambito danno al project manager l’autorità di dire «questo è fuori ambito» quando arrivano nuove richieste. Senza esclusioni documentate, ogni conversazione del tipo «sembra semplice, possiamo aggiungerlo?» diventa una negoziazione.
RACI: lo strumento che previene la diffusione della responsabilità
La diffusione della responsabilità è l’equivalente, nella gestione dei progetti, dell’effetto spettatore: quando più persone sono associate a un risultato senza una responsabilità chiaramente assegnata, ciascuna presume che se ne stia occupando qualcun altro. Il risultato è un deliverable che non è un problema di nessuno finché non diventa un problema di tutti - scoperto in ritardo, gestito di fretta e attribuito al team.
Una matrice RACI previene questo problema rendendo inequivocabile l'assegnazione delle responsabilità prima dell'inizio dell'esecuzione. Responsible è la persona che svolge il lavoro. Accountable è l'unica persona indicata che risponde del risultato: può essercene una sola. Consulted sono le persone il cui contributo è necessario. Informed sono le persone che devono conoscere lo stato di avanzamento. Paul crea una RACI per ogni deliverable significativo di ogni flusso di lavoro del progetto, includendo tutti gli stakeholder che ricoprono un ruolo.
La matrice RACI è pensata per essere esaminata durante la riunione di avvio del progetto, non inviata come documento da rivedere in modo asincrono, ma discussa dal team affinché ogni persona confermi il proprio ruolo, comprenda la propria responsabilità e abbia l'opportunità di sollevare dubbi prima dell'inizio del progetto. I conflitti nella RACI individuati all'avvio si risolvono in cinque minuti. Quelli scoperti a metà progetto richiedono settimane.
Registro dei rischi creato prima che i rischi si concretizzino
Il momento migliore per creare un registro dei rischi è all'avvio del progetto, quando l'attenzione del team è rivolta al futuro e le opzioni sono ancora aperte. I rischi identificati all'inizio possono essere mitigati. Quelli identificati quando si stanno verificando attivamente possono solo essere gestiti: le opzioni sono più limitate, il costo è maggiore e l'impatto sulla tempistica è peggiore.
Paul produce un registro dei rischi con i rischi identificati, valutazioni della probabilità e dell'impatto (Alta/Media/Bassa), azioni di mitigazione specifiche per ciascun rischio e un responsabile nominativo per il monitoraggio di ogni rischio durante l'intero ciclo di vita del progetto. I rischi identificati includono sia quelli più ovvi, come la disponibilità delle risorse chiave e i ritardi nelle dipendenze di terze parti, sia i rischi specifici della categoria che l'esperienza suggerisce essere più comuni per questo tipo di progetto.
Per i progetti già in difficoltà
Paul diagnostica e recupera anche i progetti in difficoltà, non si limita a pianificarne di nuovi. Per un progetto in ritardo, fuori budget o soggetto a un'espansione incontrollata dell'ambito, le domande iniziali fanno emergere la causa principale: un ambito originale poco chiaro, una tempistica irrealistica, responsabilità ambigue o rischi che si sono concretizzati senza piani di mitigazione. Il piano di recupero affronta la causa effettiva invece di limitarsi a comprimere il programma rimanente, perché applicare una compressione dei tempi a un piano fondamentalmente viziato produce una versione diversa dello stesso fallimento.
Come avviare una sessione di pianificazione del progetto con Paul
Carica il file delle competenze di Paul in Claude Projects. Incolla il prompt di attivazione. Paul pone domande iniziali sul progetto: l'obiettivo, i deliverable, la scadenza, la composizione del team, le dipendenze note e i vincoli. Rispondi in modo specifico: più dettagli fornisci sul progetto reale, più accurato sarà il piano. La sessione completa produce un piano di progetto completo in 30 minuti. Paul funziona con Claude, ChatGPT o qualsiasi chat AI che accetti system prompt.