Project Management: lo stakeholder ha sempre ragione

Come sta andando il vostro allenamento progettuale? Preso atto che in ogni momento della vostra vita siete circondati da progetti di vario genere e tipo, applicando gli esercizi delle ultime due schede dovreste aver migliorato due abilità fondamentali:

• gestire l’incertezza attraverso il Risk Management, prefigurando gli eventi che potrebbero accadere e avere impatto sul progetto per stabilire in anticipo le strategie di azione più opportune, evitando o limitando le minacce e favorendo o esaltando le opportunità
• affrontare i problemi senza confidare solo sul vostro fixer istinct da Mr. Wolf, ma attraverso l’applicazione di un processo strutturato di investigazione, diagnosi e soluzione.

Il workout di oggi parte da una domanda filosofica: per produrre cosa, ma soprattutto per chi fate un progetto?

Ormai sapete bene che un progetto è tale perché – in tempi definiti – deve raggiungere uno specifico obiettivo di cambiamento, realizzando qualcosa che prima non c’era: un prodotto, un servizio, un processo organizzativo o produttivo, un evento, etc. E questo qualcosa deve essere a beneficio di un numero più o meno ampio di persone.

Oggi vediamo quindi come il vero scopo di un progetto non è tanto, o non solo, essere completato rispettando tempi e costi pianificati, ma realizzare qualcosa che serva davvero a qualcuno.

Warm up

Qualsiasi progetto produce deliverable, che sono l’output finale rappresentato dagli oggetti – fisici e/o intangibili – che vengono rilasciati a clienti e utilizzatori.

Gli stakeholder sono invece tutti gli attori, diretti e indiretti, del progetto. In pratica tutte le persone, enti e organizzazioni sui quali il progetto e i suoi esiti hanno un qualche impatto, positivo o negativo che sia. Tra questi ci siete voi, il vostro team, i clienti e gli utilizzatori dei deliverable che realizzerete, lo sponsor che garantisce la copertura finanziaria e decine – centinaia nel caso di progetti di grandi dimensioni – di altri soggetti con cui fare i conti.

Immaginate di preparare un piatto per i clienti del vostro ristorante. Il deliverable è quello che servite a tavola, costituito dalla pietanza lavorata e impiattata. Preparereste un insalata di gamberoni crudi per una persona allergica ai crostacei? O un battuto al coltello di fassona piemontese per un vegetariano?

Ovviamente no. Purtroppo, però, anche quello che appare ovvio spesso viene trascurato, col risultato di impiegare male le risorse vanificando l’impegno.

Tra tutti gli stakeholder – voi che cucinate, il proprietario del ristorante e il personale di sala – sono gli avventori che gusteranno il vostro piatto quelli più importanti e legittimi. E’ per loro che cucinate, non per soddisfare il vostro ego di emuli di Carlo Cracco, e saranno loro a decretare il successo del piatto e il profitto del ristorante.

Facciamo un esempio più in grande. Si parla molto di arretratezza digitale dell’Italia, al 25esimo posto in Europa su 28 Paesi in base all’indice DESI della Commissione Europea, in particolare della Pubblica Amministrazione. Tuttavia, analizzando i dati si scopre che la nostra PA, rispetto a quelle di altri Paesi europei, pubblica molti più servizi online e open data, che però vengono utilizzati solo dal 16% dei cittadini, cioè meno della metà della media europea.

Insomma, la nostra PA avvia centinaia di progetti per realizzare servizi digitali che poi quasi nessuno usa. C’è quindi da chiedersi: erano quelli che servivano davvero? Quanti di questi, ad esempio, sono accessibili e fruibili in mobilità?

Parecchi stakeholder ne hanno comunque tratto giovamento: le Amministrazioni, che possono dire di avere impiegato il budget disponibile per realizzare servizi che “fanno statistica”; i dirigenti responsabili, che hanno probabilmente raggiunto gli obiettivi su cui sono incentivati; i fornitori di tecnologia, che li hanno realizzati nell’ambito di contratti in essere o nuovi. Persino gli sviluppatori, che probabilmente si sono divertiti a realizzare software con nuovi metodi e tecnologie.

Ci siamo però dimenticati dello stakeholder più importante: coloro per i quali in teoria quei servizi dovevano essere progettati e realizzati. Tant’è che anche AgID nel Piano Triennale per l’Informatica nella PA 2017-2019 afferma che la PA deve “considerare le esigenze dei cittadini e delle imprese come punto di partenza per l’individuazione e la realizzazione di servizi digitali moderni e innovativi”. Segno evidente che finora non è stato così.

Anche se i progetti che gestite non sono grandi e complessi come quelli per la trasformazione digitale della nostra PA, non importa. Dovete tutti allenare la vostra capacità di identificare correttamente gli stakeholder, comprenderne esigenze e necessità, fissare delle priorità – perché non è possibile accontentare sempre tutti – e determinare i deliverable che il progetto alla fine dovrà produrre.

Esercizi

Esercizio N. 1. Individuazione dei deliverable: non è sempre una cosa facile come sembra. Immaginate una festa per il diciottesimo compleanno di vostra figlia. Un elenco sommario e non esaustivo dei deliverable potrebbe includere il food and beverage, la torta, l’intrattenimento musicale, i biglietti di invito, il servizio fotografico e altro ancora.

Fate allora mente locale sui progetti che avete in corso adesso. Ce ne sono di sicuro. Mettetevi a tavolino e stilate per ciascuno di essi una lista dei deliverable che saranno rilasciati al termine come output. Se c’è qualche progetto per il quale non riuscite a farlo allora avete un problema, nel senso che state portando avanti delle attività che non è chiaro cosa debbano produrre.

Esercizio N. 2. Identificazione degli stakeholder: cominciate coi progetti più semplici e piccoli. Vedrete che anche in quei casi gli stakeholder sono sempre più di quanti immaginiate. Come fatto a suo tempo per problemi e rischi di progetto, è bene tracciare le informazioni alimentando un registro degli stakeholder, una specie di rubrica contatti del progetto, come quella qui di seguito.

1. numero progressivo (identificativo dello stakeholder)
2. nome
3. informazioni di contatto (indirizzo, recapito telefonico, etc.)
4. organizzazione di appartenenza (es. rischio perdita dati)
5. ruolo nell’organizzazione (es. manager, responsabile tecnico, etc.)
6. data di rilevazione o ultima modifica.

Al solito, è solo una tabella di partenza. Il vostro contesto potrebbe suggerirvi la raccolta di ulteriori informazioni e gli esercizi successivi suggeriranno altre colonne da aggiungere.

Alcuni stakeholder (es. il Project Manager, i membri del team, lo sponsor del progetto, il cliente, etc.) sono facili da individuare, ma non potete limitarvi solo a questi. A volte dovete mettervi sulle tracce degli stakeholder come veri e propri investigatori.

Qualche regola base da applicare:

Seguite i soldi, chiunque investe o ha un interesse economico nel progetto è uno stakeholder.

Seguite le risorse, chiunque fornisca risorse umane e materiali per l’esecuzione del progetto è uno stakeholder.

Seguite i deliverable, chiunque sia il destinatario di deliverable di progetto è uno stakeholder.

Seguite le firme, chiunque firmi, autorizzi o approvi degli output di progetto è uno stakeholder.

Esercizio N. 3. Analisi degli stakeholder: una volta identificati e censiti nel registro, gli stakeholder vanno analizzati, raccogliendo più informazioni possibili per comprendere il ruolo e l’impatto che hanno sul progetto e se questo sia positivo o negativo. Ad esempio, rispetto al progetto di costruzione di un nuovo centro commerciale con ipermercato alimentare, i commercianti al dettaglio della zona, potenzialmente danneggiati, avranno un atteggiamento contrario e potrebbero associarsi per ostacolare il progetto, mentre le aziende del settore edile e del relativo indotto avranno ovviamente un atteggiamento favorevole e spingeranno per la sua realizzazione.

Perché è importante conoscere bene gli stakeholder? Perché da essi dipendono due aspetti fondamentali di qualsiasi progetto: i requisiti e i flussi di comunicazione.

I requisiti sono le caratteristiche dei deliverable che dovete produrre. Abbiamo detto prima che preparate un piatto non perché piaccia voi, ma ai clienti del vostro ristorante. E più conoscete il vostro cliente (il “target” direbbero quelli che si occupano di marketing) più avrete chance di soddisfarlo. Per farla breve, potete pensare ai requisiti del progetto e dei deliverable come alla formalizzazione dei bisogni, delle necessità e delle aspettative degli stakeholder.

Le comunicazioni poi sono un aspetto cruciale. La comunicazione efficace di progetto è quella che fornisce a ciascun stakeholder le informazioni di cui ha bisogno, al momento giusto e nel giusto modo. Su questo pubblicheremo in futuro una scheda di allenamento specifica. Per il momento, potendo utilizzare diversi canali (es. face to face, telefono, email, chat, etc.) e diversi livelli di formalismo, dalla lettera vergata a mano col sigillo di ceralacca alla chiacchiera in attesa dell’ascensore, conoscere bene i vostri stakeholder vi darà gli elementi per decidere lo stile e la modalità di comunicazione più adatta a ciascuno nelle varie situazioni.

Ad ogni modo, sia i requisiti che i flussi di comunicazione sono l’esito di un processo complesso, che deve bilanciare le esigenze dei diversi attori, tenendo conto di priorità dettate dal ruolo e dal peso di ciascun stakeholder. Come determiniamo queste priorità? Con uno “stakeholder assessment”, come direbbero quelli bravi, da farsi come al solito con carta e penna. Tanto ormai lo sapete che i nostri allenamenti progettuali non richiedono attrezzature sofisticate.

Uno strumento facile e intuitivo sono delle matrici per rappresentare coppie di caratteristiche, ciascuna delle quali ha due valori possibili: tipicamente “alto / basso”, ma potete usare anche “sì/no”, “vero/falso” o altre coppie di valori convenzionali. Potete ad esempio utilizzare la coppia “power-interest”, che mette in relazione il potere dello stakeholder e l’interesse o il coinvolgimento che ha nel progetto, e quella “knowledge-preference”, che mette in relazione la conoscenza che lo stakeholder ha del progetto e dei suoi obiettivi e l’atteggiamento conseguente (a favore o contrario).

Tracciate su un foglio gli assi corrispondenti alla coppia di caratteristiche, evidenziate i quattro quadranti risultanti e, sulla base delle informazioni in vostro possesso, posizionate gli stakeholder individuati e censiti nel registro durante l’Esercizio 1, come nell’esempio di seguito.

Ho considerato per semplicità tre soli stakeholder: S1, S2 ed S3. Ho poi arricchito per comodità i quadranti con delle regole generali di gestione e con l’impegno che dovreste dedicare agli stakeholder che vi ricadono dentro.

Stando alle matrici, lo stakeholder S1 è quello più importante di tutti. La matrice power-interest ci dice che ha un interesse elevato nel progetto ma anche il potere di poter intervenire (es. è un manager, un responsabile di qualche unità organizzativa coinvolta, etc.). La matrice knowledge-preference ci dice invece che ha un’elevata conoscenza del progetto e l’interesse affinché vada a buon fine. Insomma, in entrambi i casi è quello a cui va data la massima attenzione e dedicato il massimo impegno.

Analoghe considerazioni potete farle, ovviamente di contenuto diverso, sugli altri due stakeholder S2 ed S3, in funzione del loro posizionamento sulle matrici.

Questo genere di rappresentazione è molto popolare e potete utilizzarlo per analizzare anche altre entità in contesti del tutto diversi, come fa ad esempio Gartner con il suo Quadrante Magico, dove si rappresenta il posizionamento sul mercato di aziende tecnologiche in specifici settori in funzione della coppia di caratteristiche “completezza di visione vs. capacità di realizzare”.

Tornando a noi, per completare l’esercizio conviene aggiungere al Registro degli Stakeholder 3 nuove colonne in più, per tracciare gli esiti dell’analisi di posizionamento sulle varie matrici:

7. livello di influenza sul progetto (es. alto, medio, basso)

8. prospettiva/Atteggiamento (es. positiva, neutrale, negativa)

9. livello di supporto da fornire (es. massimo, medio, basso, minimo).

Queste colonne non corrispondono necessariamente alle caratteristiche utilizzate nelle matrici di prima, ciò per svincolare la struttura del registro – che può essere un modello fisso – dalle dimensioni di analisi che di volta in volta potreste voler scegliere. L’importante è che dal posizionamento sulle matrici abbiate gli elementi per valorizzare le 3 nuove colonne che avete aggiunto.

Per esempio, per lo stakeholder S1 di prima, avremo livello di influenza alto, atteggiamento positivo e massimo supporto da fornire. Semplice no?

Esercizio N. 4, Gestione degli stakeholder: fatevi coraggio, siete ben oltre il giro di boa della scheda. Il grosso lo avete già fatto censendo gli stakeholder nel registro e analizzandoli. Ora sapete chi sono, che influenza hanno, come si pongono sul progetto e l’impegno che dovete dedicare a ciascuno di loro.

A questo punto non dovete fare altro che dare a ciascuno il livello di attenzione e di supporto in funzione delle esigenze e delle priorità. Qui i cosiddetti soft skills, cioè le abilità legate all’intelligenza relazionale ed emotiva, si rivelano preziosi: tatto, empatia, diplomazia, capacità di negoziare, atteggiamento positivo e costruttivo nel fronteggiare problemi ed imprevisti.

Volendo esprimere tutto con un unico concetto, dovete cercare di mantenere il giusto livello di coinvolgimento per ciascun stakeholder, che non dipende per forza dal suo livello di influenza. Se sviluppate una app per uno specifico target di utenza, l’amministratore delegato della società che vi ha commissionato il lavoro ha un grande potere di influenza sul progetto, ma avendo un sacco di impegni non potrà né vorrà essere “presente” a tempo pieno. Viceversa, il coinvolgimento degli utenti finali – o di un loro campione rappresentativo – dovrebbe essere massimo, day by day, nella fase di progettazione dell’interfaccia, visto che sono loro i destinatari del prodotto finale.

Vi propongo una scala di livelli di coinvolgimento (ingaggio) per gli stakeholder sulla quale costruire una semplice rappresentazione grafica, come quella di seguito.

Per ciascun stakeholder ci sarà un livello di coinvolgimento ottimale che vi attendete (Desiderato), da confrontare con il livello di coinvolgimento effettivamente raggiunto (Attuale). Maggiore è il gap, maggiore è l’impegno per colmarlo con azioni relazionali e di comunicazione.

Aggiungete quindi al registro degli stakeholder le ultime 2 colonne:

10. livello di coinvolgimento atteso (es. ignaro, resistente, neutrale, supportivo, direttivo)

11. livello di coinvolgimento attuale.

Riepilogando, come dovete eseguire questi 4 esercizi? Semplice.

Eseguite un circuito dei primi 3 esercizi all’inizio del progetto. Un elenco dei deliverable e un primo censimento e analisi degli stakeholder sono praticamente la prima cosa da fare in un progetto. L’esercizio 4 lo eseguite poi in maniera continua per tutta la durate dei lavori e periodicamente vi suggerirà quando rieseguire in particolare il n.2 e il n. 3, per:

• inserire e valutare nuovi stakeholder che intervengono in corso d’opera
• rivalutare periodicamente il livello di influenza, il potere, i rapporti di forza tra gli stakeholder già censiti e il livello di supporto da dare, che possono cambiare in corso d’opera
• monitorare il livello di ingaggio e agire per far si che, per ciascuno, coincida con quello atteso.

Riepilogando, il vostro registro degli stakeholder apparirà come di seguito.

Defaticamento e Stretching

I deliverable sono il risultato del progetto e dovreste individuarli con chiarezza il prima possibile. Le loro caratteristiche e requisiti dipendono dai bisogni, dalle necessità e dalle aspettative degli stakeholder, che sono la prima cosa di cui occuparvi sin dall’inizio del progetto e su cui raccogliere informazioni.

Se non sapete per chi, con chi e anche contro chi fate il progetto correte grossi rischi di realizzare qualcosa che non serve, vanificando impegno e risorse. Conoscere i vostri stakeholder vi metterà in condizione di comunicare efficacemente con loro e di soddisfarli, nei limiti del possibile, sfruttando il contributo di quelli che si pongono a favore e cercando di portare a bordo quelli che remano contro.

Insomma, alla fine gli stakeholder hanno sempre ragione, sono loro che decretano il successo di ciò che realizzate ovvero, parafrasando Justin King (“If you do the right thing for the customer, it’s always the right thing for the company”), se fate la cosa giusta per gli stakeholder, allora state facendo la cosa giusta per il vostro progetto.