Processi decisionali collaborativi
Quello che segue è un estratto del talk che terrò al Codemotion di Roma di come ideato ed extrategy siano diventate Flowing.
Nello specifico in questo articolo spiegherò di come abbiamo impostato, in Open Governance, un framework per aiutarci nei processi decisionali [1] identificando, sulla nostra esperienza, tool diversi in base al tipo di feedback necessario.
Prima però dobbiamo spiegare cosa sono i processi decisionali collaborativi e perché è utile, se non indispensabile, avere uno strumento di allineamento all’interno dell’azienda per decidere quale usare e quando.
Perché Open Governance
In questo momento storico, una organizzazione che vuole fare business e prosperare deve fare i conti con un contesto in continua evoluzione, se fino al secolo scorso la vita media di un’azienda era di 67 anni negli ultimi 80 anni è calata drasticamente fino ad arrivare all’attuale media di 15 anni [2].
Questo aumento della velocità e di complessità, affiancate alla necessità continua di sperimentare nuovi modelli economici (soprattutto nel mondo del knowledge working) hanno reso necessario rivedere e valutare nuovi approcci alla gestione delle organizzazioni; non è più consentito alle aziende di concedersi un modello decisionale dove “chi pensa” non solo è gerarchicamente diviso da “chi fa”, ma anche quest’ultimo è lontano (se non all’oscuro) dalle motivazioni dietro al “perché” debba essere fatto. Insomma, un circolo vizioso dove: ci sono cose che vengono fatte su presupposti sbagliati ed implementate erroneamente perché non se ne conoscono motivazioni e obiettivi da raggiungere.
Una Governance Aperta è più che una azienda senza manager, è un modo radicalmente diverso di approcciarsi alla gestione di una azienda. Per ottenere questo l’organizzazione deve uscire da schemi prefissati, modificarsi, ed evolversi creando quando necessario dinamiche e principi che la rendano adattiva.
Gli esempi di Governance Aperta sono diversi ed ognuno a diversi livelli di implementazione (e risultato), da Zappos a Spotify, da Valve a Medium.
Nel nostro caso specifico abbiamo adottato una Governance Aperta perché:
- Decentralizza il processo decisionale, e migliora la capacità di reazione ed evoluzione dell’organizzazione
- Permette alle leadership di emergere in base alle competenze (soft ed hard), ed al suo valore riconosciuto dal sistema (in contrapposizione a leader nominati ma non riconosciuti)
- Permette all’organizzazione di prendere le migliori decisioni possibili coinvolgendo, in ogni decisione, le migliori persone che il gruppo ha a disposizione (le più interessate, le più competenti, le più coinvolte, quelle con le informazioni di contesto migliori).
- Abilita le persone a prendere decisioni, che è una competenza che va creata e costantemente allenata.
In un contesto di questo genere avere un framework decisionale comune e condiviso è quindi necessario per migliorare la qualità delle decisioni, evitare le decisioni nate da mancanza di leadership (emergente), dall’eccesso di ego o dalla poca attenzione alle competenze rispetto al venirsi incontro per essere d’accordo.
Come cita uno dei principi della governance di Medium
Good decision-making implies alignment, not consensus.
Una attività di governance per migliorare la governance
La prima stesura del lavoro svolto in Open Governance ha cercato di mappare gli strumenti decisionali attualmente utilizzati in Flowing, la loro efficacia in base al numero di persone coinvolte nella decisione e la loro profondità e velocità di utilizzo. Lo scopo dell’attività è stato quello di fornire un aiuto nella scelta dello strumento di decisione da utilizzare, basando la scelta su 3 parametri: impatto della decisione, tempo a disposizione e numero di persone coinvolte.
Ogni strumento utile ai processi decisionali all’interno di questo documento è considerato valido, se applicato nel giusto contesto.
Descrizione criteri di valutazione
Abbiamo dato una valutazione ad ogni strumento, su tre criteri:
- Velocità
- Impatto
- Persone
Per ogni criterio abbiamo utilizzato una scala da 1 a 10.
Valutare gli strumenti secondo parametri così precisi è ovviamente impossibile, quindi il valore è da considerarsi un’indicazione. Per limitare l’errore e avere un posizionamento migliore nel grafico abbiamo cercato di fare in modo che i dati fossero coerenti in relazione tra loro più che come valori assoluti (ad es. non è importante che, in termini assoluti, dot voting abbia impatto 2 o 3, ma che la sua scelta sia fatta per attività con un impatto minore ad esempio di QuEST).
Velocità
Indica la velocità con la quale lo strumento consente di prendere una decisione.
E’ importante fin da subito avere la consapevolezza di cosa significhi impiegare del tempo per prendere una decisione.
Sto operando a cuore aperto una persona (o un sistema business critical)? Probabilmente non posso aspettare mesi per fare una azione, ma dovrò muovermi in base alle competenze accumulate negli anni. Allo stesso modo posso decidere di rallentare una decisione fino a quando avrò abbastanza informazioni necessarie prima di poterla prendere serenamente.
La velocità decisionale è fortemente veicolata dall’istinto, dalla capacità di accettare/assorbire i rischi e dalla competenza sul campo. Una summa di fattori che possono essere riassunti come i Guts (la Pancia) del mondo anglosassone.
Questo significa anche che se si è vittima, soprattutto sul fronte della confidenza, dell’effetto Dunning-Kruger si tenderà ad avere una velocità decisionale troppo alta (cit. vado in ira e carico) o poco efficiente.
Eticamente parlando se bisogna decidere velocemente cercate di farlo quando i primi a risponderne siete voi, o quando il rischio è relativamente basso.
L’unità di Misura della velocità è una scala da 1 a 10 dove 1 indica che lo strumento richiede un tempo nell’ordine dei mesi, 10 indica l’ordine dei minuti.
Impatto
Indica l’impatto massimo della decisione che stiamo prendendo all’interno del suo contesto. La definizione di impatto è molto soggettiva e limitata al singolo caso messo in discussione.
Proprio perché ordinare la pizza sbagliata non ha lo stesso impatto di vendere un ramo d’azienda, ma entrambe sono scelte che lasciano il segno, gli strumenti decisionali a disposizione cambiano e forzano a ragionare (e raccogliere informazioni) in modo differente.
Se la velocità serve per capire il time frame in cui prendere la decisione, l’impatto definisce l’ampiezza (e le ripercussioni) che questa avrà all’interno del contesto di appartenenza.
Per spiegare meglio questo concetto valutiamo l’impatto di scegliere un software per un team di due persone piuttosto che cambiarlo, magari insieme al processo produttivo, per 50 sviluppatori . Stesso problema (cambiare il software), impatti decisamente diversi e strumenti decisionali utilizzati con profondità differenti.
Come per la velocità anche l’impatto si misura su una scala da 1 a 10 dove 1 indica un impatto quasi nullo, 10 rappresenta vita o morte.
Persone
Indica il numero di persone massimo che è possibile, o consigliabile, coinvolgere nel processo decisionale, tramite lo strumento selezionato.
Il tema delle persone è stato molto discusso e delicato in quanto i possibili risvolti alla partecipazione di massa sono:
- più persone = maggiore partecipazione = più punti di vista =bene
- più persone = complessivamente meno focus = rischio di bullshit asymmetry principle = male
Inoltre il tranello di uno vale uno e una testa un voto sono sempre alle porte soprattutto quando il contesto richiede focus e competenza mentre il team vuole solo prendere una decisione in fretta.
Citando due dei punti core di Liquid0 (il framework di Open Governance che abbiamo adottato)
We believe in the innovation processes that are aimed at sustainably improving the quality of life and the diffusion of a culture of respect, knowledge, experience and support.
ed ancora
We recognize the value of competencies and results far above titles and hierarchies.
Coinvolgere più persone è quindi importante per avere più punti di vista, avere più allineamento, far emergere più rapidamente possibili problemi e/o incomprensioni ma deve essere supportato da un forte senso di rispetto per le competenze sul dominio trattato e sul comprendere che non tutti i coinvolti possono avere la stessa importanza, a prescindere dal titolo o dal ruolo, al fine della decisione. Inoltre con il giusto strumento decisionale si rompe l’equazione più persone === più tempo per prendere la decisione.
Anche qui la scala è espressa su una base 10 ed 1 indica una sola persona, 10 indica tutti (nel contesto di Flowing questo vuol dire ~50 persone).
È importante precisare che se uno strumento ha ricevuto un 10 non vuol dire che può essere usato solo con tante persone, ma che il coinvolgimento di tante persone è possibile (cioé l’efficacia dello strumento non collassa all’aumentare delle persone) o auspicabile.
Il gioco delle leve
Come avviene in altri contesti i tre parametri sono correlati e difficilmente si potrà avere qualcosa che necessita di grande velocità decisionale, tante persone coinvolte ed avrà un impatto critico per tutto il sistema [3].
Qui di seguito una serie di interpretazioni che abbiamo dato agli strumenti decisionali selezionati durante l’attività di Open Governance.
Prendiamo l’esempio dell’Event Storming, per definizione sono necessarie tutte le persone coinvolte nel processo, l’attività può durare anche alcuni giorni per rappresentare al meglio lo stato dell’arte ed il risultato non ha un impatto diretto su quanto sta rappresentando (essendo appunto la rappresentazione di un flusso).
Al contrario se vogliamo avere un impatto forte per validare un’idea non c’è nulla di meglio di un piccolo team di persone che implementano in cicli rapidissimi degli MVP.
Gli strumenti utili ai processi decisionali
Qui di seguito, in modo sparso e per niente puntuale una lista tra gli stumenti che, in fase di stesura dell’attività di governance [4], abbiamo ritenuto utili ai processi decisionali che sono, o sono stati usati, nei nostri processi di governance. Quando parliamo di strumenti utili ai processi decisionali significa che gli stessi abilitano determinate domande, analisi, ricerca di informazioni o anche semplicemente dialogo tra le parti e che danno, in modo diversi, contributo al processo decisionale interno.
Il loro posizionamento nel grafico nasce da un sondaggio interno, rifinito poi nel tempo in base ad ulteriore esperienza sul campo.
Dot Voting
Planning poker, etc. strumenti di voto condiviso ma sincrono. Serve a prendere decisioni veloci e democratiche, innescando se serve discussione sulle posizioni diametralmente opposte.
Qu.E.S.T.
- Question. Definizione del perimetro dell’intervento (c.d. “problema”) e raccolta interna ed esterna di una mole di dati sufficiente a valutarne le implicazioni e opportunità.
- Envision. Nell’envision si offrono “porzioni” di soluzione/decisione. L’intento dell’envision è divergere e generare il più alto numero possibile di idee. Nell’envision la quantità conta più della qualità delle idee proposte perché anche proporre approccio che non ci piacciono può innescare ragionamenti che portano, per opposizione a definire proposte che invece ci soddisfano molto.
- Select. Si definiscono i criteri per selezionare le “parti” di soluzione proposte nell’envision. Quali criteri vogliamo usare per selezionare cose proposte nell’envision? preferiamo soluzioni che … ? Preferiamo soluzione che non ? etc
- Take. Le proposte dell’envision, filtrate dai parametri del select vanno a comporre la decisione finale, che a quel punto è unica, organica e composta dal punto di vista di tutti i pezzi di envision che hanno passato il filtro.
Strumento, asincrono, per raccogliere una serie di informazioni su un periodo di tempo medio lungo e per andare a fondo nei dettagli. Maggiori dettagli qui: http://nilofermerchant.com/books/the-new-how/
Event Storming
Strumento che necessita “tutte le persone corrette nello stesso spazio” per far emergere informazioni utili a come processi funzionano (o dovrebbero funzionare). Di solito utilizzato per mappare un flusso lungo una timeline. Maggiori informazioni qui: http://www.eventstorming.com
Architectural Clash
La caratteristica principale di Architectural Clash è quella di far prendere decisioni strategiche condivise tra il team tecnico ed il management, e di rendere chiaro da subito quali sono i punti critici da risolvere nel software esistente. Lo scopo di questa prima fase è quella di allineare tutto il team sugli obiettivi di business che guideranno lo sviluppo. Da questi obiettivi si estraggono degli esperimenti che serviranno per la parte successiva del workshop. Il principio che ci guida durante la prima fase è “Start with Why”, chiarire i “perché” (obiettivi aziendali) prima di decidere su cosa e come lavorare. Mentre il principio della seconda è “Learn by Doing”, questo lavoro “hands-on” ci permette di quanto le strade che ipotizziamo sono percorribili o no.
Maggiori informazioni: https://medium.com/@TheStrazz86/architectural-clash-1baa6dc1e09d
Open Space Technology
Strumento sincrono per aprire e gestire tavoli di discussione. Maggiori approfondimenti qui: https://openspaceworld.com/brief_history.htm
Pro e Contro
Nell’ottica del Cynefin viene usato per scelte nell’ambito del “Banale” (o al massimo Complicato) SENSE-CATEGORIZE-RESPOND. Funziona sia in sincrono che in asincrono.
Dado
Nell’ottica del Cynefin viene usato per scelte nell’ambito del CAOS dove non anche se ho informazioni non mi permettono di prendere scelte consapevoli. Mi affido al caso ACT-SENSE-RESPOND
Hearing/Consulenza
Chiedo alle persone che hanno avuto esperienza diretta. E’ asincrona (in quanto aspetto di ricevere risposta)
MVP
Costruisco un prototipo per raccogliere le informazioni utili ad analizzare la situazione e rispondere di conseguenza.
Comparazione
Comparo con MIE (o del gruppo) esperienze dirette.
PUP
Procrastinate Until Possible, non c’è urgenza di avere feedback e posso permettermi il fatto di vedere che succede non facendo nulla.
Popcornflow
esperimenti in ambiente controllato. L’MVP può essere una sorta di esperimento, ma abbiamo voluto tenere separate le due cose per la natura degli esperimenti di popcornflow, più piccoli e veloci. Maggiori informazioni qui: https://popcornflow.com/
Guts/Ci provo
(sul mio bagaglio di competenza) vado dritto al punto (e spero di non schiantarmi)
Five whys
O genericamente altre forme di root cause analysis, tecnica per risalire alla causa di un evento chiedendosi “perché” iterativamente fino ad arrivare alla “root cause”. Es:
L’auto non parte, (il problema)
- Perché — La batteria è scarica (primo perché)
- Perché — L’alternatore non sta funzionando (secondo perché)
- Perché — La cinghia dell’alternatore si è rotta (terzo perché)
- Perché — La cinghia dell’alternatore non è mai stata sostituita, sebbene l’auto avesse percorso molti chilometri (quarto perché)
- Perché — Non è stata effettuata la manutenzione programmata (quinto perché, la radice del problema).
5 whys deriva dal fatto che empiricamente dopo 5 perchè si riesce solitamente a risalire alla causa, ma non c’è l’obbligo di attenersi a quel numero. Maggiori approfondimenti qui: https://kanbanize.com/lean-management/improvement/5-whys-analysis-tool/
Fishbone
Versione evoluta dei five whys (nel grafico li riportiamo insieme perché hanno le stesse caratteristiche), anche questo utilizzato per risalire alle cause di un evento/problema. Partendo dal problema si va a ritroso identificando le possibili cause (e non solo una come nei 5 whys). Ogni causa viene poi analizzata a sua volta. Per tenere traccia di questo processo di costruisce un diagramma a spina di pesce (fishbone diagram). Esempio di fishbone http://fishbonediagram.org/example-2-delays-in-custom-order-shipments/
Fishbowl
Ci si divide in due gruppi: il primo discute, il secondo ascolta e prendere appunti. Allo scadere di un timebox i ruoli si invertono. Particolarmente utile per far partecipare tutti alla discussione ed avere modo di vedere dall’esterno alcune dinamiche.
Es: https://www.facinghistory.org/resource-library/teaching-strategies/fishbowl
LSP
Lego Serious Play, tecnica sincrona di facilitazione 100/100 delle riunioni. Ideale per allineare desiderata, aspettative e visioni. Un altra caratteristica è quella dello “story making” cioè quando sia necessario inventare (creare/costruire) una soluzione nuova (fuori dall’ordinario) ad un problema complesso.
Maggiori informazioni qui: https://www.lego.com/en-us/seriousplay/the-method
Sondaggio
Il sondaggio è uno strumento asincrono per valutare possibili soluzioni e votarle. Eventualmente può essere visto come un primo punto di partenza per decidere che temi approfondire o meno.
Note
[1] La definizione di un framework per la selezione di processi decisionali condiviso, nata essa stessa come processo condiviso porta ad interessanti risvolti. Il primo tra i quali è che il framework è soggettivo e perfettibile, quindi non prendete tutto come la verità imposta dall’alto ma come uno strumento nato come base di partenza e che evolverà man mano che nuove tecniche di analisi, consapevolezza e competenza sulle stesse, verranno fatte proprie dall’azienda e dagli individui. Il secondo è che se avete da darmi(/ci) spunti per migliorarci siete i benvenuti.
[2] maggiori informazioni qui: https://www.innosight.com/wp-content/uploads/2016/08/Corporate-Longevity-2016-Final.pdf
[3] E’ una semplificazione, perché la popolazione votante con pochi secondi di effort personale può cambiare (anche in peggio) le sorti di un paese.
[4] Nel tempo sono emersi nuovi strumenti come Architectural Clash e Capacity Canvas, ma per un motivo o per l’altro non abbiamo mai aggiornato il grafico.
