Cynefin: un framework per aiutare il processo decisionale negli ambienti complessi

Cynefin: un framework per aiutare il processo decisionale negli ambienti complessi

Cynefin (cu-NE-vin) è una parola gallese che in Inglese si traduce letteralmente come haunt o habitat (habitat anche in Italiano) ma che in realtà significa molto più di queste semplici parole. Il Framewrok Cynefin è stato creato da Dave Snowden di Cognitive Edge come uno strumento per aiutare il processo decisionale negli ambienti sociali complessi.
Una delle ragioni per cui Snowden ha scelto un nome così inusuale per il suo framework è stata semplicemente che “Un nome che richiede una storia per spiegare il suo significato evita la confusione o l’associazione con concetti già esistenti”.
Il framework parte con tre tipi di sistema: ordinato, complesso e caotico. Il sistema ordinato è diviso in due aree chiamate semplice e complicata, per un totale quindi di quattro sistemi. L’obiettivo del framework è di aiutarti a capire con quale dei quattro domini hai a che fare. Perciò c’è un quinto dominio chiamato ‘disordine’ che rappresenta semplicemente lo stato in cui non si sa quale degli altri quattro domini si applichi alla propria situazione.
Il framework Cynefin è importante per i progetti, programmi e portfolio perché l’approccio di Project, Programme e Portfolio Management deve essere adattato al contesto del lavoro. Fattori quali la complessità e l’incertezza devono essere capiti prima di decidere se gestire un lavoro come un progetto o un programma, o magari per decidere se siano o meno pertinenti approcci iterativi (come Agile).

Cliccare su una delle cinque etichette per andare direttamente alla descrizione corrispondente.

Disordine

Questo è il punto di partenza in cui non sai quale dei quattro domini sia quello pertinente. Le quattro descrizioni seguenti dovrebbero essere studiate per aiutare a collocare il lavoro che si sta per intraprendere. Questo aiuta, ad esempio, a identificare il requisito nel processo di identificazione del modello dei processi di Praxis, per decidere se gestire il lavoro come un progetto o un programma.
Bisogna fare attenzione perché le persone tendono a valutare la situazione in base al loro modo preferito di lavorare.

Semplice

Nel dominio semplice vi sono relazioni causa ed effetto che sono prevedibili e ripetibili. Esse sono evidenti a qualsiasi persona ragionevole. Nell’ambiente del Project, Programme e Portfolio Management è ragionevole presumere che “qualsiasi persona ragionevole” rappresenti qualcuno con una comprensione tecnica di ciò che implica il lavoro.
Ad esempio, in un contesto edilizio, un progetto semplice può comportare la costruzione di una casa, soprattutto se il team di progetto ha già costruito molte di queste case. Ci saranno differenze ogni volta che ne costruisce una, ma le relazioni di causa ed effetto sono ben chiare. Allo stesso modo, in un ambiente IT, un nuovo sito web può seguire un formato collaudato e affidabile che ha modelli consolidati ma contenuti diversi ogni volta.
In questo ambito l’approccio è quello di percepire-categorizzare-rispondere, cioè capire quali sono le differenze per questo progetto, classificarle e rispondere a tali differenze. Snowden sostiene che questo è l’unico dominio in cui è pertinente il concetto di “best practice”.
Le persone che trascorrono molto tempo in questo ambito probabilmente vedranno qualsiasi errore del progetto come un “fallimento del processo”.

Complicato

Nel dominio complicato ci sono ancora le relazioni causa-effetto ma non sono evidenti e richiedono competenze per analizzarle. Un esempio potrebbe essere la costruzione di un ponte. Sebbene il team possa aver costruito molti ponti prima, ogni ponte attraversa un fiume o una strada diversi; il traffico che deve trasportare e il tempo o le condizioni geologiche a cui deve resistere sono diversi. Gli ingegneri strutturali specializzati analizzeranno il contesto specifico e prepareranno i progetti.
L’approccio qui è percepire-analizzare-rispondere e la gestione del progetto sarà considerata come “buona pratica” piuttosto che come “migliore pratica” (best practice).
Le persone che trascorrono molto tempo in questo ambito probabilmente vedranno l’insuccesso del progetto come causato dalla presenza di insufficienti informazioni su cui basare l’analisi.

Complesso

Lavorare in questo dominio ha cause ed effetti che sono imprevedibili e che appaiono ovvi solo a posteriori. In questa categoria rientreranno i programmi di cambiamento di business così come molti progetti / programmi IT. Ciò è dovuto in gran parte al fatto che esistono molteplici relazioni con gli stakeholder, con opinioni e requisiti che emergono nel tempo.
L’approccio qui è quello di sondare-percepire-rispondere, cioè si dovrà sperimentare e testare per capire lo scopo dettagliato del lavoro.
La comunità del Project, Programme e Portfolio Management di solito risponde a questo dominio con lo sviluppo iterativo e con team multidisciplinari strettamente integrati. “Concurrent Engineering” e “Agile” sono due esempi. Maggiore è la complessità, maggiore è l’elasticità richiesta al team di gestione per rispondere ai risultati dell’indagine e della sperimentazione.

Caotico

Snowden afferma che nei sistemi caotici non è possibile stabilire relazioni di causa ed effetto. Questa affermazione sembra un po’ estrema, dato che persino sistemi caotici come il meteo possono essere previsti in una certa misura, anche se ciò richiede una notevole raccolta di dati e un’enorme potenza di calcolo solo per una previsione di appena un paio di giorni: quindi forse nell’ambiente del Project, Programme e Portfolio Management l’affermazione è vera a tutti gli effetti.
Il dominio caotico dovrebbe essere introdotto deliberatamente solo per ragioni di innovazione e chiaramente ciò richiederà una notevole propensione al rischio. I progetti caotici dovrebbero essere concepiti in modo consapevole solo laddove ci potrebbe essere molto da guadagnare, forse quando si è i primi a vendere in un nuovo settore in rapida evoluzione, oppure come risposta a una crisi, come il caso di un reattore nucleare che si fonde.
L’approccio qui sarà agire-percepire-rispondere.
C’è un altro modo in cui un progetto potrebbe diventare caotico. I confini tra i domini possono in genere essere oltrepassati, ad esempio quando, una volta eseguita l’analisi, il lavoro passa da complicato a semplice o da complicato a complesso.


Ma c’è un confine che è diverso dagli altri. Quello tra semplice e caotico è spesso rappresentato come un dirupo. Se la diagnosi nella fase del disordine è sbagliata e il lavoro viene considerato semplice quando non lo è, oppure il lavoro diventa più complicato e il team di gestione non risponde, il progetto potrebbe entrare nella ‘zona compiacente’. La governance del progetto si rivela totalmente inadeguata e precipita giù dal dirupo nel caos(1).

Lo Staff di PME

 

(1) Il presente articolo è la traduzione in italiano da noi curata per il sito www.praxisframework.org.
L’articolo originale in inglese è consultabile al seguente link. La versione italiana qui riprodotta è reperibile anche nella sezione in italiano del sito praxisframework.org/library al seguente link. Il titolo attribuito in questo blog è una nostra elaborazione.

0 Commenti

Leave a reply

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

*