E’ la Magna Carta del progetto e si chiama Project Charter

L’avvio di un progetto è tipicamente sancito dalla stesura di un Project Charter. Generalmente, dopo una naturale fase di incubazione, spesso non formalizzata ufficialmente, si matura la necessità o l’opportunità di avviare il progetto. Il project charter ufficializza il progetto e ha natura, come vedremo, sia formale che sostanziale

Il Project Charter è un documento di progetto che sintetizza, a chiusura della fase di avvio, valutazioni di fattibilità e delinea e preconfigura il perimetro del progetto, gli obiettivi, il modo in cui realizzarli, i benefici attesi, i tempi previsti, i costi, la qualità e altro ancora.

Ciò non toglie che lo studio di fattibilità o di business, specie se particolarmente articolati e complessi, possano essere visti come una fase specifica del progetto con un proprio project charter. Stessa cosa, per lo stesso motivo, potrebbe (o dovrebbe) anzi accadere, in situazioni complesse, per specifiche fasi di progetto.

Opportunità è obiettivi (e quindi benefici attesi) restano in ogni caso all’origine del progetto e ne guidano pertanto la vision attraverso la stesura del project charter.

Nella fase di avvio del progetto deve chiaramente manifestarsi la volontà e l’impegno dello Sponsor a promuove il progetto e sostenerlo finanziariamente. Il project charter, essendo sottoscritto dallo sponsor, è evidenza documentata e ufficiale di questo impegno. Non solo, con il project charter lo sponsor nomina ufficialmente un Project Manager che, investito dell’autorità di utilizzare le risorse del progetto, può decidere di assumere la responsabilità di gestirlo e guidarlo verso gli obiettivi. Quanto ampia è questa autorità può variare da caso a caso ed è qualcosa che dovrebbe essere tracciato nello stesso project charter.

Non di rado, per la verità, il project charter (qualora esista! :-( ) viene limitatamente, e direi erroneamente, scambiato con una mera anagrafica del progetto quando invece dovrebbe essere un documento strutturato ben più sostanziale.

Esso dovrebbe infatti mettere non solo lo sponsor e il PM ma anche gli altri stakeholder chiave nelle condizioni di comprendere, in maniera univoca e sinergica, motivazioni e opportunità all’origine del progetto da un lato e obiettivi e benefici attesi dall’altro, creando il giusto allineamento e riducendo quella sensazione di vaghezza che tanto spesso nasconde pericoli ben più profondi. 

Un project charter correttamente strutturato non formalizza semplicemente l’avvio del progetto, ne fissa le radici, ne delinea il contorno, ne orienta la pianificazione. A tale scopo poggia su evidenze, informazioni e dati di fatto condensati in documenti strutturati che ne sono a monte, primo tra tutti il business case.

Ciò non toglie che progetti standardizzati, di limitate dimensioni, altamente prevedibili, basati su risorse e know-how consolidati non necessitando di analisi particolarmente complesse, possano essere avviati con project charter molto schematici e puramente anagrafici.

Strutturare e redigere il project charter

Il project charter, come qualunque documento è tanto più efficace quanto più è chiaro, definito, sintetico, ben strutturato, esente da ambiguità di interpretazione, basato su dati di fatto verificati e previsioni realistiche.

Esso può essere strutturato in diversi modi. Le informazioni che ne fanno parte non devono necessariamente essere riportate per esteso, molte possono essere integrate attraverso rimandi ad altri documenti adeguatamente identificati. Ciò porta a redigere project charter snelli, scalabili, esaustivi e al tempo stesso non ridondanti.

Un’organizzazione che opera per progetti è normalmente dotata di un sistema documentale che integra template specifici di project charter e di altri documenti di progetto che, utilizzati in maniera sistematica, aiutano a creare cultura e uniformità gestionale e documentale dei progetti all’interno dell’organizzazione.

Se immaginiamo il project charter strutturato, come normalmente accade, in campi o paragrafi, al suo interno dovremmo trovare:

·       informazioni anagrafiche

-       Titolo. E’ mai possibile che un progetto possa non avere un titolo identificativo univoco? Sembra un paradosso eppure talvolta accade che gruppi di lavoro differenti nell’ambito dello stesso progetto si riferiscano ad esso con titoli differenti. Questo genera il giustificato sospetto che forse non abbiano mai preso realmente visione del project charter,… o forse che nessuno lo abbia mai redatto sebbene il progetto sia in pieno svolgimento!

-       Codice identificativo. All’interno di una organizzazione che opera per progetti, i progetti dovrebbero beneficiare di un adeguato sistema di codifica dei medesimi, della documentazione relativa e di un adeguato sistema di archiviazione e repository. Il codice identificativo del progetto diventa radice di tutti i documenti associati. In conclusione, se esiste un sistema di codifica dei progetti il progetto sarà identificato non solo da un titolo ma anche da un codice univoco. A lungo andare ciò rende strutturato e scalabile lo stesso know-how storico di progetto documentato dell’organizzazione. Esso entra cioè a far parte in maniera corretta, cioè efficace ed efficiente, dell'asset stesso dell'organizzazione.

-       Descrizione. Breve descrizione del progetto.

-       Informazioni sul cliente (interno o esterno) e/o relativi referenti.

-       Informazioni sullo sponsor e relativi referenti o rappresentanti.

-       Project Manager: nominativo, responsabilità e livello di autorità.

·     Giustificazione/Opportunità/Obiettivi e benefici attesi generalmente in termini di business ma non necessariamente (si pensi a progetti che hanno obiettivi sociali, culturali o di tipo comunque non commerciale). Occorre, in particolare, verificare che gli obiettivi siano SMART (Specific, Measurable, Achievable, Realistic and Time-bound). Se così non fosse dovremmo avere il ragionevole sospetto che il progetto non sia sufficientemente definito.

-       Motivazioni e opportunità che giustificano il progetto agli occhi degli stakeholder chiave, alla luce dei benefici attesi. I progetti possono nascere da opportunità di mercato, da obiettivi strategici, da richieste o esigenze di clienti, da cambiamenti tecnologici, da nuovi requisiti normativi e/o legali. A ciò deve tuttavia aggiungersi una giustificazione documentata, generalmente un business case.

·     Requisiti generali e ambito. Gli obiettivi sono più comprensibili se si definisce, inizialmente almeno ad alto livello, l’ambito del progetto cioè cosa si dovrà realizzare e i relativi requisiti e cosà non si dovrà realizzare, precisazione quest’ultima assolutamente necessaria qualora vi sia il rischio di possibili fraintendimenti.

·     Vincoli. Quasi sempre, già all’avvio del progetto è possibile definire i principali vincoli cioè aspetti su cui si ha poca o nessuna libertà d’azione e come tali limitanti perchè suscettibili di condizionare piani e sviluppo del progetto.

·     Assunti. Stessa cosa vale per gli assunti ovvero presupposti e ipotesi che occorre spesso formulare per evitare lo stallo del progetto. Sapere quanto realistici sono gli assunti formulati e quanto è possibile indurli in modo da trasformarli in fatti accertati è spesso determinante. Fare assunzioni sbagliate o poco realistiche può attivare minacce e avere effetti deleteri a volte irreversibili sul progetto. La comune condivisione tra i giusti stakeholder e la verifica degli assunti in fase di avvio è quindi strategica.

·     Elenco e analisi preliminare dei rischi. Essi dovrebbero trovare spazio in una sezione specifica del project charter distinti in minacce e opportunità, sebbene di alto livello. La loro prematura identificazione consente di prevenire più efficacemente, fin dall’avvio del progetto, le minacce e sfruttare adeguatamente le opportunità con impatti positivi su tutte le altre aree di gestione del progetto.

·     Stakeholder chiave interni ed esterni. Gli stakeholder chiave sono quelli che hanno elevata influenza e/o potere sul progetto e sono quasi sempre identificabili fin dall’avvio. E’ importante che il project manager, che spesso finisce indirettamente per avere un ruolo nella redazione del project charter, ponga da subito particolare attenzione agli stakeholder chiave. Non a caso, l’identificazione degli stakehiolder è l’unico processo che insieme allo sviluppo del project charter è esplicitamente collocato nel gruppo dei processi si avvio dal PMBOK.

·     Ciclo di vita e milestone. Significa definire già in avvio, a grandi linee, le fasi di progetto e le cosiddette milestone cioè eventi che scandiscono momenti particolarmente significativi di avanzamento del progetto. Esse costituiranno un forte punto di raccordo in corso d’opera tra project manager, sponsor e cliente o committente e consentiranno congiuntamente e in modo efficace, a tutte le parti interessate, di accorgersi per tempo di eventuali deviazioni rispetto alle baseline che saranno fissate concordemente in pianificazione.

·     Budget. Possiamo avere un budget stimato richiesto ed un budget di massima assegnato al progetto, comprensivo o meno delle eventuali riserve. E’ sottinteso una distribuzione temporale del medesimo.

·     Core team. Si tratta di persone che lavorano, generalmente a stretto contatto, con il project manager come componenti del team di project management o del team di progetto. Se il progetto si svolge all’interno dell’organizzazione è probabile che anche il core team sia interno. Componenti del team provenienti da specifiche unità funzionali o divisioni sono una situazione abbastanza ricorrente. Al contrario, se il progetto investe consorzi di organizzazioni o trattasi di progetti che necessitano di know-how esterno, i componenti del team potrebbero essere in parte provenienti dall’esterno, assegnati dallo sponsor al PM su sua richiesta o reclutati dallo stesso PM qualora glie ne sia concessa l'autorità.

·     Elenco dei documenti di riferimento (business case, progetti pregressi, specifiche, tecniche, bandi di gara, normative, contratti, accordi, ecc..) identificati in maniera univoca attraverso relativi codici, titoli, numeri e date di revisione.

Non andrebbe trascurata o omessa in fase di avvio una corretta e oggettiva valutazione sul grado di maturità dell’organizzazione e del team, vale a dire sul know-how e sulle competenze tecniche necessarie a sviluppare il progetto (e perché no, sulla capacità di gestire i progetti!).

Analoga valutazione andrebbe sviluppata sul più generale ambiente di progetto, essendo i progetti quasi sempre tra loro concorrenti, per non dire interferenti a livello di programma e/o di portfolio. Spesso i progetti vengono in prima battuta visti come a risorse infinite al fine di concluderne, rapidamente e per sommi capi, benefici attesi e fattibilità tecnica. Prima di renderne ufficiale l’avvio occorre tuttavia cambiare prospettiva e ragionare in termini di risorse limitate e condivise guardando all’interno dell’organizzazione, oltre il progetto stesso. Il project charter diviene così punto di raccordo del progetto con il più generale programma e/o portfolio, con l’organizzazione più in generale e non solo. Questo è uno dei tanti legami o interferenze che il progetto si porterà dietro lungo il suo intero ciclo di vita, fino alla sua conclusione (o chiusura anticipata!).

Il project charter dovrebbe in fine essere sempre sottoscritto, cioè firmato, da sponsor e project manager, e ad essere rigorosi, per accettazione dal cliente o committente del progetto, prodotto o servizio che scaturirà dal progetto.

E’ inoltre interessante osservare che, il Project Charter tocca in pratica e in maniera generale molte o tutte le aree i conoscenza di project management. Solo con il successivo piano di progetto e i relativi piani di dettaglio, che verranno elaborati dinamicamente nel corso del progetto tuttavia, si raggiungerà il vero grado di approfondimento che una pianificazione esaustiva ed efficace richiede.

Linee guida ulteriori

Tabelle strutturate, punti elenco e rimandi ad altri documenti, sono tipici di un project charter come di molti documenti gestionali di progetto.

In genere, il project charter è ufficializzato con il cosiddetto kick-off meeting, il “colpo di pistola che da fuoco alle polveri”, il “via alla gara”, quando i principali attori sono ormai allineati ai nastri di partenza.

Dal punto di vista del project manager rappresenta incarico ufficiale ricevuto dallo sponsor a gestire e guidare il progetto verso i suoi obiettivi e quindi autorizzazione a “consumare” le risorse del progetto, dal punto di vista dello sponsor costituisce invece impegno a sostenere il progetto e il project manager.

In teoria, il project charter dovrebbe essere redatto dallo sponsor, tuttavia nella pratica comune accade spesso che esso venga redatto a quattro mani da sponsor e project manager designato oppure dal solo project manager che lo sottoporrà all’approvazione dello sponsor e insieme a questo ultimo a quella del cliente. Questa ultima approvazione consente di avere confidenza che il progetto come è pensato potrà rispecchiare i requisiti del cliente e soddisfarne quindi le esigenze.

Progetti di dimensioni ridotte e relativamente standardizzati presentano project charter più snelli, strutturati in poche sezioni, tanto da apparire più simili ad una anagrafica o scheda di progetto. Progetti più complessi presentano invece molte sezioni, riportano informazioni più ampie e dettagliate, maggiori rimandi ad altri documenti.

Il project charter oltre a sancire ufficialmente l’esistenza del progetto ne definisce, in ogni caso, concretamente una visione condivisa e ne preconfigura la pianificazione.

A chi pensa quindi che si tratti di un esercizio formale interno all’organizzazione occorre osservare che trattasi in realtà di un documento che “vende”, nel vero senso del termine, il progetto agli stakeholder e lo lega contestualmente al suo presumibile ritorno sull’investimento.

Il project charter identifica cliente e/o utente finale (che potrebbero anche non essere lo stesso soggetto!), chi è responsabile del progetto per la performing organization e chi essendolo lato cliente ha potere di accettazione dei risultati.

I ruoli chiave tracciati all’interno del documento preconfigurano e concorreranno inoltre a delineare l’organigramma di progetto e i canali di comunicazione all’interno e verso l’esterno del progetto.

Strumenti e template per la redazione del Project Charter

In grandi organizzazioni è frequente avere un sistema gestionale che consente la gestione integrata, condivisa e real-time, anche da remoto, dei progetti. Si tratta di veri e propri sistemi informativi noti con il nome di Management Information System o ERP-Enterprise Resource Planning.

Resta il fatto che, anche con strumenti relativamente semplici è possibile strutturare efficacemente un project charter e altri documenti gestionali per la maggior parte dei progetti. Semplici fogli excel o word e tabelle opportunamente strutturate e codificate possono, come al solito, essere di grande aiuto nella stesura di questo tipo di documenti. Non è inoltre difficile trovare in rete template di project charter modificabili e adattabili alle esigenze più disparate. In Figura 1 si riporta un template di project charter appositamente strutturato per questo articolo allo scopo di riassumere in maniera sufficientemente esaustiva quanto fin qui esposto. Particolarmente utile può risultare allo scopo una sua attenta e critica analisi.

Figura 1-Esempio di strutturazione di un project charter

Come si può osservare, il documento non proietta semplicemente la visione del progetto verso la successiva pianificazione, collega piuttosto e prima, il progetto medesimo agli obiettivi strategici dell’organizzazione. Esso appare inoltre come lo specchio di una vera e propria partnership, non solo tra sponsor e project manager ma in senso più ampio tra performing organization e organizzazione richiedente pur non rappresentando un documento legale o contrattuale.

La struttura tabellata è asciutta dell’esempio di Figura 1 è resa possibile dall’inserimento di richiami ad altri documenti che ne diventano così parte integrante e sostanziale. Ciò non esclude la possibilità di optare per modelli di Project Charter maggiormente testuali, organizzati in paragrafi e sottoparagrafi, contenenti a loro volta tabelle strutturate. In generale, non vi è una regola assoluta che porti a preferire una soluzione piuttosto che l’altra. La coerenza e l’integrazione di contenuti esaustivi e basati su dati di fatto è ciò che fa la differenza.

Prima di chiudere il paragrafo, riportiamo una semplice ma importante osservazione. Il project charter è un documento prevalentemente statico nel senso che, contenendo la vision del progetto, difficilmente viene a (o dovrebbe) subire delle modifiche significative successivamente alla sua redazione e qualora modifiche dovessero intervenire esse si riflettono piuttosto e direttamente nel piano di progetto e nei piani di dettaglio che riguardano il gruppo dei processi di pianificazione che per loro natura sono invece dinamici. Ciò nonostante, può accadere che il documento venga, dopo una prima emissione, riemesso a nuova revisione per renderlo più completo ed esaustivo o anche per il fatto che nuovi responsabili sono intervenuti in sostituzione di quelli originari. Per questo motivo è necessario tracciare adeguatamente revisioni e date di revisione (vedi Figura 1).

Riportiamo in fine una interessante nota tratta dal testo “Il Project Management secondo la Norma UNI ISO21500”, di P.L. Guida, Ed. Franco Angeli, che per la verità ha ispirato il titolo di questo articolo.

“Al posto del termine Project Charter è perfettamente accettabile il termine Charter di progetto. Charter deriva dal latino Charta ovvero documento. Di origine medievale, charter era il documento che decretava autorità e diritto di istituire colonie, città, organizzazioni a statuto speciale. Deriva dalla Magna Charta Libertatum scritta in latino nel 1215, attraverso cui il re Giovanni Senzaterre d’Inghilterra concesse ai propri baroni speciali garanzie e poteri in cambio della loro fedeltà. Come la Magna Charta fu sottoscritta dal re, quella di progetto, il project charter appunto, viene firmata dallo sponsor.”

Altri termini più o meno equivalenti a project charter esistono: uno molto diffuso che occorre conoscere, perché derivante dal metodo Prince2, è Project Brief.

Conclusioni

I documenti gestionali del progetto (e il project charter è uno di questi!) servono anche, e forse soprattutto, a rendere evidente e comprendere in modo strutturato e per tempo ciò che mancando al progetto rischia di minarne le fondamenta già in avvio.

Compreso cosa sia un project charter e perché è così importante per avviare e orientare correttamente un progetto, concludiamo ponendoci alcune semplici domande.

-       L’avvio dei nostri progetti si conclude sempre con la redazione di un adeguato project charter?

-       Se no, siamo consapevoli del perché e consci delle conseguenze?

-       Se si, la sua redazione si riduce ad un esercizio formale che attesta l’esistenza del progetto o è qualcosa di più? Cosa ci dice che è adeguato allo scopo?

Porsi queste poche ma semplici domande è quantomai opportuno. Al di là dello specifico argomento cui è dedicato l’articolo, riuscire ad operare nel modo corretto, fin dall’avvio del progetto, anche nella redazione di semplici documenti quale è il project charter, specie in ambienti non del tutto maturi e poco abituati a strutturare i progetti attraverso i necessari processi, presuppone un atteggiamento distaccato e indipendente spesso difficile da conquistare, oltre che oggettivo, critico e costruttivo, sul proprio modo di lavorare e su quello di chi ci circonda.

Ricondividi l’articolo, lascia un commento o delle osservazioni. Grazie!

Articoli della collana

INDICE

ACCESSO:

SE LA TUA APP MOBILE NON RISPONDE AL LINK ACCEDI DA BROWSER MOBILE

Articolo n°1: Il Project Management è sempre esistito

Articolo n°2: Chi ha ucciso il Project Management

Articolo n°3: Project Management: il progetto prima di tutto!

Articolo n°4: Comprendere organizzativo per il successo dei progetti – Parte I

Articolo n°5: Comprendere l’ambiente organizzativo per il successo dei progetti - Parte II

Articolo n°6: Il ruolo del Project Manager nell’ambiente di progetto

Articolo n°7: La gestione strutturata dei progetti: fasi, ciclo di vita del progetto e processi di Project Management

Articolo n°8: I processi di Project Management

Articolo n°9: E’ la Magna Carta del progetto e si chiama Project Charter

Articolo n°10: Il Project Charter come uscita di un processo fatto per alimentare altri processi

Articolo n°11: Dal Project Charter (ma non solo) all’identificazione degli stakeholder

Articolo n°12: Il Piano di Project Management. Una risposta strutturata a una domanda dovuta: "Come ... ?"

Articolo n°13: Un piano di gestione specifico per l'ambito, la sostanza intorno a cui tutto ruota

... gli articoli che seguono non sono accessibili …