I 6 strumenti che un Project Manager deve saper usare davvero

Per gestire davvero un progetto bastano sei strumenti, a patto di usarli come risposte a sei domande e non come moduli da compilare.

Chi ha seguito un corso di Project Management conosce decine di tecniche. Poi arriva il primo progetto vero, con una scadenza, un budget e persone che hanno altro da fare, e la domanda diventa:

Da cosa parto lunedì mattina?

La nostra risposta è una cassetta degli attrezzi corta: cinque strumenti, ciascuno legato a una domanda che ogni sponsor prima o poi farà, più una competenza trasversale che serve quando il piano incontra la realtà.

Per restare sul concreto useremo un solo esempio in tutto l’articolo: l’avviamento di una nuova linea di confezionamento in uno stabilimento, da completare in sei mesi senza fermare la produzione esistente.

1. WBS: cosa dobbiamo fare?

La Work Breakdown Structure scompone il progetto in risultati consegnabili, fino a pacchetti di lavoro che una persona può stimare e prendersi in carico.

Tutto ciò che non compare nella WBS non fa parte del progetto: è il primo argine contro le richieste che si aggiungono strada facendo.

Come si costruisce

1. Parti dal risultato finale e chiediti: “cosa deve esistere perché questo sia finito?”
2. Scomponi per deliverable, non per reparti e non per attività. “Layout approvato” è un deliverable, “fare riunioni sul layout” no.
3. Fermati quando il pacchetto è stimabile in ore e costi e ha un solo responsabile. Come ordine di grandezza, tra 8 e 80 ore di lavoro.
4. Verifica la regola del 100%: la somma dei figli copre tutto il padre, niente di più e niente di meno.

Nell’esempio della linea di confezionamento

L’errore tipico è scrivere la WBS da soli in ufficio. Costruita con chi farà il lavoro, in un paio d’ore davanti a una parete di post-it, fa emergere subito le cose dimenticate: nel nostro caso, quasi sempre, la formazione dei manutentori e i ricambi critici.

2. Gantt: quando lo facciamo?

Il Gantt mette i pacchetti della WBS sul calendario e mostra cosa dipende da cosa.

Il suo valore non sono le barre colorate ma il percorso critico: la catena di attività in cui ogni giorno di ritardo sposta la data di fine.

Come si costruisce

1. Prendi i pacchetti di lavoro dalla WBS e fai stimare le durate a chi li eseguirà.
2. Collega le dipendenze reali: cosa non può partire finché un’altra cosa non è finita.
3. Inserisci le milestone, cioè eventi verificabili con un sì o un no: “ordine emesso”, “FAT superato”.
4. Individua il percorso critico e proteggilo: è lì che vanno le risorse migliori e l’attenzione settimanale.
5. Salva una baseline. Senza il piano originale non potrai mai dire di quanto sei in ritardo.

Nell’esempio, il percorso critico passa quasi sempre dalla consegna del fornitore: 14 settimane tra ordine e FAT. La predisposizione dell’area ha invece margine e può slittare di due settimane senza conseguenze.

Saperlo cambia le priorità: una settimana persa nella scelta del fornitore è una settimana persa sull’avviamento, mentre un ritardo sul pavimento no.

L’errore tipico è il Gantt disegnato all’indietro dalla data promessa, con durate compresse fino a farla tornare. È un piano che dice quello che lo sponsor vuole sentire e smette di essere vero alla seconda settimana.

Meglio mostrare subito che la data non regge e discutere cosa togliere dall’ambito o quali risorse aggiungere.

3. RACI: chi lo deve fare?

La matrice RACI assegna a ogni deliverable un ruolo per ciascuna persona coinvolta, così nessuna attività resta “di tutti” e quindi di nessuno.

• R, Responsible: chi esegue il lavoro.
• A, Accountable: chi risponde del risultato e approva. Uno solo per riga.
• C, Consulted: chi va sentito prima di decidere.
• I, Informed: chi va avvisato a cose fatte.

Nell’esempio

Tre controlli da fare sempre

• Ogni riga ha una e una sola A. Due A significano che nessuno decide.
• Ogni riga ha almeno una R, e chi ha la R sa di averla.
• Leggi le colonne: una persona piena di R è un collo di bottiglia, una funzione con sole I forse non serve al tavolo.

L’errore tipico è compilare la matrice e inviarla per email. La RACI funziona quando viene discussa: il momento in cui Produzione e Qualità scoprono di ritenersi entrambe responsabili dei lotti di prova vale da solo la riunione.

Alla matrice RACI abbiamo dedicato un approfondimento completo sul blog di Crossnova.

4. Risk Register: cosa può andare storto?

Il registro dei rischi elenca gli eventi incerti che possono colpire il progetto, li ordina per priorità e assegna a ciascuno una risposta e un proprietario.

Serve a decidere oggi, con calma, quello che altrimenti decideresti in emergenza.

Come si costruisce

1. Identifica i rischi con il team, ripercorrendo la WBS pacchetto per pacchetto.
2. Scrivili in forma causa, evento, effetto. “Il fornitore” non è un rischio, “il fornitore consegna in ritardo perché dipende da un componente a lunga consegna” sì.
3. Valuta probabilità e impatto su una scala da 1 a 5 e moltiplica per ottenere la priorità.
4. Per i rischi più alti scegli una risposta: evitare, ridurre, trasferire o accettare con un piano di riserva.
5. Assegna un proprietario con nome e cognome e definisci il segnale che fa scattare il piano di riserva.

Nell’esempio

L’errore tipico è il registro compilato al kick-off e mai più riaperto. I rischi cambiano: dieci minuti a ogni riunione di avanzamento per rivedere i primi cinque bastano a tenerlo vivo.

5. Dashboard / Status Report: dove siamo rispetto all’obiettivo?

Lo status report è una pagina, sempre uguale, che in due minuti dice allo sponsor se il progetto è in linea e quale decisione gli serve. Se richiede una riunione per essere spiegato, non sta facendo il suo lavoro.

Cosa deve contenere

• Stato generale con un semaforo su tempi, costi, ambito e qualità, basato su soglie concordate prima. Per esempio: giallo oltre il 5% di scostamento, rosso oltre il 10%.
• Avanzamento rispetto alla baseline: milestone previste e raggiunte, giorni di scostamento sul percorso critico.
• Costi: consuntivo e stima a finire rispetto al budget.
• Primi tre rischi e problemi aperti, presi dal registro.
• Decisioni richieste: cosa serve, da chi, entro quando.
• Prossime due settimane: le milestone in arrivo.

Nell’esempio, alla settimana 10 il report potrebbe dire:

L’errore tipico è il progetto “anguria”: verde fuori, rosso dentro. Succede quando il colore lo sceglie il PM a sensazione.

Con soglie numeriche fissate all’inizio il semaforo smette di essere un’opinione, e segnalare un giallo diventa una richiesta di aiuto tempestiva e non un’ammissione di colpa.

6. Problem Solving: cosa facciamo quando qualcosa non va?

I cinque strumenti precedenti dicono che c’è uno scostamento; il problem solving è la competenza che permette di chiuderlo agendo sulla causa e non sul sintomo.

È trasversale perché serve in ogni fase, e distingue il PM che gestisce il progetto da quello che lo rendiconta.

Un metodo in cinque passi

1. Descrivi il problema con i dati: cosa, dove, quando, quanto. “Il FAT è in ritardo di 6 giorni” è un problema, “il fornitore non è affidabile” è un giudizio.
2. Contieni: cosa facciamo subito per limitare il danno mentre cerchiamo la causa.
3. Cerca la causa radice con i 5 Perché o un diagramma di Ishikawa, andando a verificare i fatti dove il problema accade.
4. Scegli la contromisura che agisce sulla causa, con un responsabile e una data.
5. Verifica e standardizza: controlla che abbia funzionato e porta la lezione nel registro dei rischi e nei progetti successivi.

Nell’esempio, i 5 Perché sul ritardo del FAT

La contromisura non è sollecitare il fornitore. È aggiungere alla WBS il deliverable “dati tecnici consegnati al fornitore”, assegnargli una A e controllare se esistono altri pacchetti nella stessa situazione.

L’errore tipico è fermarsi al primo perché e alla prima persona. Una causa del tipo “errore umano” quasi sempre nasconde un processo che ha permesso l’errore. Ne parliamo più a fondo nell’articolo sull’analisi della causa radice, sul nostro blog.

Sei strumenti, un solo sistema

Presi da soli sono moduli. Collegati, formano un sistema in cui ognuno alimenta il successivo:

• la WBS fornisce le righe al Gantt, alla RACI e al Risk Register;
• il Gantt con la sua baseline fornisce i numeri allo Status Report;
• lo Status Report fa emergere gli scostamenti che attivano il Problem Solving;
• il Problem Solving riporta le correzioni in WBS, RACI e rischi.

Se lunedì parte un progetto nuovo, la sequenza pratica è questa:

Non serve un software dedicato: un foglio di calcolo ben tenuto vale più di una piattaforma che nessuno aggiorna.

La differenza tra conoscere questi strumenti e saperli usare si costruisce applicandoli a un caso reale. È il modo in cui lavoriamo nei percorsi di Project Management di Crossnova Academy: ogni strumento viene provato su un progetto del partecipante, non su un esercizio da manuale.