Il prodotto secondo gli stakeholders e l’importanza dello scope management

La definizione dello scope, vale a dire dell’ambito di un progetto (ad esempio, le caratteristiche di un prodotto), è una fase molto delicata del project management. Tuttavia è spesso sottovalutata e finisce per mettere a repentaglio tutto il project management.

Nello scope management, il PM dovrà poter contare su raffinate doti di progettazione, previsione e, non ultima, di diplomazia. Infatti, per la definizione dello scope si dovrà trovare il giusto compromesso tra tutti gli attori in gioco nel progetto: gli stakeholders. Sarà la loro soddisfazione, infatti, a decretare il successo del progetto.

In caso contrario, durante la riunione di fine progetto, ci si troverà a dover giustificare al cliente l’assenza di funzionalità che non erano neanche state vagliate in fase progettuale.

Il primo passo nella definizione dello scope: l’individuazione degli stakeholders

Avere ben presente chi è coinvolto nel progetto e a chi sarà utile il suo output è fondamentale per progettare, fin dalla fase di stima, il prodotto finale e per definirne i contorni. Tempi, costi e qualità sono in funzione di questa stima.

Il secondo passo: mediare le esigenze e trovare il giusto ambito

Nella seconda fase, il project manager dovrà mettere in campo tutte le sue doti di stratega, comunicatore e diplomatico, per mettere d’accordo tutti gli stakeholders in grado d’influenzare il buon esito del progetto. L’alternativa è il caos, l’inefficienza del progetto.

Perché i desiderata rispetto allo scope sono spesso differenti e in contrasto tra i vari stakeholders.

Conflitto d’interessi: il prodotto secondo gli stakeholders

Facciamo l’ipotesi di un progetto di sviluppo di un software nel quale sono coinvolti quattro stakeholders:

Lo sponsor: il finanziatore del progetto, il manager dell’azienda commissionante;

Il tecnico: il referente dell’azienda commissionante che si occupa dell’aspetto tecnico del prodotto;

L’utente finale: chi dovrà utilizzare il prodotto;

L’azienda fornitrice: nella quale lavora il PM e della quale egli cura gli interessi.

Il prodotto secondo lo sponsor – Per lui il software ha funzionalità di base, un costo molto basso, ma è così bello che lascerà di stucco la direzione dell’azienda commissionante.

Il prodotto secondo il tecnico – Non ci sono dubbi, per lui il software è pienamente funzionale. Il budget per lui è questione veniale: le funzionalità le vuole tutte progettate nel minimo dettaglio, anche a costo di un prodotto inutilizzabile.

L’utente finale – Per lui il software è bello esteticamente, efficiente e gratis.

L’azienda fornitrice – Anche il datore di lavoro del PM vuole dire la sua sul prodotto: deve essere realizzato nella metà del tempo stimato al cliente, con un quarto delle risorse e deve essere pienamente soddisfacente per tutti gli stakeholders, in primis lo sponsor.

Proprio per la complessità dei vari interessi in gioco, è fondamentale che la definizione dello scope di progetto avvenga in modo chiaro per tutti e sia oggetto di un documento condiviso ad avvio del progetto.