La gestione degli stakeholder – prima parte: Chi sono?

da | Nov 14, 2019 | 0 commenti

In questo articolo iniziamo a vedere uno degli aspetti più importanti del project management: la gestione degli stakeholder.

Tra gli “attori” del progetto identificati con questa parola ci sono lo sponsor del progetto ed il committente che approva i deliverable, che sono considerati Key Stakeholder. È facile immaginare cosa succede se lo sponsor del progetto comincia ad avere un atteggiamento ostativo e se il committente che approva i deliverable presenta continuamente osservazioni su quanto consegnato: il progetto fallisce.

Questo accade indipendentemente dalla capacità delle persone che portano avanti il lavoro pianificato.

È quindi fondamentale capire chi sono gli stakeholder e come fare affinché abbiano un atteggiamento positivo e di supporto al progetto.

Il processo Identify Stakeholder che segue quello di sviluppo del Project Charter (con riferimento alla certificazione PMP®) fa parte dei processi che vengono eseguiti all’inizio. È importante capire chi sono e come devono essere gestiti gli stakeholder, ovvero, secondo quanto stabilito dall’ultima versione del PMBOK®, come deve essere gestito il loro coinvolgimento.

Il Processo Identify Stakeholder

Uno stakeholder può essere definito come un “attore” che ha un interesse (anche minimo) sul progetto. In inglese la traduzione è letteralmente “titolare di una posta di gioco”.

Esempi di stakeholder sono manager funzionali, fornitori, clienti, senior manager. Ma uno stakeholder è anche un membro del team di progetto nonché un’associazione di ambientalisti che ha interesse che il progetto porti dei risultati, se ad esempio il progetto riguarda una bonifica ambientale.

L’identificazione degli stakeholder può essere vista come un processo.

Nel processo distinguiamo gli input, gli strumenti che applichiamo agli input per ottenere dei risultati, ovvero gli output.

Input di processo

Cominciamo con elencare gli input per fare qualche breve osservazione:

  • Project Charter
  • Business Documents
  • Project Documents
  • Project Management Plan
  • Agreements
  • Enterprise Environmental factors
  • Organizational Process Assets

Il Project Charter giustificando l’investimento sul progetto e descrivendo i benefici attesi, ci aiuta a capire chi ha interesse nel progetto e, soprattutto, chi ne decide il successo (sponsor, committenti, responsabili di funzioni aziendali).

Gli agreement sono i contratti e accordi di diversa natura, anche verbali. Analizzandoli identifichiamo i contraenti, che rappresentano gli stakeholder di riferimento.

I Business Document sono documenti che descrivono come si realizza il business. Quali sono gli obiettivi, le priorità, gli strumenti che vengono messi in campo per ottenere i risultati attesi e quindi quali sono gli stakeholder che contribuiscono a sviluppare il business.

Il Project Management Plan è il piano generale di progetto. Definisce come vengono integrati i piani di gestione dei vari aspetti del progetto. Integra quindi il piano di gestione dei costi con il piano di gestione dei rischi, della schedulazione, della comunicazione e così via.

Fa riferimento ad ognuno di questi piani, compreso il piano di gestione del coinvolgimento degli stakeholder. Quest’ultimo definisce come mantenere il supporto degli stakeholder verso il progetto, analizzando le aspettative, i bisogni e gli interessi. Considerando l’impatto che ha la loro influenza sugli obiettivi.

I fattori ambientali (Enterprise Environmental Factors), sono fattori che influenzano il progetto ma non sono governabili dal progetto (standard industriali, elementi normativi, contesto di business).

Gli Organizational Process Assets contengono le informazioni storiche sugli stakeholder che sono intervenuti in progetti simili in passato. Informazioni che contribuiscono a formare la base di conoscenza aziendale, che rappresenta un vero e proprio asset.

Strumenti e tecniche

Gli strumenti che vengono applicati agli input sono:

  • Data Analysis
  • Data Gathering
  • Data Representation
  • Expert Judgment
  • Meetings

Il lavoro sui dati raccolti, la loro analisi e rappresentazione ci consente di iniziare a formare una lista degli stakeholder, identificando attitudini, predisposizioni, influenze, dati storici . Se non abbiamo abbastanza dati lavoreremo predisponendo questionari, organizzando riunioni con chi può darci ulteriori informazioni (Senior Manager, Consulenti, Clienti, Fornitori).

Output di processo

Arriveremo così ad ottenere l’output principale (non unico) del processo: lo stakeholder register

Nello stakeholder register identifichiamo ciascun stakeholder e soprattutto ne facciamo una classificazione (interno, esterno, di supporto, resistente, neutro) . In questo registro possiamo annotare informazioni quali:

  • sintesi posizioni dello stakeholder in progetti simili
  • aspettative disattese in passato
  • aspettative attese in questo progetto
  • atteggiamento mostrato verso il progetto
  • atteggiamento atteso verso il progetto
  • impatto sul progetto
  • azioni da intraprendere per ottenere l’atteggiamento atteso (inizialmente di alto livello poi specificate in dettaglio in seguito nel progetto)
  • influenza sugli altri stakeholder
  • key stakeholder (si/no – motivazioni)
  • influenzabile dai seguenti stakeholder/manager/altro
  • linea guida di gestione dello stakeholder

È importante sottolineare che questo è un documento “vivo” nel progetto. Cambia continuamente, cambiano gli stakeholder, cambiano gli equilibri in gioco, i comportamenti, gli interessi e così via.

Il coinvolgimento degli stakeholder in AGILE

Molte considerazioni che abbiamo visto valgono anche per AGILE; con riferimento alla certificazione PMI-ACP®, c’è però una fondamentale differenza:

In Agile il Cliente, principale key stakeholder, ovvero il suo “portavoce” il Product Owner, è quotidianamente a contatto con il Team di progetto.

È questa figura professionale a stabilire cosa è di maggiore interesse o meglio di maggior valore per il Cliente e quindi deve essere sviluppato con priorità. Ciò che deve essere prodotto nella prossima iterazione o Sprint viene elencato nel Product Backlog, e la priorità è fissata esclusivamente dal Product Owner (PO).

Il Team, se incontra difficoltà o necessita della collaborazione del PO, può contattarlo direttamente e quotidianamente. La squadra è unica. Il cambiamento, che secondo quanto indicato dalla metodologia classica, deve essere approvato formalmente attraverso un processo specifico (Integrated Change Control), in agile invece è accettato ed è normale introdurre delle variazioni a quanto pianificato. Proprio perché occorre mantenere alta la produzione di “valore” per il Cliente, e, quindi, il suo coinvolgimento è assicurato.

La gestione degli stakeholder ostativi

Uno stakeholder può essere di ostacolo al progetto in modo dichiarato o anche non dichiarato.

Ad esempio, potrebbe di proposito avanzare continuamente dei change request. Oppure apparentemente supportare il progetto per poi avanzare osservazioni su quanto consegnato affermando che non rispetta le attese, anche se conforme alle specifiche definite.

In presenza di attori così negativi non bisogna rinunciare a cercare di gestire il loro coinvolgimento, l’errore più comune è ignorarli: in tal modo non cambieranno mai il loro atteggiamento nei confronti del progetto.

Tra le azioni che vengono svolte nei confronti degli stakeholder negativi c’è sicuramente la condivisione degli obiettivi del progetto, cercare di dimostrare come il progetto può essere utile al loro lavoro, alla loro posizione aziendale. Comunicare apertamente che non è una minaccia al loro ruolo aziendale, che anzi può essere maggiormente rafforzato una volta che i risultati del progetto verranno tradotti in on going operation. La comunicazione aperta e leale nonché la condivisione degli obiettivi sono elementi chiave per coinvolgere gli stakeholder. Unitamente ad un approfondimento di quello che possono essere i lori interessi e di come il progetto possa supportarli, può condurre ad ottenere risultati inizialmente inaspettati.

Una volta identificati gli stakeholder e classificati nello stakeholder register vanno gestiti, va gestito il loro coinvolgimento. Il management dello stakeholder engagement avviene continuamente durante tutto lo svolgimento del progetto, ed ha diversi processi specifici.

Ma di questo vi parlerò in un altro articolo.

Alla prossima!

About Francesco Liguori
Francesco Liguori, professionista con esperienza pluriennale nella gestione di progetti complessi ed in possesso di diverse credenziali nell'ambito del project management, del service design e sicurezza delle informazioni (PMP®, PRINCE2®, SCRUM®, ITIL®, ISO/IEC 27001), ha fondato nel 2015 PM facile. In qualità di ATP Instructor del PMI, ha curato la progettazione dei corsi di preparazione agli esami di certificazione PMP®, CAPM® e PMI-ACP®. È inoltre CEO di BE Innovazione (www.beinnovazione.com), innovation company che migliora il posizionamento competitivo delle aziende clienti con progetti di trasformazione digitale.

0 commenti

Invia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.