Chi ti ha chiamato non è sempre chi decide

Prima di disegnare la soluzione, distingui sponsor, requester e rumor: eviterai di scambiare urgenza e visibilità per un vero mandato.

Obiettivo

Nominare sponsor, requester e rumor, e non trattare la richiesta più rumorosa come mandato.

practice

Nomina i ruoli prima della soluzione

Quando vieni coinvolto, non assumere che la persona con il ticket, il budget preliminare o la maggiore presenza nelle riunioni abbia anche il mandatoGlossarioMandatoL'autorizzazione esplicita a occuparti di un risultato, con confini su cosa puoi decidere e cosa puoi solo rendere visibile.Apri la voce completa. Prima di disegnare, scrivi tre nomi: SponsorGlossarioSponsorChi può sostenere o fermare il lavoro perché ne porta il rischio o il risultato, distinto da chi ha solo aperto la richiesta.Apri la voce completa, cioè chi può dire sì, cambiare priorità o fermare il lavoro; requester, cioè chi ha formulato o aperto la richiesta; rumor, cioè chi esercita pressione senza possedere necessariamente il rischio o la decisione. La stessa persona può coprire più ruoli, ma va verificato, non presunto. Chiedi inoltre chi risponde delle conseguenze su budget, rischio operativo, sicurezza e risultati di business. Se non sai chi potrebbe bloccare il lavoro venerdì, non hai ancora chiarito il mandato.

practice

Trasforma l'ambiguità in una domanda operativa

Porta la mappa dei ruoli nella prima conversazione utile e rendila verificabile: chi sponsorizza l'esito, chi rappresenta la richiesta, chi deve essere consultato e chi possiede la decisione finale? Formula la risposta in una frase breve, per esempio: il requester coordina l'iniziativa, ma lo sponsor approva l'esposizione al rischioGlossarioEsposizione al rischioUna vista contestuale della perdita potenziale che combina probabilità, impatto e tempo o ambito di esposizione.Apri la voce completa e il business owner accetta l'impatto operativo. Se manca lo sponsor, limita il lavoro a esplorazione e raccolta di evidenze; non presentare una direzione architetturale come già autorizzata.

trade-offs

Velocità apparente o mandato reale

Seguire subito chi ti ha reclutato è rapido, mantiene il ritmo del delivery e può sembrare collaborativo. Il prezzo è il rischio di ottimizzare per una voce influente ma priva dell'autorità necessaria, con rework e decisioni riaperte quando arrivano business, security o operations. Cercare lo sponsor richiede tempo, può rendere visibili conflitti organizzativi e rallentare l'avvio. In cambio chiarisce criteri, responsabilità e condizioni di stop. Non serve bloccare ogni analisi finché la governance è perfetta: puoi esplorare opzioni reversibili, ma devi distinguere esplicitamente l'esplorazione da una decisione impegnativa.

enterprise-example

Il ticket urgente per la nuova integrazione

In un'impresa assicurativa, il responsabile del delivery chiede con urgenza un'integrazione diretta tra il portale partner e il sistema sinistri. Il requester è il delivery lead; la voce più rumorosa è il responsabile commerciale, che promette una data ai partner; lo sponsor effettivo è la direttrice Operations, responsabile dei rischi sul processo sinistri. Il Solution Architect chiarisce i ruoli prima di confermare il disegno. Emerge che Security richiede un controllo centralizzato degli accessi e Operations non accetta dipendenze sincrone sul sistema core. L'opzione diretta sarebbe più veloce da consegnare, ma aumenta rischio operativo e accoppiamento. Con lo sponsor in stanza, il gruppo sceglie uno scambio asincrono con controlli di identità centralizzati e concorda una data diversa. Il punto non è che abbia vinto l'architettura più sofisticata: la decisione è stata presa da chi portava il rischio, con conseguenze e compromessi visibili.

references

Per approfondire

Fonti autorevoli per approfondire responsabilità, coinvolgimento degli stakeholderGlossarioStakeholderUna persona o un gruppo che influenza una decisione o ne sperimenta gli effetti.Apri la voce completa e chiarezza dei ruoli decisionali. • A Guide to the Project Management Body of Knowledge, sezione Stakeholder Performance Domain - Project Management Institute - https://www.pmi.org/pmbok-guide-standards/foundational/pmbok • The Open Group Architecture Framework, Stakeholder Management - The Open Group - https://pubs.opengroup.org/togaf-standard/adm-techniques/chap03.html

Da ricordare

Non confondere chi apre il lavoro con chi ne porta il rischio: nomina sponsor, requester e rumor prima di trattare una richiesta come mandato.

Per la prossima riunione

Come Solution Architect, so indicare chi può davvero approvare, cambiare o fermare questa decisione, oltre a chi ha aperto la richiesta?

Una domanda per te