Un'organizzazione di grandi dimensioni ha raramente una sola relazione con un solo stakeholder. Un comune ha in corso un percorso di autorizzazione, una richiesta di sussidio, e una linea informale con un assessore su un dossier futuro. Tre team di progetto, uno stakeholder. La domanda su chi ne sia proprietario di solito non viene posta finché qualcosa non va storto: l'assessore riceve due versioni diverse della stessa storia, oppure un impegno preso in un progetto non viene riconosciuto in un altro.
In un'organizzazione a matrice la struttura dei progetti è di solito chiara, ma la struttura delle relazioni no. Ogni progetto ha un capoprogetto, e quel capoprogetto spesso si comporta come se la relazione con lo stakeholder appartenesse al progetto. Nel momento in cui il progetto si conclude, la relazione scompare con esso, anche se lo stakeholder resta. Questo è il primo errore: una relazione viene trattata come componente di progetto invece che come qualcosa che esiste indipendentemente dal progetto.
Il secondo errore è l'opposto: nessuno diventa proprietario perché tutti presumono che qualcun altro se ne stia già occupando. Ciò accade soprattutto con gli stakeholder che presentano un punteggio elevato sia in influenza che in impatto contemporaneamente, esattamente i casi in cui il coordinamento è più necessario. Come si arriva a quel punteggio è descritto nelle pagine su come stimare l'influenza di uno stakeholder e come determinare quanto sia impattato uno stakeholder. La matrice che ne deriva è illustrata su la pagina che spiega cos'è una matrice influenza-impatto.
È naturale voler collegare la titolarità alla seniority: la funzione più alta presente nella stanza diventa proprietaria. Non funziona, perché la seniority non dice nulla su chi abbia il contatto più strutturale. Un manager operativo che ha contatti settimanali con un residente locale sa più su quella relazione di un direttore che le parla due volte l'anno. La titolarità segue la relazione, non la funzione.
Quello che funziona è collegare la titolarità alla domanda su chi sia responsabile degli impegni presi con quello stakeholder. Chi prende impegni senza poterli monitorare non è un proprietario ma un rischio. Come un impegno viene concretamente messo per iscritto, compreso chi, cosa e quando, è descritto su la pagina sulla registrazione di un impegno. Senza quella registrazione, la domanda su chi sia proprietario resta soprattutto teorica, perché non c'è nulla su cui fare riferimento.
La soluzione pratica non è complicata: una persona diventa proprietaria della relazione, indipendentemente da quale progetto sia in corso. Quella persona non deve essere coinvolta in ogni progetto, ma deve sapere cosa è stato detto a nome dell'organizzazione a quello stakeholder, in qualsiasi progetto. Questo richiede un registro separato dall'amministrazione di progetto: un luogo dove finisce ogni impegno preso con quello stakeholder, indipendentemente da chi lo ha fatto.
Quel registro è esattamente ciò di cui tratta la pagina sulla titolarità di una relazione: non come principio organizzativo in senso astratto, ma come domanda su chi mantenga la visione d'insieme non appena sono in corso più progetti contemporaneamente. Senza aver risposto a quella domanda, si crea lo scenario in cui l'assessore, il residente o il giornalista sente tre versioni diverse della stessa organizzazione, non perché qualcuno menta, ma perché nessuno vede l'insieme.
Un progetto ha una data di fine. Un impegno non sempre. Un impegno a fornire un aggiornamento entro sei mesi continua a decorrere anche dopo che il progetto in cui quell'impegno è stato preso si è già concluso e il team è stato sciolto. Senza un proprietario della relazione non c'è più nessuno che veda arrivare quella scadenza. Chi monitora tali scadenze nell'organizzazione, e come si evita che un impegno decada tacitamente, è descritto su la pagina sul monitoraggio di una scadenza. È esattamente questo il motivo per cui un piccolo impegno non rispettato costa spesso più fiducia della mancanza di un grande investimento: il piccolo impegno era concreto e verificabile, il grande investimento non ha mai avuto una data precisa.
Tenere traccia di chi è proprietario di cosa, quale impegno appartiene a quale stakeholder e quale scadenza è ancora in corso, è in gran parte lavoro amministrativo: raccogliere segnali, collegarli a un dossier, impostare un promemoria. È un lavoro di precisione, ma non necessariamente un lavoro che deve essere svolto da un collaboratore senior scarsamente disponibile. Chi vuole sapere quale parte di questo tipo di compiti può essere ripresa dall'IA e quale parte no, può farlo calcolare con lo scan del lavoro di FTE TO AI, che indica per ciascun compito dove l'automazione si applica e dove no.
Vraag maar. Het interessantste antwoord komt meestal van wie u nog niet heeft gesproken.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.