Un progetto ben gestito non parte dall’operatività, ma da una mappa chiara: obiettivo, passaggi, responsabilità e criteri di chiusura. Nella pianificazione aziendale, uno schema delle fasi di un progetto serve proprio a questo: rende visibile il percorso prima che i problemi diventino costi, ritardi o conflitti tra team. In questo articolo ricostruisco la struttura in modo pratico, con gli elementi da inserire in ogni fase, gli errori da evitare e un esempio utile per contesti HR e digitalizzazione.
Le informazioni essenziali da avere prima di avviare un progetto
- Un progetto efficace passa di solito da cinque fasi: avvio, pianificazione, esecuzione, monitoraggio e chiusura.
- Ogni fase deve produrre un output concreto: obiettivi, piano, deliverable, KPI, consuntivo.
- Un diagramma funziona solo se rende visibili responsabilità, dipendenze e criteri di passaggio.
- Nel lavoro aziendale conviene aggiungere sempre rischio, budget, capacità del team e approvazioni.
- Per progetti HR o digitali, il controllo del cambiamento conta quanto il piano tecnico.
Perché uno schema delle fasi conta nella pianificazione aziendale
In azienda non basta avere una buona idea: serve un percorso che trasformi quell’idea in risultati misurabili. Il PMI descrive il ciclo di vita del progetto come una sequenza di fasi collegate; Atlassian lo riassume in avvio, pianificazione, esecuzione, monitoraggio e chiusura. Questa struttura funziona perché aiuta a decidere prima chi fa cosa, con quali risorse e in quale momento, invece di correggere tutto a progetto già partito.
Io lo considero particolarmente utile quando un’iniziativa coinvolge più funzioni, per esempio HR, IT, operations e management. In questi casi, il problema non è solo “fare il lavoro”, ma farlo nell’ordine giusto e con criteri condivisi. Uno schema ben costruito riduce le ambiguità, rende più semplici le approvazioni e permette di capire subito se il progetto sta perdendo direzione.
Prima di entrare nel merito delle singole fasi, conviene distinguere tra fasi, attività e risultati attesi. È lì che si gioca la qualità del diagramma. Da qui il passaggio naturale è capire come leggerlo senza scambiarlo per una semplice lista di compiti.
Come leggere le fasi senza confonderle con le attività
Io faccio sempre una distinzione netta: le fasi sono i contenitori logici, le attività sono i mattoni. Se confondi i due livelli, il diagramma diventa solo una lista elegante ma poco utile. Una fase dice perché stiamo facendo qualcosa e cosa deve essere vero per passare oltre; le attività spiegano come arrivarci.
| Fase | Obiettivo | Output atteso | Errore tipico |
|---|---|---|---|
| Avvio | Definire il bisogno e il perimetro | Mandato, obiettivo, sponsor, stakeholder | Partire senza una decisione chiara |
| Pianificazione | Trasformare l’idea in un piano operativo | WBS, calendario, budget, rischi | Confondere il piano con una lista di to-do |
| Esecuzione | Produrre i risultati previsti | Deliverable, test, formazione, configurazioni | Cambiare il perimetro senza controllo |
| Monitoraggio e controllo | Verificare se si resta sulla rotta giusta | KPI, report, change log, correzioni | Accorgersi tardi degli scostamenti |
| Chiusura | Consegnare e capitalizzare l’esperienza | Accettazione, documentazione, lesson learned | Chiudere senza apprendimento |
Se il diagramma si ferma ai nomi delle fasi, manca il punto. Deve mostrare anche quando una fase si chiude e con quale evidenza, altrimenti il team passa avanti “a sensazione”. La differenza tra un buon schema e uno debole è spesso tutta qui, nel collegare la sequenza alla verifica reale.
Da qui si passa a una domanda ancora più pratica: che cosa deve comparire dentro ogni fase per renderla davvero utile a chi lavora sul progetto?
Cosa inserisco in ogni fase per renderla davvero operativa
Un buon schema non è decorativo: deve aiutare chi decide e chi esegue. Nella pratica, io considero indispensabili quattro blocchi di informazioni, perché senza questi elementi il progetto sembra ordinato ma non lo è davvero.
Obiettivo e deliverable
Ogni fase deve produrre un risultato visibile. Il termine deliverable indica proprio il risultato tangibile atteso, non l’attività svolta per arrivarci. Se non lo scrivi in modo esplicito, il rischio è lavorare molto e non sapere con precisione cosa si stia consegnando.
Qui aiuta anche un obiettivo formulato bene: specifico, misurabile e coerente con il risultato atteso. In un progetto HR, per esempio, non basta scrivere “migliorare l’onboarding”; è molto più utile definire “ridurre il tempo medio di inserimento dei nuovi assunti” oppure “uniformare il processo su tutte le sedi”.
Responsabili e dipendenze
Quando più funzioni collaborano, il problema non è quasi mai la mancanza di volontà, ma l’ambiguità sui ruoli. La matrice RACI, cioè lo strumento che chiarisce chi è responsabile, chi approva, chi viene consultato e chi deve essere informato, evita molti attriti inutili. Io la uso soprattutto nei progetti con interdipendenze forti, perché rende visibile chi deve fare il primo passo e chi deve sbloccare il passaggio successivo.
Nel diagramma conviene indicare anche le dipendenze esterne, cioè gli elementi che bloccano una fase finché non arriva un’azione da un altro reparto o da un fornitore. È una di quelle cose che sembrano secondarie finché non fermano davvero il progetto.
Tempi, budget e rischio
Per un progetto interno di media complessità, io trovo realistico distinguere almeno tre livelli: tempi stimati, margine di assorbimento e punti di controllo. In pratica, un avvio può richiedere pochi giorni, la pianificazione una o due settimane, mentre l’esecuzione dipende molto dal numero di persone coinvolte e dalla stabilità dei requisiti. Se il progetto tocca più funzioni o dipende da un fornitore esterno, riservo spesso un margine del 10-15% su tempi o budget, perché senza buffer si finisce a gestire emergenze invece che decisioni.
Qui entra in gioco anche la WBS, cioè la scomposizione del lavoro in blocchi gestibili. Serve a stimare meglio, ma soprattutto a evitare che il progetto resti troppo generico per essere controllato. Quando manca questa granularità, il diagramma sembra completo ma non guida davvero le priorità.
Leggi anche: Matrice RACI - Chi fa cosa? Evita il caos nei progetti!
Criteri di uscita
Una fase si chiude quando è chiaro che il risultato è stato ottenuto e verificato. Questi criteri, chiamati anche exit criteria, sono fondamentali per non far scivolare il progetto da una fase all’altra senza controllo. In alcuni contesti si parla di gate di fase, cioè del punto di decisione in cui si conferma il passaggio, si chiede una correzione oppure si ferma tutto.
Atlassian insiste proprio sull’utilità di milestone e criteri di ingresso e uscita per mantenere il progetto leggibile. Ed è una logica che condivido: senza un vero punto di passaggio, il controllo si indebolisce e il team perde riferimento. Una volta chiariti questi elementi, il passo successivo è vedere dove il diagramma si rompe più spesso nella pratica.
Gli errori che fanno perdere il controllo del progetto
Quando uno schema delle fasi non funziona, il problema è quasi sempre prevedibile. Di solito vedo gli stessi errori ripetersi, soprattutto nei progetti aziendali che nascono in fretta o che coinvolgono più stakeholder.
- Si parte senza sponsor, quindi manca qualcuno che prenda decisioni quando emergono conflitti o priorità alternative.
- Si confonde il piano con l’elenco delle attività, e il risultato è un diagramma che descrive il lavoro ma non il controllo.
- Si ignorano i rischi iniziali, così gli imprevisti entrano nel progetto come eccezioni anziché come variabili già considerate.
- Si aggiorna il dettaglio ma non la visione d’insieme, e il team continua a lavorare su una versione ormai superata del progetto.
- Si misura solo il rispetto delle scadenze, senza verificare qualità, adozione o impatto reale.
- Si chiude troppo presto, saltando documentazione, test finali e lezione appresa.
Il difetto più costoso, però, è un altro: trattare il progetto come se fosse immutabile. In azienda non lo è quasi mai. Cambiano priorità, budget, disponibilità delle persone e perfino gli obiettivi iniziali. Per questo un buon schema non deve essere rigido, ma governabile. Ed è proprio qui che un esempio concreto aiuta più di una definizione astratta.
Un esempio utile per HR e digitalizzazione
Immaginiamo un progetto di digitalizzazione dell’onboarding per 250 persone distribuite su tre sedi. Nella fase di avvio definisco il problema: troppe email manuali, documenti dispersi e tempi troppo lunghi per rendere operativo un nuovo assunto. In pianificazione traduco il bisogno in requisiti: firma digitale, checklist documentale, formazione per i manager e un pilota su una sola sede. Durante l’esecuzione preferisco un rilascio graduale, perché nei processi HR il go-live “big bang” è spesso più rischioso di quanto sembri.
Le metriche giuste qui non sono decorative. Io guarderei almeno tre indicatori: tempo medio di completamento dell’onboarding, numero di ticket aperti nelle prime settimane e tasso di adozione da parte dei manager. Se il tempo scende in modo stabile e i ticket diminuiscono dopo il primo mese, il progetto sta creando valore. Se invece il software parte ma il processo resta manuale, la digitalizzazione è solo apparente.
La fase di monitoraggio, in questo caso, non serve solo a controllare il calendario, ma a capire se il nuovo flusso è davvero usato. La chiusura, poi, non coincide con il rilascio tecnico: io considero sempre utile un periodo di stabilizzazione di 2-4 settimane, durante il quale si raccolgono feedback e si correggono i punti deboli. È il modo più semplice per evitare che il progetto “finisca bene” ma venga poi abbandonato nella pratica.
Dopo un esempio come questo, la domanda giusta è: come mantenere lo schema utile anche quando il progetto cambia strada senza trasformarlo in burocrazia?
La versione che tengo viva quando il progetto cambia strada
Una cosa che vedo spesso è questa: lo schema nasce bene, poi viene trattato come un poster e non come uno strumento. Io faccio il contrario. Se il progetto è piccolo, tengo una sola pagina; se coinvolge più funzioni, passo a una versione più strutturata, ma sempre leggibile. L’aggiornamento va fatto con una cadenza regolare, almeno settimanale o a ogni gate di fase, così il diagramma resta allineato alla realtà.
- tenere visibili i responsabili e gli approvatori;
- aggiornare solo le decisioni rilevanti, non ogni micro-attività;
- salvare uno storico dei cambi di scope;
- chiudere con una breve lesson learned, anche quando il progetto è andato bene;
- usare un linguaggio semplice, perché il documento deve essere letto anche da chi non vive il progetto ogni giorno.
Se lo schema rimane semplice da leggere e abbastanza rigoroso da guidare le scelte, diventa davvero utile: non descrive soltanto il progetto, lo aiuta a non deragliare.
