Marco Merlino parla di
Prima che un progetto prenda forma nei piani, nei backlog o nei diagrammi, esiste un momento decisivo che spesso passa inosservato. È il momento in cui l’organizzazione sceglie di chiarire, o di evitare, le domande più scomode: perché stiamo facendo questo progetto, chi ne è davvero responsabile e quale valore deve produrre. In questa fase iniziale si concentrano molte delle cause dei fallimenti successivi, ma anche le condizioni dei successi più solidi. Il Project Charter nasce proprio per dare forma a questo spazio decisionale, trasformando intenzioni implicite in scelte esplicite. Non è un documento operativo, né una sintesi del piano di lavoro, ma un atto di allineamento e di governo. Quando viene trattato come una formalità, il progetto parte fragile. Quando viene costruito con consapevolezza, diventa una bussola che orienta decisioni, priorità e responsabilità lungo tutto il ciclo di vita del progetto.
Il progetto nasce prima del piano
Molti progetti falliscono molto prima di entrare in esecuzione. Non falliscono perché mancano strumenti, né perché il team non sia competente, ma perché non esiste un accordo chiaro su che cosa il progetto sia davvero, chi lo governi e quale valore debba produrre. In questo spazio, spesso invisibile e sottovalutato, si colloca il Project Charter. Troppo spesso trattato come un documento formale da “mettere a posto” per avviare i lavori, il Charter è in realtà un atto di governo: definisce la legittimità del progetto, ne stabilisce i confini, assegna responsabilità e rende esplicita la logica decisionale. Il Project Charter non descrive il progetto, lo rende possibile. Ed è per questo che, in modo silenzioso, ne decide il destino prima che inizi.
Il Project Charter non è burocrazia: è un patto organizzativo
La prima incomprensione sul Project Charter riguarda la sua natura. Se viene visto come una formalità amministrativa, viene scritto in modo generico, riempito di frasi standard e archiviato. Se invece viene inteso come un patto, cambia tutto. Il Charter è un accordo tra sponsor, management, project manager e stakeholder principali sul significato del progetto: perché esiste, quale problema risolve, quali risultati devono essere considerati un successo, quali vincoli sono non negoziabili.
In assenza di questo patto, il progetto è esposto a una deriva tipica: ognuno interpreta obiettivi e priorità in modo diverso, i conflitti vengono rimandati e riemergono quando costano di più, le decisioni diventano lente perché non esiste una base comune. Un Project Charter debole non genera solo confusione, genera conflitto differito, e il conflitto differito è uno dei costi più alti nei progetti complessi.
Perché il Project Charter “decide il destino”
Il Project Charter decide il destino del progetto perché risponde, in modo esplicito, a quattro domande che altrimenti restano implicite e quindi ingestibili. La prima è la domanda sul valore: quale beneficio reale deve produrre il progetto e per chi. La seconda riguarda il perimetro: cosa è incluso e cosa è escluso, cioè dove finisce la responsabilità del progetto. La terza domanda riguarda la governance: chi decide, come decide, e con quali criteri. La quarta riguarda le condizioni: vincoli, rischi, assunzioni, dipendenze, limiti di budget e di tempo.
Quando queste domande restano senza risposta formale, il progetto parte comunque, ma parte “vuoto”. Il vuoto viene riempito dall’emergenza, dalla politica, dall’interpretazione soggettiva e dalla pressione del momento. Il Project Charter non elimina l’incertezza, ma rende governabile la complessità.
Contenuti essenziali: cosa deve contenere un Charter che funziona
Un Project Charter efficace non è necessariamente lungo, ma è denso di decisioni. La parte più importante è una definizione chiara del purpose, cioè del “perché” del progetto, formulata in modo che sia riconoscibile e verificabile. Questa sezione non può essere composta da slogan; deve esplicitare la logica di valore e la motivazione organizzativa. In un’organizzazione matura, questa parte contiene anche ciò che spesso viene evitato: il costo del non fare, ovvero cosa accade se il progetto non viene realizzato.
Il Charter deve poi includere gli obiettivi, distinguendo tra output e outcome. Gli output sono i deliverable prodotti, gli outcome sono i risultati ottenuti. Confondere output e outcome è una delle principali cause di progetti “completati” ma inutili. Un Charter forte esplicita anche criteri di successo, misure e soglie di accettazione, evitando formulazioni ambigue che rendono impossibile valutare se il progetto abbia davvero funzionato.
Un’altra sezione fondamentale riguarda lo scope, che deve essere presentato non come una lista esaustiva di attività, ma come una definizione di confine. Uno scope chiaro include esplicitamente ciò che è fuori. Questa scelta è scomoda, perché costringe a dire dei no prima che le richieste arrivino. Ma è proprio questa scomodità che rende il Charter un documento potente.
Governance e responsabilità: la parte che tutti evitano
La sezione più delicata e spesso più trascurata del Project Charter è quella della governance. Qui non basta elencare ruoli. Occorre stabilire la struttura decisionale: quali decisioni sono in capo allo sponsor, quali al project manager, quali richiedono un comitato, quali possono essere prese dal team. Serve chiarezza sui meccanismi di escalation, sui tempi di risposta e sui criteri di prioritizzazione in caso di conflitto tra vincoli.
Quando questa parte manca, il project manager si trova a governare senza autorità. Lo sponsor diventa una firma, non una guida. Gli stakeholder assumono un potere informale e intermittente, comparendo solo quando qualcosa non piace. Un Project Charter che non chiarisce chi decide produce un progetto che decide per inerzia, e l’inerzia è una pessima forma di governance.
In questa sezione è utile rendere espliciti anche i ruoli in chiave di responsabilità, per esempio attraverso un riferimento coerente a logiche RACI o equivalenti, senza trasformare il Charter in un documento eccessivamente tecnico. L’obiettivo non è formalizzare tutto, ma rendere non ambigua la catena decisionale.
Assunzioni, vincoli e rischi: l’onestà che protegge il progetto
Un Project Charter efficace include assunzioni e vincoli. Questa parte è spesso vista come un dettaglio, ma in realtà è un meccanismo di protezione. Le assunzioni sono ipotesi su cui il progetto si basa. Se non vengono dichiarate, diventano “verità invisibili” e quando si rivelano false generano shock organizzativi. I vincoli definiscono ciò che non può essere violato: budget massimo, data non negoziabile, requisiti normativi, capacità produttiva, dipendenze critiche. Il Charter deve anche esplicitare i principali rischi, non in forma di registro dettagliato, ma come consapevolezza iniziale degli elementi di fragilità.
Questa sezione è un esercizio di maturità: significa accettare che il progetto non è una promessa, ma una scommessa governata. Dichiarare vincoli e rischi non indebolisce il progetto, lo rende credibile.
La relazione tra Charter e pianificazione: ordine corretto delle cose
Uno dei fraintendimenti più dannosi è trattare il Charter come una sintesi del piano. In realtà, il Charter precede il piano. Prima si definiscono valore, confini e governance, poi si costruisce la pianificazione. Quando si fa il contrario, il piano diventa una costruzione tecnica su fondamenta instabili. Il risultato è un project plan dettagliato che viene riscritto continuamente perché il progetto non è mai stato chiarito davvero.
Il Charter non sostituisce WBS, Gantt, schedule o backlog, ma li rende coerenti. Stabilisce la direzione entro cui questi strumenti possono operare. Un piano può essere corretto eppure inutile se il Charter è debole, perché la correttezza tecnica non compensa l’ambiguità strategica.
Un caso concreto: la piattaforma di ticketing che “non doveva cambiare nulla”
Un’azienda di servizi decide di introdurre una nuova piattaforma di ticketing per migliorare la gestione delle richieste interne. Il progetto viene approvato rapidamente perché “è solo un cambio di strumento”. Il Charter, redatto in fretta, descrive genericamente l’obiettivo: sostituire la piattaforma attuale e migliorare la tracciabilità. Nessuna definizione di outcome, nessun chiarimento sul perimetro, governance vaga. Lo sponsor firma, ma non partecipa.
Il progetto parte e, dopo poche settimane, emergono richieste non previste: integrazioni con sistemi HR, gestione di workflow complessi, nuove categorizzazioni, reportistica per il management. Ogni funzione chiede qualcosa e ritiene che sia “ovvio”. Il project manager non ha leve per dire no, perché lo scope non è mai stato definito come confine. Lo sponsor non interviene, perché non è stato definito un meccanismo decisionale. Il team implementa, ma senza una direzione, e la piattaforma cresce in modo disorganico.
Dopo mesi, la piattaforma viene rilasciata, ma gli utenti la percepiscono come peggiore: più complessa, più lenta, più burocratica. Il progetto è formalmente completato, ma fallisce sul valore. L’analisi retrospettiva è chiara: non è mancata la competenza tecnica, è mancato il Charter. Il progetto non è fallito in esecuzione, è fallito in definizione.
Come si scrive un Project Charter “utile” e non solo “corretto”
Scrivere un Charter utile significa assumere che il documento deve essere letto e usato, non archiviato. Deve essere scritto in modo comprensibile, senza gergo eccessivo, e deve essere discusso. Un Charter non discusso è un documento che non esiste. La sua forza non sta nel testo, ma nell’allineamento che produce. In questo senso, il processo di costruzione del Charter è già change management: costringe le parti a chiarire aspettative, vincoli e responsabilità.
Un Charter utile contiene anche un elemento spesso assente: la logica di trade-off. Se tempo, costo e scope entrano in conflitto, quale variabile si protegge per prima? Qual è la priorità reale? Un progetto senza logica di trade-off è un progetto destinato a conflitti continui, perché ogni stakeholder tenderà a proteggere ciò che gli interessa senza un criterio condiviso.
Il Charter come atto di leadership
Il Project Charter non è un documento tecnico, è un atto di leadership. È il momento in cui l’organizzazione dichiara cosa vuole ottenere, a quali condizioni e con quale responsabilità. È un patto che stabilisce la direzione prima che la complessità operativa inizi a distorcere tutto.
Quando viene trattato come burocrazia, il progetto parte senza fondamenta. Quando viene trattato come governance, il progetto parte con un orientamento chiaro e una struttura decisionale credibile. In definitiva, il Project Charter decide il destino del progetto perché decide la qualità del suo inizio. E nei progetti, spesso, l’inizio è già metà del risultato.
L’articolo Project Charter: il documento che decide il destino del progetto prima che inizi proviene da Management Expert.
