Dalla definizione di progetto consegue quella di project management, o gestione dei progetti, definita come l’applicazione di conoscenze, competenze, strumenti e tecniche per soddisfare i requisiti di progetto. In quanto tale, il project management si riferisce alla conduzione del lavoro di progetto per conseguire i risultati previsti (Nokes & Kelly, 2007).
La definizione merita di essere letta al contrario, perché è lì che sta l’indicazione utile: il criterio non è aver seguito un metodo, è aver soddisfatto i requisiti. Il metodo serve nella misura in cui aiuta; una procedura rispettata su una commessa consegnata in ritardo non è project management riuscito.
Pianificare non è gestire
La confusione più diffusa è fra il piano e la gestione. Il piano è un documento e invecchia dal momento in cui viene approvato. La gestione è ciò che si fa dopo: rilevare lo scostamento fra quanto previsto e quanto sta accadendo, decidere se sia il caso di intervenire e, quando serve, cambiare qualcosa.
È la ragione per cui un Gantt costruito con cura e poi mai aggiornato non è uno strumento di gestione ma un ricordo. Il valore di una pianificazione non sta nella sua precisione iniziale, che è comunque una stima, ma nella frequenza con cui viene confrontata con la realtà del reparto.
I processi che compongono la gestione
Nella pratica corrente la gestione di un progetto si articola su alcuni ambiti che vale la pena tenere distinti, perché in azienda tendono a stare in uffici diversi:
- Ambito — che cosa è compreso nella fornitura e che cosa no. È la voce che, se lasciata vaga, genera la maggior parte delle controversie con il cliente.
- Tempi — la sequenza delle attività, le durate e le dipendenze fra loro.
- Costi — il budget per categoria e il consuntivo che gli si affianca man mano.
- Qualità — i criteri di accettazione, i collaudi, la documentazione da consegnare.
- Risorse — le persone, le competenze, i reparti e i fornitori esterni.
- Rischi — ciò che può andare storto, con quale probabilità e con quale impatto.
- Approvvigionamenti — che cosa si compra, da chi, con quale anticipo.
- Comunicazione e stakeholder — chi deve sapere che cosa, e quando.
Nessuna azienda li presidia tutti allo stesso modo, e non è necessario. Il problema tipico di chi lavora su commessa non è la mancanza di processi, è che i loro dati vivono separati: le ore in un foglio, i costi nel gestionale, il piano su un portatile, i documenti su una cartella di rete. Ogni domanda sensata — a che punto siamo, quanto ci abbiamo rimesso, chi era in ritardo — richiede allora una riconciliazione manuale, e arriva a consuntivo, quando non serve più.
Il caso engineering-to-order
Chi progetta e produce su ordine gestisce progetti anche quando non lo chiama così. Ogni commessa ha un committente, un capitolato, una data e un margine; quello che spesso manca non è la disciplina, è che l’organizzazione resta divisa per reparto — taglio, saldatura, montaggio, collaudo — mentre la commessa attraversa tutti i reparti e non appartiene a nessuno di essi.
Il primo passo concreto è quindi meno sofisticato di quanto la letteratura lasci intendere: dare alla commessa un’identità unica a cui agganciare piano, ore, costi e documenti, così che lo stato di avanzamento sia una lettura e non un’indagine. È il problema da cui parte la nostra pagina Soluzione, che affronta la questione con sei domande concrete invece che con un modello teorico.
Accorgersi prima
Quello che il project management rende possibile è accorgersi prima. Due giorni persi in carpenteria, un componente ordinato in ritardo e un collaudo spostato sono ciascuno recuperabile se visti al momento; sommati e scoperti a fine commessa, sono una consegna mancata. L’incertezza invece resta: un progetto è per definizione un lavoro parzialmente nuovo, e nessun metodo lo rende prevedibile.