Stakeholder Performance Domain – PMBOK® Guide 7th Edition

Secondo il PMBOK^® Guide 7th Edition ci sono due definizioni molto importanti che riguardano questo Performance Domain:

Questo performance domain riguarda la collaborazione con gli stakeholder (le parti interessate), con lo scopo di mantenerli allineati e coinvolti, in modo da riuscire ad impostare relazioni produttive e soddiisfacenti.

La definizione mostrata precedentemente stabilisce chiaramente che uno stakeholder può essere un individuo, un gruppo o un’organizzazione. Tra l’altro è possibile che gli stakeholders cambino durante il ciclo di vita del progetto e possono essere interni o esterni al progetto stesso. Ma la domanda fondamentale qui è: qual’è l’insieme dei concetti, delle idee degli spunti, delle attività consigliate che mi aiutino ad avere un rapporto produttivo con gli stakeholder? Per raggiungere questo obbiettivo, dobbiamo fare in modo che siano coinvolti (engaged), dobbiamo capirli, dobbiamo renderli partecipi, dobbiamo fare in modo che ci aiutino nella delivery del progetto. Ma vogliamo anche creare del “valore” per loro. Vogliamo quindi ottenere delle buone relazioni (relationships appunto) con loro. Nel Performance domain quindi rientrano tutte quelle pratiche consigliate per interagire efficacemente con gli stakeholder.

Stakeholder engagement

Come coinvolgere efficacemente gli stakeholder? Schematizziamo graficamente di seguito quali sono le strategie e le azioni che costituiscono un’efficace e produttivo approccio allo stakeholder engagement.

Le attività relative allo stakeholder engagement iniziano dall’inizio (o anche prima dell’inizio) del progetto e proseguono durante tutto il suo ciclo di vita. Discutiamo uno ad uno gli step dello stakeholder engagement rappresentati nello schema.

Identify

Perché è così importante una corretta identificazione degli stakeholder? Quando è meglio iniziare questo step e per quanto tempo va portato avanti? Anzitutto è bene tenere presente che la mancata individuazione di stakeholder importanti può comportare la ripetizione dell’intero lavoro fatto fino a quel momento. Non solo alcuni aspetti importanti potrebbero essere stati trascurati (o addiruttura alcuni requisiti potrebbero non essere emersi del tutto e quindi costituire potenziali Change Request future), ma il fatto di non essere stati considerati potrebbe portare gli stakeholder ad esprimere la massima resistenza al cambiamento che il risultato del progetto necessariamente rappresenta. Addirittura potrebbero divenire ostili e rappresentare un ostacolo difficilmente sormontabile. Potrebbe sembrare prematuro cercare di individuare fin da subito gli stakeholder, ma il rischio di compromettere la corretta definizione dello scope di progetto e del corretto set di requisiti è così grande, che non ci si può permettere di correrlo. In realtà, può essere condotta un’individuazione ad alto livello degli stakeholder ancora prima che venga costituito il Project Team. In una fase successiva si proseguirà con un’individuazione più dettagliata e continua durante tutto il ciclo di vita del progetto. Alcuni stakeholder sono facili da identificare (ad es. il cliente, lo sponsor, il project team, gli utenti finali e così via), ma altri potrebbero essere particolarmente difficili, specialmente se non appaiono direttamente connessi al progetto.

Understand

Abbiamo ora in mano una lista degli stakeholder. Dallo schema grafico presentato in precedenza, emerge il carattere ciclico dell’engagement. Ogni volta che aggiorniamo la nostra lista degli stakeholder, dovremo poi affrontare il passo successivo che è quello di “capirli”: quali sono i loro valori, le loro convizioni, emozioni, aspettative, qual’è la loro visione? Questi elementi possono essere di fondamentale importanza per far emergere opportunità o minacce relative ai risultati di progetto. Purtroppo, non esiste alcun corso o standard da seguire per riuscire a dominare la capacità di capire gli stakeholder: è tutta una questione di soft skills ed esperienza. Alla base c’è sempre in ogni caso la cura delle capacità di comunicazione. In questo senso si possono sviluppare alcuni aspetti che fanno capo alla comunicazione non verbale (liguaggio del corpo, tono della voce, …), active listening e così via.

Analyze

Oltre che comprendere gli stakeholder, dobbiamo necessariamente analizzarne la posizione rispetto al progetto. Ma di cosa stiamo parlando di preciso? L’analisi degli stakeholder consiste nella raccolta di informazioni su di essi in base alle quali analizzarli mediante un approccio sistematico. Le informazioni raccolte possono essere di natura qualitativa o quantitativa e l’analisi ha appunto lo scopo di comprendere gli interessi, la posizione degli stakeholder rispetto al progetto, al fine di stabilirne l’importanza per il progetto stesso.

Cosa è importante analizzare?

Anzitutto, il livello di interesse: è un progetto che gli preme? E’ intenzionato ad impegnarsi, è abbastanza coinvolto dal progetto? Ovviamente, maggiore è il suo grado di interesse, maggiore sarà il valore aggiunto che sarà in grado di apportare. Ad esempio, un membro del team di progetto (uno stakeholder interno quindi), potrebbe essere particolarmente interessato e coinvolto perché nel progetto viene utilizzata una tecnologia di cui gli interessa acquisire gli skill. E’ ovvio che un collaboratore di questo tipo è di maggior vantaggio per il progetto (sarà maggiormente prosdduttivo), rispetto ad un altro completamente disinteressato. In questo senso, la stessa modalità di attribuzione dei ruoli e delle responsabilità può essere determinante per massimizzare l’engagement da parte degli stakeholder interni ed esterni.

Anche stabilire il potere degli stakeholder è di fondamentale importanza. E’ chiaro che uno stakeholder che abbia un grande potere che è particolarmente interessato al progetto, può costituire una grande risorsa. Costui potrebbe avere un ruolo importante non solo per sponsorizzare il progetto in sé, ma anche nei momenti di criticità, mettendo a disposizione risorse addizionali o anche facilitando processi e decisioni.

Sebbene alcuni stakeholder possano avere minor potere, potrebbero avere competenze e autorevolezza tali da esercitare una leadrship in grado di influenzare il progetto significativamente. Quindi anche il grado di influenza che uno stakeholder è in grado di esercitare deve essere misurato ed “utilizzato” come un vero e proprio asset di progetto. Immaginate cosa accadrebbe se uno stimato membro del team, a cui tutti riconoscono autorevolezza e leadership, non è favorevole all’adozione di una determinata tecnologia: si diffonderebbe diffidenza e disaffezione da parte degli altri stakeholder interni, che ben presto inizierebbero ad assumere una posizione ostile e abbassare la produttività. Non dimentichiamo ad esempio nei progetti di sviluppo software le guerre di religione nell’adozione di un sistema operativo o l’altro o di quel linguaggio di programmazione piuttosto che quell’altro. E’ chiaro che un membro influente del team, di cui tutti riconoscono la leadership, è in grado di affossare una scelta tecnologica a lui invisa, instillando negli altri membri ad esempio il dubbio che lavorare con quella particolare tecnologia non sia vantaggioso per la propria crescita professionale.

Altro concetto fondamentale da tenere in considerazione è quello di prossimità. Tanto più uno stakeholder è “vicino” all’ambiente di progetto, tanto più avranno potere, interesse e grado di influenza sul progetto. Chi lavora nell’azienda in cui si svolge il progetto è chiaramente più vicino al progetto e quindi più influente, più interessato e con più potere di un esterno.

Parliamo poi dell’impatto che un risultato di progetto può avere sugli stakeholder. Uno stakeholder che percepisce un impatto negativo dal successo del progetto, cercherà di utilizzare tutto il suo potere e la sua influenza per affossarlo. Si pensi ad esempio ad un dipendente aziendale che si sente minacciato da un progetto, che se andrà in porto comporterà lo scioglimento della divisione in cui lavora da anni: farebbe di tutto per ostacolarlo.

Per comprendere (ed eventualmente prevedere) i comportamenti degli stakeholder, devono essere considerate le loro convinzioni ed attitudini. Se il progetto riguarda il software di un nuovo elicottero da guerra, un membro del team di progetto pacifista potrebbe rivelarsi uno stakeholder negativo, che cercherà di remare contro.

Ricordiamo di tenere sempre presenti i bisogni e le aspettative, che se non considerate potrebbero farli sentire messi da parte. Questa è una componente molto complicata di cui tenere conto, perché le aspettative di differenti stakeholder potrebbero essere in conflitto tra di loro. E’ questo il motivo fondamentale per cui a valle di tutta l’analisi si deve anzitutto stilare una classifica degli stakeholder in ordine di priorità: è chiaro che le aspettative degli stakeholder a priorità maggiore vanno maggiormente tenute in considerazione.

Prioritize

Una volta identificati tutti gli stakeholder, è chiaro che si deve condurre l’analisi secondo questi parametri descritti: potere, interesse, influenza, impatto, convinzioni, attitudini, prossimità, aspettative e in generale tutti quegli aspetti che riguardano l’interazione degli stakeholder con il progetto. Ma il numero degli stakeholder potrebbe essere veramente grande, tanto da rendere praticamente impossibile valutare questi parametri per tutti. Si deve in questo caso adottare una tecnica per restringere il numero degli stakeholder da considerare. Una potrebbe essere quella di valutare l’autorità che uno stakeholder ha rispetto agli altri. E’ chiaro che in questo senso la scelta può ricadere sulle figure apicali (dei responsabili di division ad esempio), cercando di spendere meno tempo sugli altri, oppure su quelle che hanno una influenza maggiore. Un altro criterio potrebbe essere quello di raggruppare gli stakeholder per interesse o per aspettative simili.

Un’altra scrematura del lavoro potrebbe essere presa in considerazione pensando che non tutti gli stakeholder è necessario che siano coinvolti fin dall’inizio. Organizzare in altre parole una schedulazione adeguata dell’analisi da condurre, privilegiando quelli a priorità maggiore in quella data fase di progetto.

Si può adottare un approccio sistematico per stabilire le priorità degli stakeholder. Anzitutto, è bene tradurre le informazioni di tipo qualitativo in informazioni quantitative, in modo da facilitare il compito di stabilire la classifica delle priorità.

Informazioni qualitative del tipo quanto uno stakeholder è potente, interessato ed influente, vanno tradotte in numeri. Per far questo si devono prevedere delle categorie predeterminate in base alle quali dedurre il valore del determinato attributo. Supponiamo di voler attribuire un valore al potere di uno stakeholder. Potremmo tenere in considerazione quali vincoli di progetto è in grado di influenzare e stabilire un grado di influenza:

Chiaramente questo è solo un esempio: a seconda del tipo di progetto e delle esigenze specifiche, va ideato il proprio sistema di attribuzione del punteggio.

Una volta attributo tramite questa tabella un punteggio per ogni stakeholder, potremo ordinarli in base al loro potere. Quelli che risulteranno avere stesso punteggio, andranno classificati ulteriormente in base ad altri aspetti, come interesse ed impatto. L’importante è utilizzare lo stesso sistema di valutazione per tutti gli stakeholder.

Il metodo più usato per assegnare la priorità agli stakeholder è mediante la rappresentazione potere/interesse:

Questa rappresentazione aiuta a raggruppare gli stakeholder in quattro classi principali (High Power – High Interest/High Power Low Interest/Low Power High Interest/Low Power Low Interest). A seconda della classe, il gruppo di stakeholder dovrà essere coinvolto (engaged) in modo diverso.

Engage

In merito a questo step, sul PMBOK® Guide 7th Edition leggiamo:

Quin la guida inizia giustamente ad incentrare il discorso sulla comunicazione, che è lo strumento fondamentale per consentire di raggiungere questi obbiettivi. In particolare fa riferimento alla classificazione secondo la tipologia verbale/scritta e formale/informale:

Tipo	Formale	Informale
Verbale	Presentazioni Project Reviews Briefings Product demos Brainstorming	Conversazioni e discussioni ad hoc
Scritta	Progress reports Documenti di progetto Business Case	Brief notes Email Instant messaging/Texting Social Media

Per ciò che concerne i metodi di comunicazione, li classifica tra push (comunicazioni inviate direttamente allo stakeholder come memo, email e così via), pull (comunicazioni in cui è lo stakeholder che attivamente va a cercarsele, ad esempio in un repository online, oppure attraverso una riceca sul web, e così via) ed interattive. Queste ultime sono qualcosa che va oltre il semplice push e pull: si tratta di uno scambio che avviene con conversazioni, meeting, call conference e così via. Ciò che è di fondamentale importanza è stabilire un feedback loop veloce in modo da avere prima possibile contezza del fatto che il messaggio che si voleva comunicare allo stakeholder è stato compreso nel modo giusto, trova la sua approvazione, siano state identificate tutte le sfumature e i fraintendimenti possibili che possano portare ad incomprensioni ed in generale avere altre intuizioni utili.

Da quanto esposto appare chiaro che lo step di “engage” degli stakeholder richiede da parte del Project Manager il mettere in campo tutti i propri soft skill. E’ fondamentale l’active listening, le capacità di interrelazione personali, quelle di gestione dei conflitti, oltre che a tipici aspetti di leadership come stabilire la vision e il critical thinking.

Monitor

Questo step consiste nel monitoring delle relazioni con gli stakeholder e nell’elaborare delle strategie personalizzate per il loro coinvolgimento (engagement). In questo modo si mantengono efficacia ed efficienza delle attività di engagement degli stakeholder durante lo svolgersi del progetto, quando anche l’ambiente circostante evolve. In altre parole, si cerca di far fronte a questa dinamicità, che vede cambiare continuamente gli stakeholder stessi (che possono variare: presentarsene di nuovi e altri sparire, altri cambiare il loro potere o la loro attitudine). Inoltre, mentre si cerca di identificare e analizzare nuovi stakeholder, si valuta l’efficacia della strategia adottata (ed eventualmente si corregge). In questo senso è di fondamentale importanza riuscire a valutare il grado di soddisfazione degli stakeholder mediante una conversazione diretta. Vengono effettuate delle review di progetto (o dell’ iterazione) periodiche, delle review di prodotto, e così via, con lo scopo di ottenere dei feedback periodici. Nei casi in cui gli stakeholder sono numerosi, possono essere utilizzate delle survey.

---

Fonti:

• Wikipedia
• PMBOK^® Guide 7th Edition

Immagini:

• Public domain images from Pexels