1. Il cuore del problema: reti di interazioni (non “singoli fattori”)
Nei progetti complessi il rischio non nasce quasi mai da un singolo elemento. Nasce piuttosto da come fattori interni ed esterni si influenzano tra loro. Per questo l’unità di analisi non è il fattore isolato, ma la rete di interazioni: dipendenze tecniche e organizzative, flussi informativi, vincoli contrattuali, passaggi di consegna. È proprio lungo queste interfacce che un input può trasformarsi in ritardo, extra-costo o perdita di qualità.
I principali fattori che compongono e generano il successo o il fallimento di un progetto possono essere raggruppati in:
- stakeholder, sistemi sociali con agenda e capacità decisionale;
- fattori contestuali, come condizioni economiche, normative, tecnologiche e ambientali.
Gli eventi visibili del progetto sono esiti emergenti della loro interazione e non la semplice somma dei comportamenti dei singoli fattori.
Con non linearità e feedback, la stessa decisione può produrre esiti molto diversi a seconda di come il sistema la assorbe e reagisce.
2. Propagazione delle vulnerabilità: “fattore sano” + fattore con attributo
Un progetto si comporta “come previsto” solo finché il contesto reale resta vicino alle ipotesi su cui è stato impostato. Quando una condizione cambia oltre quei limiti, cambia anche il modo in cui i problemi si propagano nel sistema. Di conseguenza, cambiano anche gli esiti del progetto.
Chiamiamo attributo uno scostamento rilevante rispetto all’atteso, tale da modificare tempi, affidabilità o modalità di interazione di un fattore. La vulnerabilità nasce quando quel fattore opera con un attributo critico. Non è quindi un difetto astratto, ma una condizione concreta che altera il modo in cui il fattore si relaziona con gli altri.
Attributi come scarsità, ritardo, rigidità, conflitto e variabilità rendono fragili accoppiamenti altrimenti funzionali. Spesso il management reagisce aumentando controllo e coordinamento, ma così può generare ulteriori attese, errori e rework.
Il salto avviene nell’interazione: quando un fattore sano dipende da un fattore che porta un attributo critico, la relazione diventa un canale di trasmissione. Il fattore sano compensa, cambia priorità o carico operativo e può degradarsi a sua volta.
Se la leggiamo come una catena di eventi, una riga del Risk Register non descrive un episodio isolato. Descrive invece un insieme di interazioni critiche che, sommandosi, aumentano la probabilità di uno scostamento rispetto al piano.
3. Feedback e non linearità: quando il sistema cambia regime
Nei progetti ogni sollecitazione genera effetti che ritornano sul sistema: talvolta correggono e stabilizzano, talvolta amplificano e producono escalation. È qui che nasce la sensazione di perdita di controllo tipica dei contesti complessi.
I feedback negativi riportano il progetto verso un equilibrio; quelli positivi amplificano il problema: ritardo, urgenza, bypass dei controlli, errori, rework, backlog e nuovo ritardo. Il PM deve capire quali loop stanno stabilizzando il sistema e quali lo stanno spingendo verso l’escalation.
L’output non cresce proporzionalmente all’input. Finché la capacità regge, il progetto assorbe variabilità; superata una soglia di saturazione, con backlog o WIP eccessivo, il comportamento cambia regime. I ritardi moltiplicano gli effetti perché le correzioni arrivano quando il sistema è già mutato.
Quando cambiano normativa, mercato, stakeholder o supply chain, cambiano anche le interazioni rilevanti. Il PM non deve inseguire l’ultimo evento, ma capire quale catena sta guidando l’escalation in quel momento.
4. Renderlo visibile (e misurabile): dal Risk Register ai sensori
Se il rischio è un fenomeno di rete, la domanda non è solo quali rischi abbiamo elencato, ma quali interazioni stanno creando le condizioni perché si manifestino. Rendere visibile questa dinamica significa passare dagli eventi alle catene, alle connessioni e a pochi indicatori anticipatori.
Una riga di Risk Register, letta in chiave sistemica, diventa una catena di seed event: cosa deve accadere, passo dopo passo, perché il rischio produca impatto. Scomporre poi ogni seed event nelle interazioni critiche sposta l’attenzione dal futuro ipotetico al presente osservabile.
Se si raccolgono le interazioni critiche associate ai diversi rischi, si ottiene un Interaction Register: una mappa del contesto che mostra quali relazioni ricorrono più spesso, quali sono più fragili e dove si concentra la pressione sul sistema. In questo modo diventa più chiaro dove intervenire per stabilizzarlo.
Tuttavia, la rete è utile solo se diventa governabile.
Per questo servono pochi sensori di early warning che segnalino il cambio di regime prima dei KPI finali:
- Backlog: lavoro “in attesa” (decisioni, approvazioni, chiarimenti, varianti, non conformità) che indica accumulo di energia potenziale;
- WIP (Work In Progress): quantità di lavoro aperto simultaneamente, spesso correlata a multitasking e frammentazione delle interfacce;
- Rework: lavoro rifatto (o rifacimenti mascherati da “revisioni”) che segnala feedback positivi in atto;
- Latenza/qualità del feedback: tempo e affidabilità con cui il sistema “risponde” (ciclo decisionale, tempi di chiarimento, qualità informativa degli handover).
Letti insieme, questi indicatori misurano la dinamica del sistema. Se backlog e WIP crescono e il rework accelera, il progetto sta entrando in una zona non lineare; se aumenta la latenza, anche le buone decisioni arrivano tardi.
5. Agire sulle interazioni: mitigazioni e decisioni che non alimentano escalation
Se il rischio complessivo è un effetto di rete, non basta reagire al singolo evento. Bisogna intervenire sulle interazioni che lo rendono probabile e che ne amplificano l’impatto. Per questo ogni azione di mitigazione va valutata con attenzione: può stabilizzare il sistema, ma può anche generare nuove catene di effetti indesiderati.
Una stessa interazione può essere stabilizzante per alcuni rischi e amplificante per altri. L’Interaction Register aiuta quindi a capire dove intervenire, cioè sulle interazioni più ricorrenti e più pesanti nella generazione dei seed event.
Se molti rischi prevedono la stessa interazione tra due fattori, conviene introdurre misure che la rendano meno frequente o meno efficace.
Quando ricorre lo stesso attributo, ad esempio ambiguità o inaffidabilità, bisogna ridurne l’entità nell’intero contesto.
L’Interaction Register è utile anche per evitare risposte di “buon senso” che, nei sistemi complessi, peggiorano il quadro: un’azione vantaggiosa su un rischio può risultare dannosa a livello globale.
Più risorse in un sistema saturo possono aumentare interfacce e WIP; più controllo può introdurre latenza; più urgenza può ridurre qualità e generare rework. Per questo le mitigazioni vanno valutate per i loro effetti di rete.
Con un Interaction Register queste controindicazioni possono essere rese visibili anche tramite indicatori globali riportabili nei cruscotti.
Inoltre l’Interaction Register aiuta a definire KPI leading capaci di segnalare l’aumento del rischio prima che si trasformi in incidente.
6. Conclusioni e checklist essenziale
Nei progetti complessi la non linearità è l’esito naturale di dipendenze, interfacce e feedback. Un evento piccolo diventa rilevante quando si accoppia a un attributo critico e trova nella rete un canale di propagazione; oltre certe soglie, il progetto cambia regime.
Per questo la gestione del rischio deve spostarsi dal singolo evento alla catena di interazioni che lo rende possibile: Risk Register → seed event → Interaction Register → sensori anticipatori → decisioni sulle interfacce.
La checklist seguente traduce questa lettura in domande rapide di governance per capire dove si accumula tensione, quale loop domina e su quali interazioni conviene intervenire.
1) Quali interfacce sono oggi più critiche e cosa succede se una rallenta?
2) Quali fattori esterni stanno cambiando rispetto al modello e quale attributo introducono?
3) Quali accoppiamenti “fattore sano + attributo” stanno diventando canali di propagazione?
4) Dove si accumulano backlog, WIP e rework e come si influenzano?
5) Quanto è lento o inaffidabile il feedback nelle decisioni chiave?
6) Quale loop domina oggi: stabilizzazione o escalation?
7) Stiamo agendo sui sintomi o sulle interazioni?
8) Decision rights e timebox sono chiari?
9) Quali guardrail proteggono le interfacce critiche?
10) Qual è il prossimo esperimento safe-to-fail sulle interazioni dominanti?
In sintesi, nei sistemi complessi il PM non controlla ottimizzando parti isolate, ma governando interfacce, condizioni e feedback.
La leva principale non è aggiungere attività, urgenza o controllo in modo indiscriminato, ma ridurre gli accoppiamenti critici, drenare gli stock e accorciare la latenza del feedback. Nel prossimo articolo questa logica sarà tradotta in un modello pratico di governance adattiva.
