Processo di definizione

Aspetti generali

Questo processo gestisce la fase di definizione del ciclo di vita di un progetto o programma. I suoi obiettivi sono:

  • sviluppare un quadro dettagliato del progetto o programma;
  • stabilire se il lavoro sia giustificato;
  • delineare le politiche di governance che descrivono come verrà gestito il lavoro;
  • ottenere l’autorizzazione dallo sponsor per la fase di consegna.

Il processo sarà innescato da un brief e da un piano di definizione autorizzati ed è fondamentalmente lo stesso indipendentemente dal fatto che sia stato deciso di gestire il lavoro come un progetto o come un programma.  Il prodotto di questo processo sarà un insieme di documenti che descrivono tutti gli aspetti del lavoro, con un contenuto e un livello di dettaglio diversi in base al contesto.

 

 

Il processo di definizione pianificherà la gestione e la consegna del lavoro. Una sintesi dei piani viene poi presentata allo sponsor per ottenere l’autorizzazione della fase di consegna. Anche se la richiesta formale di autorizzazione viene mostrata nella figura alla fine del processo, il manager e lo sponsor devono essere in costante comunicazione durante tutto il processo.

Quando in conclusione viene presentata la formale richiesta di autorizzazione, lo sponsor deve avere un’idea precisa di cui che viene proposto. Questo è particolarmente importante nel caso in cui, con il consenso dello sponsor, può essere necessario eseguire del lavoro in pre-autorizzazione.

Pianificare il modo in cui il lavoro verrà gestito implica lo sviluppo di politiche e procedure per tutte le pertinenti funzioni che verranno utilizzate. Quale possa considerarsi una ‘funzione pertinente’ dipende dal contesto del lavoro.

Pianificare il modo in cui il lavoro verrà consegnato richiede il possesso da parte del team di definizione delle necessarie competenze riguardo a tutte le funzioni pertinenti. I documenti di consegna che ne risultano definiscono il progetto o programma e come sarà eseguito. Una volta autorizzati, questi documenti costituiranno la baseline che fungerà da punto di partenza per il monitoraggio e il controllo dello stato di avanzamento.

Thamhain e Wilemon hanno identificato questa fase del ciclo di vita come quella in cui tipicamente si verifica il più elevato livello di conflittualità. Se si unisce questo al fatto che il team è ancora in via di amalgamazione e probabilmente si trova nella fase ‘storming’ di Tuckman, allora è evidente che il project o programme manager deve essere molto sensibile al conflitto e avere buone capacità di leadership, di gestione dei conflitti e di influenza.

Un processo di definizione ben eseguito getta le basi per la riuscita del processo di consegna.

 

Nominare il team di definizione

Nei progetti più piccoli il team di identificazione può avere competenze e capacità sufficienti per proseguire con l’intera definizione e portarla a termine. Nei progetti di dimensioni più grandi e nei programmi il team di identificazione avrà probabilmente bisogno di essere integrato in modo da poter disporre di sufficienti risorse dotate delle necessarie competenze. Un progetto di costruzione può avere necessità di ingaggiare specialisti supplementari come ingegneri strutturali o meccanici ed elettronici (M&E); un programma di cambiamento dell’infrastruttura IT o del business può dover reclutare ulteriori analisti di business o architetti di sistemi.

Tali ruoli tecnici sono focalizzati sulla definizione dell’ambito del lavoro e saranno meno coinvolti nella fase di consegna del progetto o programma. Solitamente il lavoro di preparazione dei piani di gestione, dei documenti di alto livello relativi all’ambito, e dei documenti di consegna iniziali viene svolto dai ruoli che andranno a costituire il team che gestisce la fase di consegna.

 

Definire l’ambito

Le procedure descritte nella funzione di gestione dell’ambito saranno utilizzate per catturare i requisiti degli stakeholder, sviluppare soluzioni e definire i benefici, a seconda dei casi. L’ambito di alcuni progetti riguarderà soltanto i prodotti, mentre altri includeranno anche i benefici. L’ambito dei programmi ricomprenderà i benefici e spesso anche i cambiamenti significativi di business necessari per realizzarli.

Fra i documenti che sono appropriati per i progetti o i programmi si possono annoverare:

La gamma dei documenti relativi all’ambito e il loro livello di dettaglio saranno influenzati anche dal ciclo di vita prescelto. Di solito in questa fase gli obiettivi (prodotti o benefici) saranno definiti in maggior dettaglio in un ciclo di vita seriale piuttosto che in un ciclo di vita parallelo. Approcci paralleli (come ad esempio agile) svilupperanno continuamente l’ambito per tutto il ciclo di vita, per cui la definizione iniziale sarà flessibile e per grandi linee.

 

Lavoro in pre-autorizzazione

La conclusione di tutto il lavoro di pianificazione prima di un qualunque tipo di mobilitazione o di avvio di un pur minimo lavoro di consegna è spesso irrealizzabile. Ci può essere bisogno di materiali o attrezzature specialistici che sono soggetti a tempi di consegna lunghi; può essere necessario far partire in anticipo l’approvvigionamento dei fornitori attraverso gare d’appalto; la richiesta di approvazioni di legge o regolamentari può prendere molto tempo.

Parallelamente alla pianificazione, il team di gestione dovrebbe identificare l’eventuale lavoro in pre-autorizzazione da svolgere prima della sua piena definizione e autorizzazione. Il vantaggio derivante dall’emissione di ordini provvisori per i materiali o dall’avvio di una procedura di gara deve essere valutato in rapporto al rischio che la fase o la tranche successiva non venga poi autorizzata.

L’esecuzione del lavoro in pre-autorizzazione deve essere pianificata e concordata con lo sponsor. Il completamento di questo lavoro deve essere riportato nei piani, ma il fatto che il lavoro in pre-autorizzazione sia stato completato non deve costituire un fattore che influenza il giudizio di fattibilità del business case al momento di presentare la richiesta di autorizzazione.

 

Preparare i documenti di governance

La documentazione di governance include i piani di gestione prodotti internamente e qualsiasi documento esterno di policy. I piani di gestione possono essere scritti per numerose funzioni e ogni procedura funzionale inizia con un passo denominato ‘piano’. Alcuni, come ad esempio il piano di gestione degli stakeholder o il piano di gestione del rischio, sono universali, dal momento che tutti i progetti e programmi hanno la necessità di gestire gli stakeholder e il rischio. Altri, come il piano di gestione dei benefici o il piano di gestione degli approvvigionamenti, sono pertinenti solo se l’ambito del lavoro copre la consegna dei benefici o nel caso in cui vengano utilizzati fornitori esterni.

In Praxis la creazione indipendente di piani di gestione che derivano da progetti o programmi è un attributo del livello 2 di capability.

La creazione di piani di gestione controllati centralmente e adattati al contesto di ciascun progetto e programma è un attributo del livello 3 di capability.

Basandosi sull’ambito del lavoro, il team di definizione deciderà quali funzioni abbiano bisogno di un piano di gestione. In organizzazioni più mature ci saranno dei piani di gestione standard che verranno adattati allo specifico contesto del lavoro. In organizzazioni meno mature i piani di gestione tendono a essere ricreati per ogni nuovo progetto o programma.

I piani di gestione non dovrebbero essere preparati singolarmente. Ciascuno di essi sarà influenzato dai documenti di consegna e dagli altri piani di gestione. Per esempio, se la mappa degli stakeholder identifica una potenziale opposizione al lavoro, il piano di gestione del rischio dovrà assicurare che questo tipo di rischio venga adeguatamente gestito.

 

Pianificazione della consegna

Il contenuto e l’estensione di questa attività sono specifici di ogni progetto o programma. I vari documenti di pianificazione si occuperanno di aspetti differenti. Esempi tipici sono:

Sebbene questi strumenti e queste tecniche siano elencati separatamente, interagiscono tutti fra loro. Non sarà possibile prepararne uno alla volta. Il processo sarà iterativo e vedrà, per esempio, la prima bozza della mappa degli stakeholder fornire informazioni per la prima bozza del registro dei rischi, il quale, a sua volta, può influenzare l’iniziale valutazione dell’investimento.

Solitamente non è necessario, o neanche desiderabile, pianificare in dettaglio l’intero progetto o programma. In un progetto, la prima fase sarà pianificata in dettaglio ma il lavoro rimanente verrà pianificato a un livello più alto. In un programma, i piani per la prima tranche saranno più dettagliati rispetto al resto del lavoro. Questo è ciò che viene chiamato pianificazione a finestra mobile. La documentazione di consegna sarà dunque suddivisa in due parti, il piano di consegna complessivo e i piani di consegna dettagliati per la prima fase o tranche.

Una volta che il progetto o programma è stato autorizzato, questi documenti ne costituiranno la baseline. Durante la fase di consegna, lo stato di avanzamento verrà monitorato e confrontato con i documenti baseline.

 

Consolidare la documentazione di definizione

Al termine del processo di definizione, una richiesta di autorizzazione verrà sottoposta allo sponsor del progetto o programma. La decisione se procedere o meno con la fase di consegna viene presa dopo una revisione della documentazione pertinente. Se viene concessa l’autorizzazione, il passo successivo è mobilitare la prima fase di progetto o tranche di programma della fase di consegna. Se non viene concessa l’autorizzazione, si svolgerà una versione ridotta del processo di chiusura per smobilitare il team di definizione e archiviare le informazioni.

Sebbene la natura di ciò che viene sottoposto ad approvazione varierà a seconda del contesto, è cosa comune fornire tre documenti:

  • Piano di gestione del progetto o programma
  • Questo documento riassume o riunisce insieme tutti i piani di gestione per il progetto o programma. Può essere un unico documento indipendente con una sezione dedicata per ciascuna funzione pertinente, oppure una collezione di piani di gestione separati.

  • In un’organizzazione matura che impiega piani di gestione standard per tutto il proprio portfolio di progetti e programmi, sarà necessario solamente che il piano di gestione complessivo presenti riferimenti incrociati e evidenzi gli adattamenti fatti in base al contesto del lavoro attuale. Uno sponsor che ha familiarità con questi standard organizzativi dovrà solo prendere in considerazione gli adattamenti per essere rassicurato sul fatto che il lavoro sia sottoposto alla governance necessaria.

  • Business case  
  • Il business case spiega la giustificazione del lavoro. Tale documento riepilogherà l’ambito del lavoro e lo confronterà con i costi e i rischi che sarà necessario affrontare per realizzarlo. Così facendo, conterrà riferimenti incrociati ai documenti di consegna e di contenuto più dettagliati, come ad esempio le specifiche, i budget, il registro dei rischi e così via.

  • Piano di consegna del progetto o programma
  • Il piano di consegna mostra come verranno raggiunti gli obiettivi. Questo documento sintetizza i documenti di consegna e conterrà una tempistica complessiva, i requisiti delle risorse, il flusso di cassa e le strutture organizzative.

  • Questo piano più coprire tutto il lavoro da svolgere o può fare riferimenti incrociati a piani di fase, tranche o aree funzionali più dettagliati, come ad esempio quelli delle comunicazioni, del rischio o della qualità.

 

Mobilitare

Una volta ricevuta l’autorizzazione, il progetto o programma può essere mobilitato. Questo significa mettere in atto tutte le attrezzature, le strutture e le altre risorse necessari per raggiungere gli obiettivi.

 

Progetti e programmi

Nei progetti piccoli le attività di definizione possono essere gestite ed eseguite dal project manager, ma la presenza di uno sponsor e di un manager fra loro distinti è il requisito minimo. Può essere possibile anche combinare le fasi di identificazione e di definizione in un unico processo.

Questo processo crea molta documentazione.  Una documentazione eccessiva è dannosa per il potenziale successo del lavoro tanto quanto lo è una troppo scarna. La sezione sulla documentazione di Praxis non dovrebbe essere interpretata come l’insieme di documenti che è necessario produrre. Piuttosto rappresenta la gamma di documenti che può essere utilizzata. Decidere quale particolare insieme di documenti sia più adeguato alle dimensioni e alla complessità di ciascun progetto o programma è una parte importante di questo processo.

Inoltre è importante decidere quale sia la documentazione pertinente per lo specifico scopo della richiesta di autorizzazione. Nei progetti piccoli la documentazione può essere sintetizzata in punti chiave in una presentazione allo sponsor. Nei progetti di grandi dimensioni o nei programmi, i documenti di governance e di consegna possono essere riassunti e forniti allo sponsor per l’analisi, rimanendo i documenti di dettaglio a disposizione per l’eventuale verifica, se necessario.

In alcuni contesti, il processo di definizione può essere eseguito da un’organizzazione cliente. La documentazione di definizione può essere affidata ad un appaltatore che pianifica la consegna. Il processo di definizione viene in tal caso suddiviso tra il lato cliente del progetto e il lato appaltatore del progetto.

Nei programmi più grandi il processo di definizione può essere di per sé un piccolo progetto. Può essere condotto come un progetto di cui la documentazione di definizione del programma e il piano di consegna costituiscono i prodotti. Tutti gli aspetti del modello di questo processo sono scalabili e versioni più ridotte dello stesso possono essere contenute all’interno di quelle più grandi.

 

Grazie a E-quality Italia e a Project Management Europa per la traduzione

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Torna in cima