Il Project Charter come uscita di un processo fatto per alimentare altri processi
Antonio Giannico
MScEng, Project Manager UNI 11648, PMP®, SMC™ Scrum Master, Accredited Senior Project Management Teacher (ISIPM), ISIPM-Prado® Assessor
Nel precedente articolo abbiamo inquadrato il Project Charter come la magna charta del progetto. Per completare l’argomento non ci resta che guardarlo da una prospettiva un po’ più ampia e sistemica, quella dei processi di project management.
Nel precedente articolo [1] abbiamo inquadrato il Project Charter come la magna charta del progetto, ne abbiamo definito le finalità, abbiamo illustrato alcuni criteri generali per strutturarne i contenuti, abbiamo parlato per sommi capi di strumenti e template per la sua redazione. Per completare l’argomento non ci resta che guardare il tutto e descriverlo in termini di processi (di project management). La visione del progetto in termini di processi infatti, ci aiuta a vedere efficacemente il progetto come qualcosa di dinamico nella sua generalità e nelle sue specificità allo stesso tempo.
Cominciamo con l’osservare che, se vediamo il Project Charter come l’output di un processo, viene naturale chiamare questo processo “Sviluppare il Project Charter”. E’ questo il nome che il PMBOK, cui facciamo prevalentemente riferimento in molti degli articoli della presente serie, dà al processo. Volendone dare una sintetica definizione possiamo pertanto riferirci a quella dello stesso PMBOK:
Def. Sviluppare il Project Charter - Processo che consiste nella redazione di un documento che autorizza formalmente l’esistenza del progetto e attribuisce al Project Manager l’autorità per utilizzare le risorse organizzative per le attività previste dal progetto.
Ricordando che un processo può essere immaginato come una ideale black-box che trasforma ingressi in uscite attraverso l’applicazione agli stessi ingressi di opportune tecniche e strumenti occorre quindi chiedersi:
a) Se il processo suddetto ha come finalità la redazione del Project Charter, che ne è quindi prodotto, output, uscita, quali sono gli elementi input?
b) Quali sono gli strumenti o le tecniche che è possibile adottare per trasformare detti ingressi in Project Charter?
c) Questo processo può essere visto come opportunità per generare altri documenti magari più specifici che siano parte integrante o estensione del Project Charter?
d) Quali sono gli altri processi cui il processo “Sviluppare il Project Charter” è interconnesso attraverso i suoi output, fondamentalmente attraverso il Project Charter?
Proviamo a rispondere a queste semplici domande.
a. INGRESSI
Il Project Charter non può essere creato dal nulla. Anche nel project management possiamo dire che vale la regola secondo cui nulla si crea e nulla si distrugge ma tutto si trasforma. E’ evidente allora che il Project Charter necessiti di documenti a monte che raccordino il progetto con la vision, la mission e gli obiettivi strategici dell’organizzazione. Il PMBOK non a caso identifica una importante parte di questi inputi con il termine “Documenti aziendali” e ne indica due in particolare: Business Case e Piano di Gestione dei Benefici. Si tratta di informazioni strutturate che appartengono ad uno scenario più ampio e che esistono già prima e in parte a prescindere dal progetto. Sono infatti per lo più documenti di più alto livello rispetto al progetto e con cui il progetto dovrà raccordarsi. In particolare, il business case definisce, dal punto di vista dell’organizzazione, alla luce delle necessità e degli obiettivi strategici della stessa, se i risultati attesi dal progetto, alla luce degli oneri che questo comporterà, giustificano o meno l’avvio del progetto stesso e quindi l’investimento. Questo documento non può essere vago, deve avere un fondamento qualitativo e quantitativo. Non a caso contiene l’analisi costi-benefici.
I documenti aziendali che sono a monte del Project Charter non sono documenti di progetto in senso stretto, dal momento che esistono a monte del progetto cioè a prescindere dall’avvio o meno dello stesso. Diversa classificazione merita invece il Project Charter il quale è un documento gestionale di progetto a tutti gli effetti, dal momento che la sua esistenza rappresenta l’avvio stesso del progetto, aspetto questo che lo colloca all’interno del perimetro del progetto.
Tra gli input abbiamo quasi sempre accordi, da intendersi nel senso più generale del termine, ovvero sia essi contratti legalmente vincolanti, che accordi scritti di altra natura o lettere di intenti e persino accordi verbali. Progetti interni all’organizzazione, per esempio, non essendo caratterizzati da un cliente esterno non prevedono un contratto, accordi con un cliente esterno invece devono necessariamente essere formalizzati ad un certo punto con un contratto.
Riflettiamo infine sul fatto che, inevitabilmente i Fattori Ambientali Aziendali e l’Asset dei Processi Organizzativi [2] finiscono per influenzare la stesura e i contenuti del Project Charter, quindi possono essere considerati a tutti gli effetti degli ingressi del processo.
b. STRUMENTI E TECNICHE
E’ nell’esperienza di tutti coloro che operano in ambienti di progetto osservare come, il parere di persone che, a diverso titolo, possono essere considerate esperte su aspetti diversi del progetto che si intende avviare, abbiano un peso generalmente elevato sulle decisioni e quindi su quanto il Project Charter conterrà. Detti pareri devono riguardare in questo caso non fatti generici ma l'individuazione e valutazione oggettiva di dati specifici costituenti gli ingressi del processo prima definito. Per questo motivo il PMBOK inserisce tra gli strumenti per lo sviluppo del Project Charter i pareri di esperti. Il ricorso al parere di esperti, del resto, non deve meravigliare, specie in una fase evolutiva del progetto, quella iniziale, nella quale il progetto stesso è spesso ancora scarsamente definito.
Proprio per questo e a maggior ragione si necessita, in questo frangente, di una efficace raccolta di dati utili a redigere un Project Charter adeguato. Il PMBOK condensa con il termine “raccolta di dati” un insieme di tecniche proprie del processo che si rivelano utili all’avvio del progetto (e non solo). I dati disponibili all’avvio del progetto potrebbero essere infatti solo una parte di quelli effettivamente reperibili e risultare insufficienti. Occorre allora chiederci: in quale altro modo è possibile raccogliere dati utili ancora non disponibili ma probabilmente esistenti e comunque necessari all’avvio del progetto? La risposta che dovrebbe apparire naturale e che in effetti lo stesso PMBOK formalizza è: strutturando sessioni di brainstorming, focus group, vere e proprie interviste a persone e con persone che potenzialmente conoscono o dispongono di informazioni utili che è necessario portare alla luce e far emergere. Spendiamo qualche parola su queste tecniche.
Brainstorming, letteralmente “tempesta di cervelli”. Un facilitatore guida un gruppo di persone, in un tempo relativamente limitato, prima ad esporre le proprie idee in merito ad aspetti o questioni del progetto, quindi ad analizzarle con l’intento di generarne di nuove. E’ molto diverso dall’intervista. Allo stesso tempo è molto di più di una semplice raccolta e somma di opinioni, è altamente dinamico e interattivo in quanto l’idea generata da un partecipante può indurre valutazioni di un altro partecipante e quindi far scaturire nuove idee. Per questo è necessario un adeguato facilitatore e per questo e tipico del team di progetto sebbene possa essere esteso anche ad altri stakeholder, specie in avvio ma non solo.
Focus group. Rimarca maggiormente il fatto che i partecipanti sono individui prequalificati esperti di un determinato aspetto chiamati a confrontarsi per questa loro peculiarità e a focalizzarsi su quell’aspetto, guidati da un moderatore adeguatamente preparato sull’aspetto medesimo. E’ simile ad una intervista guidata ma non è posta a persone singole quanto piuttosto ad un gruppo di persone, è quindi più interattiva ed è più colloquiale rispetto alla classica intervista individuale. Inoltre è più efficiente in termini di tempo rispetto ad n interviste singole.
Interviste. Generalmente sono condotte in maniera individuale, soprattutto se tese a ottenere informazioni riservate che, data questa loro natura, non possono essere fatte emergere in focus group o sessioni di braistroming. Servono ad ottenere informazioni dagli stakeholder più disparati che guidano la definizione o l'identificazione di requisiti (soprattutto quelli non formalizzati, impliciti o nascosti), assunti, vincoli, rischi e a volte degli stessi obiettivi o dell’ambito del progetto.
Ovviamente, non possono non essere strumenti di sviluppo del Project Charter le riunioni, tanto che la stessa ufficializzazione del Project Charter avviene attraverso una specifica riunione, generalmente nota con il nome di kick-off meeeting. Ovviamente, una riunione efficace deve prevedere, una agenda e degli obiettivi, ovvero un ordine del giorno in grado di renderla strutturata, diversamente la riunione perde tipicamente di efficacia.
Ne consegue in maniera naturale che, interviste, riunioni, brainstorming e focus group, data l’interazione tra individui aventi spesso vedute, esperienze, approcci, formazione, cultura e a volte obiettivi diversi in seno al progetto, possano generare conflitti. Di conseguenza, le capacità interpersonali e di gruppo che il facilitatore piuttosto che il moderatore impegnato in queste attività possiedono, possono risultare determinati nel portare a termine l’obiettivo di raccogliere dati corretti, pertinenti ed esaustivi necessari alla redazione del Project Charter.
Per capacità interpersonali e di gruppo intendiamo capacità di gestire conflitti, capacità di facilitazione cioè di favorire la comprensione delle reciproche posizioni, vedute e obiettivi al fine di renderli compatibili se possibile, la capacità di gestire le riunioni attraverso la corretta definizione di un ordine del giorno, il corretto coinvolgimento dei partecipanti, la corretta stesura, condivisione e archiviazione di verbali che cristallizzano le azioni decise. Tutto questo presuppone ascolto attivo ovvero non di parte, non di posizione, ma di attenzione ai messaggi espliciti e impliciti inviati dai partecipanti. L’analisi pronta e oggettiva di questi messaggi deve essere indirizzata ad una altrettanta pronta ed efficace generazione di richieste di chiarimenti o di conferma di corretta comprensione. Tutto ciò serve ad eliminare ostacoli comunicativi, spesso invisibili, che finiscono per generare atteggiamenti di posizioni piuttosto che di focalizzazione sui problemi oggetto di discussione.
Come possiamo vedere, un obiettivo così semplice quale la redazione di un documento apparentemente di base e privo di qualunque appesantimento esecutivo qual è il Project Charter, nasconde ma ha anche il pregio di anticipare spesso e nella sostanza insidie pericolose di cui occorre avere cognizione quanto prima.
c/d. USCITE
Principale output del processo Sviluppare il Project Charter è ovviamente il Project Charter sul cui contenuto non ci dilunghiamo essendo questo già stato argomento del precedente articolo [1].
Aggiungiamo solo una piccola nota: il PMBOK preferisce porre esplicitamente tra gli output un apposito registro detto Registro degli Assunti. Si tratta di un registro spesso trascurato ma di fatto utilissimo che riporta, o meglio traccia nel vero senso del termine, generalmente attraverso un codice identificativo, ciascun assunto di alto livello del progetto, la motivazione fondante dell’assunto medesimo, il grado di approssimazione, la necessità di doverlo sottoporre a ulteriori, successive o periodiche verifiche o di doverlo in qualche modo indurlo e altri attributi o informazioni connesse. Questo perché gli assunti sono spesso tipici dell’avvio di un progetto (e non solo) e possono essere determinanti nelle decisioni che guideranno la pianificazione del progetto ormai prossima a venire. Assunti di dettaglio verranno ovviamente aggiunti nel corso del progetto. In realtà sarebbe buona norma strutturare fin da subito un analogo registro dei rischi e probabilmente dei vincoli. Ovviamente il grado di approfondimento e di strutturazione di questa documentazione va personalizzata in funzione dello specifico progetto e può quindi essere piuttosto snella e schematica o articolata a seconda dei casi.
La mappa del processo e il raccordo con gli altri processi
Analizzata la questione in termini di processo cioè di ingressi, strumenti e uscite del processo, è particolarmente efficace una sintetica rappresentazione grafica del processo stesso che metta in luce questi aspetti e sia in linea con quanto esposto. Detta rappresentazione è riportata in Figura 1 e coincide fondamentalmente con la visione standard del PMBOK.
Figura 1-Ingressi, Strumenti e Tecniche e Uscite del processo “Sviluppare il Project Charter” (PMBOK Sesta Ed.)
Fatto questo, occorre guardare il tutto da una prospettiva più ampia.
I processi di project management come espressi in [3], articolo che si rifà all’approccio standard del PMBOK, costituiscono, nell’insieme, una rete di processi interconnessi e interdipendenti. Il project charter non è quindi un deliverable gestionale fine a se stesso, è piuttosto generato per divenire ingresso di altri processi. Così facendo realizza il raccordo tra il processo Sviluppare il Project Charter e gli altri processi di project management. Dovrebbe venire naturale a questo punto aspettarsi che:
- Il Project Charter sia ingresso privilegiato del processo che porterà a sviluppare il Piano di Project Management (che definirà il “come” sviluppare/eseguire il progetto)
- Che esso sia di ingresso praticamente a tutti i processi di sviluppo dei piani di dettaglio (i singoli piani di gestione rispettivamente di ambito, schedulazione, costi, qualità, risorse, comunicazioni, rischi, approvvigionamenti e stakeholder) dal momento che riassume e condensa una importante parte delle informazioni necessarie a questi processi.
- Che sia di ingresso per il processo di chiusura del progetto (o di una sua fase) dal momento che a giochi chiusi dovremo pur chiederci cosa è stato concluso a fronte degli obiettivi dichiarati in avvio, quali valutazioni iniziali si sono rivelate corrette e quali no per ricavarne importanti informazioni e lezioni per il futuro.
E’ tuttavia anche ovvio, dal momento che il project charter contiene informazioni di alto livello inerenti requisiti e ambito, aspettarsi che esso sia ingresso degli specifici processi finalizzati alla raccolta dei requisiti e alla definizione dell’ambito.
Il gruppo dei processi di avvio prevede inoltre, e non potrebbe essere altrimenti, l’identificazione iniziale degli stakeholder. Dal momento che il project charter contiene dati e riferimenti inerenti i principali stakeholder è logico attendersi che esso debba divenire ingresso del processo che produce il più ampio ed esaustivo registro degli stakeholder e quindi del processo che identifica gli stakeholder.
Lo schema di Figura 2 riassume la visione di processo appena discussa e altro non è che una versione strutturata, in una forma leggermente diversa, del diagramma di flusso riportato a riguardo nel PMBOK (par.4.1, Figura 4.3). Lo scopo di ridisegnarlo in questa forma lievemente rivista è quello di rendere intuitiva, grazie alla disposizione degli elementi e l’impiego opportuno dei colori, la memorizzazione grafica efficace delle interconnessioni e soprattutto di un concetto fondamentale: il project charter è di guida (e non potrebbe essere diversamente) per l’intera pianificazione del progetto, generale e di dettaglio (elementi in colore verde).
Figura 2-Interconnessioni tra il processo “Sviluppare il Project Charter” e i processi di project management a valle
Appare infatti preponderante l’interconnessione in uscita con i processi facenti parte del gruppo dei processi di pianificazione (si riveda anche la Tabella 1 di [3] per una più ampia visione di insieme).
Si ponga attenzione particolare all’orientamento delle interconnessioni, cosa che definisce il flusso interprocesso. Per quanto rappresenti un dettaglio inoltre, non tragga in inganno il fatto che, la freccia verde che interconnette il processo con gli altri processi a valle facenti parte del gruppo dei processi di pianificazione sia disegnata per semplicità come elemento singolo; essa va tuttavia intesa come rappresentazione contratta di 12 diverse specifiche interconnessioni verso altrettanti processi.
Conclusioni
In questo articolo abbiamo visto il Project Charter da una prospettiva non tanto differente quanto complementare a quella più statica proposta nel precedente articolo. In sintesi abbiamo visto il Project Charter come principale risultato di un processo fatto per alimentare altri processi.
Se adesso stabiliamo o immaginiamo gli stessi collegamenti orientati di Figura 2 sovrapposti direttamente sulla tabella strutturata dei processi riportata a suo tempo nell’articolo [3], quest’ultima comincia a mutare trasformandosi in una mappa di più ampio respiro che preconfigura la gestione e l’evoluzione dinamica del progetto come risultato di processi interconnessi. Questo esercizio, che lasciamo al lettore, non ci abbandonerà mai più poiché sarà riproposto in quasi tutti gli articoli che seguiranno e perché costituisce la visione più autentica del progetto che un project manager è portato (o dovrebbe essere portato) a sviluppare in maniera quasi naturale non fosse altro che per motivi di necessità.
Bibliografia
[1]. Articolo n°9: “E’ la Magna Carta del progetto e si chiama Project Charter”
[2]. Articolo n°5: "Comprendere l'ambiente organizzativo per il successo dei progetti - Parte II” ind. Web
[3]. Articolo n°8: “ I processi di Project Management”
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