La dimensione consulenziale dell’attività del Project manager è, a nostro avviso, trasversale a qualunque settore applicativo ed è presente, con forme e modalità diverse, in tipologie di progetti significativamente differenti tra loro. A tale proposito una classificazione interessante è quella proposta da Lundin e Söderholm (1), che identifica tre macro tipologie di progetti:
– Production projects. Progetti realizzati in settori industriali organizzati in prevalenza per progetti; rientrano in quest’area i progetti in settori quali le costruzioni, la consulenza organizzativa, l’information technology.
– Innovative projects. Progetti sviluppati in settori industriali dove l’uso dell’approccio per progetti è solo parziale ma tuttavia essenziale; è il caso ad esempio dello sviluppo prodotto in aziende tecnologicamente avanzate.
– Renewal projects. Progetti con una spiccata caratteristica di unicità nell’organizzazione che primariamente li gestisce; rientrano in questa categoria i progetti di sviluppo organizzativo.
In estrema sintesi, si può sostenere che, nei progetti del terzo tipo, l’aspetto consulenziale si esplicita in attività orientate prevalentemente alla definizione progressiva dei confini dell’iniziativa e di ricostruzione e condivisione del significato del progetto e dei suoi obiettivi, mentre per quanto riguarda il secondo tipo (innovative projects) la consulenza è finalizzata soprattutto ad aiutare il committente a verificare e mantenere la coerenza tra il prodotto in sviluppo e i bisogni che lo hanno generato.
Ma è soprattutto nella prima categoria (production projects, dove ricadono, tra gli altri, i progetti svolti dalle aziende IT per i propri clienti) che, a nostro parere, si hanno situazioni in cui si assiste ad un’evoluzione del ruolo del PM. In particolare, accade sempre più spesso che il project manager sia direttamente coinvolto nella gestione della relazione con il cliente e in attività di sviluppo di nuovo business. Ecco quindi che l’approccio consulenziale diventa cruciale per interpretare correttamente il proprio ruolo di capo progetto.
Indipendentemente dalla specifica tipologia di progetto, è indubbio che l’attività consulenziale è strettamente legata alle attività di ‘scoping’, per la definizione e inquadramento del progetto. Non a caso la PMBoK Guide (2) attribuisce una particolare enfasi a questi aspetti, sottolineando come la fase di impostazione del progetto sia determinante per una sua buona riuscita.
Entriamo dunque nel dettaglio di quest’attività di scoping, evidenziando il ruolo di consulenza che il project manager si trova ad assumere sempre più spesso. In altri termini, vedremo come provando a leggere l’attività di scoping attraverso questa prospettiva, è possibile mettere in luce, oltre ai compiti classici del project manager, una serie di competenze cruciali nel determinare il successo del progetto e specificamente legate alla sua capacità di consulenza e di orientamento. Dettagliando le direttrici lungo le quali si declina questo ruolo di advisor del project manager scomporremo, al fine dell’analisi, diverse dimensioni che nella realtà sono fortemente intrecciate e correlate tra loro.
Tradurre aspettative vaghe in un project scope definito
Molto spesso il committente quando avvia un progetto ha solo un’idea generale di ciò che vuole realmente ottenere. Ha in mente degli obiettivi da raggiungere, dei benefici da ottenere, ma quasi mai un’idea dettagliata della soluzione da adottare. Pertanto, ruolo cruciale del project manager è quello di indagare le necessità iniziali espresse per orientare e inquadrare al meglio il progetto. Questo sforzo si concretizza in un processo che possiamo rappresentare nello schema di figura 1.
Figura 1 – Dall’analisi dei bisogni alla definizione del project scope
fonte ISTUD
Attività fondamentale del project manager all’avvio del progetto è quello di ‘scavare’ nei bisogni e nelle aspettative del cliente. Deve analizzarle, verificarle, definirne la priorità, la congruenza. Quest’attività di analisi e indagine porta ad un secondo passaggio del processo, quello di definizione dei requisiti, arrivando a stabilire cosa deve essere in grado di fare il prodotto o servizio output del progetto stesso. Il passo successivo consiste nella descrizione delle caratteristiche del prodotto che rispondano ai requisiti così identificati. Infine, dalla descrizione del prodotto si passa a delineare il progetto, cioè tutto il lavoro necessario per realizzare il prodotto che è stato definito.
Quanto descritto si riferisce ovviamente un processo ideale per pervenire dai bisogni del committente alla definizione e inquadramento del progetto. In questo processo il project manager gioca due ruoli fondamentali, quello di ‘translator’ e quello di ‘challenger’. Da un lato, infatti, il project manager compie uno sforzo di ‘traduzione’ per passare da un fase all’altra del processo: dai bisogni ai requisiti, dalle caratteristiche del prodotto alle caratteristiche del progetto. Dall’altra parte, il ruolo di challenger esprime come, dopo aver negoziato ed essere pervenuto ad un quadro condiviso del progetto con i diversi stakeholder coinvolti, il PM assuma la ‘sfida’ insita nell’impegno a raggiungere i risultati fissati nel rispetto dei tre vincoli classici di tempo, costi e rispetto dei requisiti.
Saper leggere i bisogni e visualizzare i valori attesi
Strettamente legata alla capacità di traduzione è l’abilità di cogliere e far emergere i bisogni inespressi, latenti. Questo implica capacità di ascolto e di analisi, interpretando anche oltre quanto esplicitamente dichiarato. Questo fenomeno è maggiormente presente in quei progetti che riguardano la realizzazione di un bene intangibile (informazioni o servizi). L’emergere dei bisogni latenti chiama in causa direttamente il tipo di relazione instauratasi tra project manager e committente o cliente. Tanto più ci si sposta verso una relazione di partnership tanto più sarà necessario realizzare uno sforzo per riorientare le aspettative del cliente sulla base delle esigenze emerse.
Un’ulteriore problematica immediatamente conseguente è quella di individuare una scala di priorità tra i diversi bisogni e aspettative. Attività per la quale è fondamentale la capacità di coinvolgimento attivo del cliente.
Occorre inoltre avere la capacità di visualizzare il successo del progetto come strettamente collegato al valore che il cliente ottiene dal prodotto output del progetto. In una prospettiva consulenziale il successo del progetto non è più esclusivamente legato al mero rispetto di tempi, costi e requisiti prefissati, ma è visto in termini di rispondenza alle reali esigenze del cliente. Successo del progetto quindi non solo come conformità ai requirements ma anche e soprattutto come ‘fitness for use’.
In altri termini, perché il progetto sia considerato di successo bisogna sì garantire la coerenza rispetto ai requisiti definiti a monte, ma anche e soprattutto, fornire un prodotto-servizio che sia in grado di rispondere ai reali bisogni per cui il progetto è stato avviato.
Per dettagliare tale concetto ci viene in aiuto la distinzione tra ‘benefit’ e ‘feature’.
All’avvio di quasi tutti i progetti il cliente è interessato e focalizzato sui benefits, cioè sui benefici che intende ottenere dai risultati del progetto. Attività cruciale del project manager è tradurre questi benefits in features, cioè in caratteristiche del prodotto-servizio da realizzare che siano realmente in grado di soddisfare gli specifici benefici attesi. Un modo per realizzare questo passaggio consiste nell’aiutare il committente a ‘visualizzare’ quello che sarà il risultato finale del progetto e a favorire una visione condivisa tra tutti gli stakeholder.
Gestire il contesto
È chiaro che l’ambiente nel quale il progetto si svolge e i tratti distintivi del contesto sono in grado di influenzare fortemente il progetto, il modo di concepirlo, le possibili modalità di gestione. Occorre quindi che chi gestisce i progetti sappia ‘sondare il terreno’, interpretando le ragioni sostanziali che sono all’origine dell’iniziativa. La prospettiva consulenziale sottolinea l’importanza da parte del project manager dello sforzo di lettura e ricostruzione del contesto, della mappa degli stakeholder, delle forze in gioco, degli interessi, delle possibili influenze organizzative, delle inevitabili relazioni tra il progetto in esame e le altre iniziative in corso.
Le variabili in gioco all’interno del contesto organizzativo rilevante per il progetto sono diverse e molto intrecciate tra loro. Sintetizzando, possiamo individuarne almeno quattro: la cultura dell’organizzazione; gli attori chiamati in causa dal progetto (il sistema di stakeholder); il modo di organizzare il lavoro tipico dell’organizzazione di riferimento (processi e procedure); le strutture organizzative.
Capire i clienti e relazionarsi con gli stakeholder
Nel gestire un progetto il project manager deve essere in grado di analizzare e segmentare il ‘sistema cliente’, svolgendo quella che viene solitamente indicata con il termine di stakeholder analysis. Di norma è possibile distinguere diversi tipi di cliente :
– clienti iniziali, coloro che stabiliscono il contatto iniziale con il capo progetto, con una richiesta o un problema;
– clienti primari, coloro che ‘possiedono’ il problema o la questione alla quale si sta lavorando;
– clienti intermedi, coloro che partecipano alle riunioni, alla pianificazione e ad altre attività nel corso del progetto;
– clienti finali, sono i membri dell’organizzazione direttamente coinvolti (volontariamente o meno) dalle decisioni prese dal cliente primario.
Non sempre i ruoli sono chiaramente identificabili: a volte il cliente iniziale, intermedio, primario e finale coincidono, a volte sono persone diverse. Inoltre la tipologia e il numero dei clienti varia nel tempo e in funzione delle fasi specifiche del progetto. Peraltro, conoscere il sistema cliente significa anche comprenderne la cultura, i valori, le regole di business, la struttura organizzativa. Significa inoltre osservare le dinamiche relazionali esistenti tra gli stakeholder per verificare la corrispondenza tra poteri formali e sostanziali e le reciproche influenze (vedi figura 2).
Figura 2 – I ruoli più comuni in un’analisi degli stakeholder di un progetto
fonte:ISTUD
Il project manager spesso viene visto dal cliente soprattutto come un esperto nel campo specifico del problema ma, accanto alle conoscenze tecniche, competenza cruciale del project manager è quella di riuscire a coinvolgere l’organizzazione nella attività di diagnosi del problema e sviluppo del progetto. Questo spostamento di focus è particolarmente evidente nelle aziende del mondo IT, dove al crescere del ruolo assunto dal project manager cresce parimenti l’enfasi sulle competenze di relazione e di gestione del rapporto con il cliente. Ecco quindi che il project manager deve essere esperto in materia di relazioni umane, particolarmente per quanto concerne la capacità di costruire relazioni di fiducia e di stabilire delle relazioni interpersonali basate su una collaborazione reciproca. Diventa fondamentale conoscere le regole culturali dell’interazione e della comunicazione.
Definire il proprio ruolo
Fondamentale per il project manager è analizzare e definire consapevolmente il contratto psicologico esplicito e implicito tra sé e il committente. È cruciale arrivare a definire che cosa ognuna delle due parti si aspetta di dare e di ricevere, quali condizioni psicologiche e interpersonali (tipo: fiducia, accettazione, rispetto reciproci) si devono verificare perché lo scambio possa avvenire nel modo migliore e come queste condizioni possono essere rispettate.
La relazione tra committente e project manager spesso si caratterizza per una condizione di asimmetria. Il riequilibrio della relazione richiede conoscenza delle dinamiche sociali di ruolo. All’inizio di ogni relazione ogni parte interessata assegna all’altra una posizione, basandosi su norme culturali e necessità personali; un passaggio fondamentale consiste nell’esplorare le reciproche attese al fine di chiarire le reciproche aspettative.
Un’ulteriore dimensione strettamente collegata alla gestione della relazione psicologica con gli stakeholder è la capacità di governare la resistenza al cambiamento. Il cambiamento, l’innovazione, la novità sono elementi connaturati alla natura stessa del progetto. La maggior parte delle persone tuttavia sono resistenti al cambiamento. Questo perché ogni novità porta con sé il germe dell’insicurezza e rischia di mettere in discussione le esperienze e i risultati conseguiti finora. Ecco quindi che il project manager deve imparare a conoscere e gestire l’inerzia, naturale conseguenza della resistenza al cambiamento.
Governo del processo di elaborazione progressiva
Nella già citata PMBoK Guide si sostiene che una caratteristica in grado d’integrare i concetti di unicità e di temporaneità propri del progetto, è quella della ‘elaborazione progressiva’. Quasi mai un progetto è definito in un quadro dettagliato e puntuale in fase di avvio. Al contrario i suoi confini, le sue caratteristiche e le specifiche attività che dovranno essere realizzate sono definiti progressivamente man mano che si procede con lo sviluppo del progetto stesso.
Il project manager deve essere consapevole del fatto che il processo di elaborazione continua lungo l’intero ciclo di vita del progetto. A nostro avviso l’ottica consulenziale sprona il project manager a presidiare lo ‘scope’ definito e far sì che rimanga coerente rispetto alle esigenze dei vari stakeholder durante l’intero sviluppo del progetto e, quindi, a governare cambiamenti, modifiche e varianti in questa prospettiva.
Concludendo, l’osservazione empirica evidenzia che non di rado il project manager si percepisce come un mero esecutore, costretto a rispettare tutta una serie di vincoli e condizioni che altri hanno definito. Al contrario leggere e interpretare il ruolo del project manager secondo la prospettiva consulenziale che proponiamo, consente di inquadrare il proprio ruolo in modo significativamente diverso e di maggior respiro professionale.
1) R.A. Lundin – A. Söderholm. Conceptualizing a projectified society. In: Projects as arenas for renewal and learning processes; Kluwer Academic Publishers, Norwell MA, 1988.
2) PMBoK – A Guide to Project Management Body of Knowledge; P.M. Institute, Newtown Square PA; 2000.
Su questi argomenti si veda anche l’articolo: La gestione progetti: una scienza che cambia, su ZeroUno n.256, maggio 2003, degli stessi autori.
*) Mario Damiani e Pier Paolo Lo Valvo sono, rispettivamente, responsabile area Project Management e docente e ricercatore Istud.
