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 costruita prima di aver compreso le dipendenze. Responsabilità distribuite tra un team senza una matrice RACI che le rendesse esplicite. Rischi discussi una volta in una riunione di avvio e mai messi per iscritto. Questi non sono fallimenti dell'esecuzione. Sono fallimenti della pianificazione che l'esecuzione deve poi assorbire.
La ricerca sui fallimenti dei progetti individua costantemente le stesse cause: un ambito poco chiaro che consente ai requisiti di espandersi indefinitamente, tempistiche irrealistiche costruite senza comprendere tutto il 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 all'inizio.
Paul - l'agent di gestione dei progetti di KissMySkills - applica questo framework in un'unica sessione di raccolta delle informazioni. 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. Costruito all'inizio, prima che inizi una singola attività.
Paul crea la dichiarazione dell'ambito, la struttura di scomposizione del lavoro, la matrice RACI, la tempistica del percorso critico e il registro dei rischi - un piano di progetto completo in un'unica 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 affronta una diversa modalità di fallimento.
Una dichiarazione dell'ambito che definisce cosa rientra nell'ambito e, 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 individualmente ragionevoli ma complessivamente disastrose per le tempistiche.
Una struttura di scomposizione del lavoro che suddivide i deliverable del progetto in flussi di lavoro, poi in attività, finché ogni elemento di lavoro non è assegnato e dimensionato. La WBS è lo strumento che porta alla luce il lavoro che viene sempre sottostimato perché si colloca tra le principali milestone - i test di integrazione, il processo di approvazione, la documentazione, la formazione, le attività di transizione.
Un cronoprogramma delle milestone costruito sul percorso critico, ovvero la sequenza di attività in cui ogni ritardo fa slittare la data di conclusione del progetto. La maggior parte dei cronoprogrammi di progetto viene elaborata partendo a ritroso da una data di conclusione desiderata, senza identificare quale percorso attraverso le attività 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 assegna 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 non è stato completato da nessuno.
Un registro dei rischi che documenta i rischi identificati, ne valuta la probabilità e l'impatto, assegna azioni di mitigazione e indica un responsabile del monitoraggio di ciascun rischio per tutta la durata del progetto.
Un piano di comunicazione con gli stakeholder che specifica chi riceve quale aggiornamento e con quale frequenza, così gli stakeholder non vengono mai colti di sorpresa dallo stato del progetto e il project manager non si trova mai senza un aggiornamento preparato per una riunione importante.
Ambito prima del cronoprogramma: la regola più violata nella gestione dei progetti
I cronoprogrammi elaborati senza un ambito chiaro non sono cronoprogrammi: sono stime dalla precisione illusoria. Il motivo più comune per cui i progetti non rispettano le scadenze non è una cattiva esecuzione da parte della squadra. È che il cronoprogramma è stato elaborato prima di comprendere pienamente 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.
Prima di elaborare qualsiasi cronoprogramma, Paul chiede informazioni su deliverable, dipendenze, vincoli ed esclusioni esplicite. La dichiarazione dell'ambito è il primo output: viene confermata e approvata prima di fissare una sola data di milestone. Prevenire lo scope creep è molto più semplice che gestirlo dopo che è iniziato, e le esclusioni esplicite nella dichiarazione dell'ambito danno al project manager l'autorità di dire «questo non rientra nell'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 deliverable 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: viene scoperto tardi, gestito in fretta e attribuito alla squadra.
Una matrice RACI previene questo problema rendendo chiare le responsabilità prima dell'inizio dell'esecuzione. Responsible è la persona che svolge il lavoro. Accountable è l'unica persona designata 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 hanno un ruolo.
La RACI è pensata per essere esaminata durante la riunione di avvio del progetto, non inviata come documento da esaminare in modo asincrono, ma discussa dal team affinché ogni persona confermi il proprio ruolo, comprenda le proprie responsabilità e abbia l'opportunità di sollevare dubbi prima dell'inizio del progetto. I conflitti nella RACI scoperti all'avvio richiedono cinque minuti per essere risolti. 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. I rischi identificati quando si stanno già verificando 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 ogni rischio e un responsabile designato per il monitoraggio di ciascun rischio durante tutto il ciclo di vita del progetto. I rischi identificati includono sia quelli ovvi, come la disponibilità delle risorse chiave e i ritardi nelle dipendenze di terze parti, sia i rischi specifici della categoria che l'esperienza indica come 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 predisposti. Il piano di recupero affronta la causa effettiva invece di limitarsi a comprimere il calendario 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 skill 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 prompt di sistema.
