Un progetto non fallisce soltanto perché il piano è debole o perché mancano competenze tecniche. Spesso si blocca quando nessuno ha la piena autorità per decidere, le priorità cambiano senza criterio o i problemi emergono troppo tardi. Questa guida alla governance dei progetti parte da qui: creare un sistema decisionale che renda visibili responsabilità, avanzamento, rischi e impatto sul business.
Per un CEO o un responsabile di funzione, la governance non è un livello burocratico aggiuntivo. È il modo per proteggere investimenti, tempi e persone dall’improvvisazione. Se ben progettata, riduce le riunioni inconcludenti, accelera le scelte critiche e consente di intervenire quando il recupero è ancora possibile.
Che cos’è la governance di progetto
La governance di progetto definisce chi decide, su quali informazioni, con quale frequenza e con quali limiti di delega. Stabilisce il rapporto tra sponsor, direzione, project manager, team operativo e fornitori. Non coincide con il project management: ilproject managerpianifica, coordina e controlla l’esecuzione; la governance assicura che l’esecuzione resti coerente con strategia, priorità e capacità dell’organizzazione.
La distinzione è concreta. Un project manager può segnalare che una nuova richiesta commerciale richiede tre settimane aggiuntive. La governance deve decidere se accettare la modifica, spostare una priorità, aumentare le risorse o mantenere lo scope originale. Senza questo presidio, il progetto assorbe lavoro non pianificato, il budget si deteriora e la data di consegna diventa una previsione poco credibile.
Nelle aziende che gestiscono piùiniziative contemporaneamente, la governance serve anche a scegliere quali progetti meritano attenzione e risorse. Non tutto ciò che è urgente è strategico, e non tutto ciò che è strategico può partire nello stesso trimestre.
Guida alla governance dei progetti: partire dalle decisioni
L’errore più frequente è costruire comitati, report e matrici di responsabilità prima di avere chiarito le decisioni da governare. Il punto di partenza corretto è l’elenco delle scelte che influenzano valore, tempi, costi, rischio e qualità.
Per ciascuna scelta occorre definire il decisore finale, chi prepara l’istruttoria, chi deve essere consultato e chi deve essere informato. Una matrice RACI può essere utile, ma non deve diventare un documento teorico. Deve rispondere a domande operative: chi approva un cambio di budget? Chi può autorizzare una variazione dello scope? Chi sblocca una dipendenza tra funzioni? Entro quanto tempo deve arrivare una risposta?
In pratica, il modello funziona quando ogni decisione critica ha un proprietario nominativo e una soglia chiara. Per esempio, il project manager può approvare micro-variazioni entro un limite concordato, mentre modifiche che impattano margine, data di go-live o requisiti essenziali passano allo sponsor o allo steering committee. Le soglie dipendono dalla dimensione dell’investimento e dal livello di rischio: in un progetto di trasformazione ERP saranno diverse rispetto al lancio di una campagna commerciale.
Lo sponsor non è una figura di facciata
Lo sponsor rappresenta il business case e ha la responsabilità di rimuovere ostacoli che il team non può risolvere autonomamente. Non deve gestire ogni attività, ma deve essere presente nei momenti che contano: approvazione dell’avvio, validazione dei passaggi rilevanti, decisioni su conflitti di priorità e verifica dei benefici ottenuti.
Uno sponsor assente produce un vuoto che viene riempito da negoziazioni informali tra funzioni. Uno sponsor troppo invasivo, al contrario, rallenta il team e svuota il ruolo del project manager. L’equilibrio consiste nel delegare l’operatività e presidiare le decisioni con impatto aziendale.
Disegnare un modello leggero, ma sufficiente
La governance efficace non ha un numero standard di riunioni o report. Un progetto breve, con poche dipendenze e un team già abituato a collaborare, può richiedere un presidio essenziale. Un programma che coinvolge operations, IT, sales, fornitori e più sedi ha bisogno di un sistema più strutturato.
In entrambi i casi, alcuni elementi non sono negoziabili:
- un mandato di progetto con obiettivi misurabili, perimetro, budget, tempi, sponsor e criteri di successo;
- un piano integrato che evidenzi milestone, dipendenze, responsabilità e risorse necessarie;
- un registro aggiornato di rischi, problemi, decisioni e richieste di modifica;
- una cadenza di governance con agenda, partecipanti, materiale pre-letto e decisioni verbalizzate;
- indicatori sintetici che mostrino stato reale, scostamenti e azioni correttive.
La qualità del mandato iniziale merita particolare attenzione. Obiettivi come “migliorare il processo commerciale” o “digitalizzare il servizio clienti” sono direzioni, non criteri di governo. Occorre tradurli in risultati verificabili: riduzione del tempo di preventivazione, aumento del tasso di conversione, diminuzione degli errori di inserimento, miglioramento del livello di servizio. Solo così si può stabilire se il progetto sta generando il valore promesso.
Reportistica: pochi dati, decisioni migliori
Un report di progetto non deve raccontare tutto ciò che il team ha fatto. Deve permettere al decisore di capire rapidamente se il progetto è sotto controllo e cosa serve per mantenerlo tale. Le slide piene di attività svolte possono dare una sensazione di movimento, ma non sostituiscono una lettura onesta degli scostamenti.
Un cruscotto utile riporta avanzamento rispetto alle milestone, stato di budget e impegno residuo, rischi prioritari, dipendenze aperte, decisioni richieste e benefici attesi. Il semaforo verde, giallo o rosso è utile soltanto se accompagnato da una spiegazione precisa e da un’azione. Un giallo senza proprietario, data e piano di recupero è un rosso rimandato.
Anche la frequenza va calibrata. Un progetto in fase di avvio o in prossimità del rilascio può richiedere un monitoraggio settimanale. Durante una fase stabile, una cadenza mensile può essere sufficiente. L’obiettivo non è produrre documenti, ma mantenere alta la capacità di anticipare le deviazioni.
Gestire scope, rischi e dipendenze senza ambiguità
Lo scope creep nasce raramente da una singola richiesta enorme. Più spesso deriva da piccole eccezioni considerate ragionevoli, accettate senza valutare l’effetto cumulativo. Una governance disciplinata richiede che ogni modifica venga descritta, stimata e approvata al livello corretto prima di entrare nel piano.
La stessa logica vale per rischi e dipendenze. Un rischio non è una nota da archiviare: deve avere probabilità, impatto, responsabile e strategia di risposta. Una dipendenza tra funzioni deve indicare cosa serve, da chi, entro quando e quale milestone viene compromessa in caso di ritardo. Quando queste informazioni restano implicite, i problemi arrivano al comitato quando hanno già generato costi e tensioni.
Governance agile: controllo senza microgestione
Agile non significa assenza di governance. Significa spostare il controllo dal rispetto rigido di un piano iniziale alla verifica frequente del valore prodotto, delle priorità e della capacità del team. In contesti di incertezza, pretendere di definire ogni requisito all’inizio può creare un’illusione di controllo più costosa del cambiamento stesso.
La governance agile mantiene fermi obiettivi di business, budget, vincoli e responsabilità, ma rivede periodicamente il backlog e le priorità. Lo steering committee non decide il dettaglio delle user story: verifica che gli incrementi rilasciati producano apprendimento, risultato e ritorno sull’investimento. Il product owner guida le priorità di prodotto, il team decide come realizzare il lavoro, lo sponsor presidia il valore complessivo.
Questo approccio richiede maturità. Se il management usa ogni review per introdurre nuove richieste senza rinunciare a nulla, l’agilità diventa disordine. Se il team evita di rendere trasparenti vincoli e ritardi, la velocità apparente si trasforma in debito operativo.
Misurare i benefici, non solo la consegna
Un progetto consegnato nei tempi può comunque essere un insuccesso se non viene adottato, se non migliora il processo previsto o se i benefici restano sulla carta. La governance deve proseguire oltre il go-live con una verifica sui risultati concordati nel business case.
Conviene nominare un responsabile dei benefici, spesso interno alla funzione che utilizzerà l’output del progetto. Questa persona non sostituisce il project manager: si assicura che formazione, cambiamento organizzativo, nuove procedure e indicatori rendano effettivo il risultato. È il passaggio che separa una consegna tecnica da un miglioramento aziendale.
Una governance ben fatta non rende i progetti più lenti. Elimina attese inutili, conflitti non dichiarati e decisioni prese quando il margine di manovra è già ridotto. Il primo passo pratico è semplice: prendete un progetto in corso, individuate le tre decisioni che oggi restano sospese e assegnate a ciascuna un decisore, una soglia e una scadenza. Da lì, la disciplina diventa un vantaggio competitivo misurabile.