“We can’t control systems or figure them out. But we can dance with them!”
(tratto dal saggio di Donella Meadows “Dancing with Systems” pubblicato nel 2001)
1. Il punto di partenza: l’incertezza non si elimina (si governa)
Nei progetti con molti domini e attori, l’incertezza non è un difetto del piano: è una proprietà del sistema. Più dettaglio e rigidità spesso producono solo un’illusione di controllo. Nei sistemi complessi, interdipendenze, ritardi e feedback rendono poco replicabile ciò che “funzionava ieri”. Governare l’incertezza significa trasformare informazioni imperfette in decisioni responsabili e riconoscere che anche rinviare è una scelta.
2. Il progetto come sistema (e come «grey box»): cosa possiamo conoscere davvero
Se accettiamo che l’incertezza è strutturale, la domanda diventa che cosa stiamo gestendo quando “gestiamo un progetto”?
Nei contesti complessi, un progetto è un sistema temporaneo che vive dentro un sistema più ampio (il contesto) e interagisce continuamente con esso.
Da qui due conseguenze operative:
(i) Conosciamo sempre solo una parte delle interazioni;
(ii) I confini del progetto sono interfacce attraverso cui entrano input addizionali.
In sostanza, gestiamo un sistema che possiamo comprendere solo in parte: una grey box, di cui osserviamo alcuni input e output ma non tutte le dinamiche interne né le influenze esterne. Il rischio è decidere sulla base di una “mappa” che non coincide più con il “territorio”, mentre il contesto continua a evolvere.
I confini del progetto sono interfacce: stakeholder, vincoli ambientali o normativi e meccanismi di governance introducono input aggiuntivi che alterano tempi e scelte. “Gestire” significa presidiare queste interfacce e rendere esplicite le assunzioni prima che diventino punti ciechi.
3. Leggere i feedback: come il sistema ci risponde (e cosa farne)
Nei sistemi complessi, il feedback è il modo in cui il sistema risponde alle decisioni e quindi il principale strumento per comprenderlo. Gli effetti tornano spesso con ritardi e amplificazioni: “danzare” significa osservare e reagire senza aspettarsi un rapporto lineare tra azione e risultato.
Un piccolo scostamento può restare silente e diventare visibile quando un vincolo si satura. Per questo conviene leggere ritardi e accumuli; backlog, difetti, attese decisionali e stress organizzativo sono segnali di traiettoria, non solo “problemi”.
I KPI funzionano come sensori: alcuni misurano lo stato (stock: arretrati, difetti, richieste pendenti), altri la traiettoria (flow: lead time, closing rate, tempi decisionali). Confondere stato e traiettoria porta spesso a reazioni tardive.
Un feedback inatteso non è solo un’anomalia da correggere ma anche un’informazione su confini, interdipendenze e assunti che non stavamo vedendo. La domanda utile non è “chi ha sbagliato?”, ma “che cosa ci sta dicendo il sistema della nostra rappresentazione?”.
4. Strategie operative: sperimentare, contenere, orientare
Se il progetto è un sistema che reagisce, la domanda diventa come ottenere informazioni affidabili e orientare il comportamento emergente. Nel project management significa introdurre micro-azioni che accelerano l’apprendimento, limitano gli effetti indesiderati e mantengono l’organizzazione adattabile.
Molte scelte restano ipotesi finché non vengono testate nel sistema reale. Per questo servono piccoli esperimenti (probe) sulle assunzioni critiche, in logica safe-to-fail: reversibili, limitati e con criteri di stop espliciti, così da massimizzare l’apprendimento e minimizzare i danni.
Per “danzare” non serve libertà totale, servono vincoli abilitanti e confini minimi (scopo condiviso, criteri di priorità, regole di escalation, linguaggio comune sugli indicatori) che rendano produttive le interazioni senza irrigidire il sistema.
5. Dove intervenire: le leve che contano (senza inseguire gli eventi)
Una volta accettato che il progetto è un sistema, il tema non è “fare di più” ma scegliere dove agire. Conta distinguere tra interventi che spostano temporaneamente un indicatore e interventi che cambiano le condizioni che generano quel risultato. Il passaggio decisivo è dall’ansia di controllo alla disciplina del governo.
La tentazione è agire sui numeri visibili (scadenze, % avanzamento, costi). Ma la leva raramente è l’indicatore bensì il processo che lo produce. Bisogna agire sulla qualità e la tempestività dell’informazione, modificare le regole decisionali ed i vincoli abilitanti, e migliorare la gestione delle interfacce.
Per riuscirci occorre rivedere i flussi informativi, ridurre l’ambiguità su priorità, variazioni ed escalation, chiarire i ruoli decisionali e proteggere buffer e interfacce critiche. Quando invece si irrigidisce tutto, ogni deviazione diventa escalation, i decisori si saturano e il sistema si blocca.
I sintomi sono noti: più controlli senza decisioni, più report e meno velocità. In questi casi conviene chiedersi quale feedback stia amplificando il problema: quale regola genera attrito, quale informazione arriva tardi, quale interfaccia è diventata un collo di bottiglia.
6. Governance adattiva: progettare il controllo che non produce fragilità
In contesti complessi, la governance non può limitarsi a proteggere il piano: deve diventare un sistema decisionale che apprende. L’obiettivo non è controllare di più, ma costruire feedback rapidi, responsabilità chiare e un ritmo di governo che non trasformi ogni variazione in burocrazia.
Per evitare questa deriva, serve una governance adattiva: pochi vincoli abilitanti, sensori utili (KPI come segnali, non come consuntivi) e processi decisionali capaci di distinguere tra ciò che va standardizzato e ciò che va esplorato. In pratica, stabilità dove serve e libertà dove produce apprendimento.
Tre elementi risultano determinanti:
- effettuare revisioni rapide e ricorrenti sui segnali leading,
- prendere decisioni chiare, assegnando senza ambiguità una responsabilità esplicita (owner),
- e prevedere meccanismi di escalation semplici, con soglie ben definite.
Così si riducono il rumore (meeting e reporting che non cambiano nulla) e la latenza (problemi che maturano sottosoglia).
L’apprendimento deve entrare nella governance: un learning log, retrospettive periodiche e aggiornamento trasparente delle ipotesi di piano e KPI aiutano a trasformare gli imprevisti in miglioramenti concreti.
Ogni evento inatteso di rilievo deve generare un miglioramento tangibile, come l’introduzione di un nuovo indicatore o sensore, la modifica di una regola, oppure una decisione di riallineamento. Se l’unico risultato è un incremento del controllo, significa che il sistema sta acquisendo fragilità invece che robustezza.
7. Dal caso alla pratica: una micro-storia di governo (non una crisi)
Nei sistemi complessi, le emergenze raramente esplodono all’improvviso: di solito nascono da interazioni distribuite e da ritardi informativi. Per questo l’osservazione dei segnali anticipatori è decisiva per evitare che piccole anomalie diventino crisi.
Immaginiamo un progetto con più team e un fornitore: una piccola modifica a una specifica d’interfaccia sembra innocua ma, dopo qualche settimana, genera accumuli nell’integrazione, difetti downstream e instabilità nella pianificazione. Quando dipendenze o versioni non sono allineate, le rilavorazioni emergono tardi e costano molto di più.
I segnali utili non sono quelli finali, come ritardi di milestone o aumento dei costi, ma quelli che fanno vedere l’accumulo prima che diventi problema. Si possono leggere in tre famiglie:
- Stock: backlog di integrazione, eccezioni manuali, difetti riaperti; segnalano accumuli e congestioni.
- Flow: lead time, ritmo di chiusura dei difetti, tempi decisionali; contano soprattutto i trend.
- Informazione: assunzioni implicite e artefatti non allineati; quando “pronto” non coincide con “integrato”, l’attrito cresce.
Ne deriva una disciplina di conversazione. Infatti, è più produttivo discutere di interfacce (cosa entra e dove si accumula), vincoli (cosa rallenta) e ipotesi (cosa si sta testando), piuttosto che limitarsi allo “stato”.
La lezione è semplice: governare significa vedere prima, decidere prima e imparare prima, intervenendo su interfacce e regole minime prima che l’accumulo diventi crisi.
8. Conclusioni: che cosa cambia domani mattina nel modo di gestire
Che cosa dovrebbe cambiare, domani mattina, nel modo di gestire?
- Definire sistema e confini. Dichiarare scopo, interfacce e assunti: senza perimetro si controlla la mappa mentre il territorio evolve altrove.
- Progettare feedback utili. KPI e dashboard servono a rendere visibili accumuli, ritardi e trend (leading), prima che diventino un’emergenza.
- Agire sulle leve, non sugli eventi. Informazioni, regole minime, ruoli decisionali, interfacce e buffer cambiano le condizioni del sistema; “più pressione” spesso irrigidisce e opacizza.
Ecco una checklist rapida (10 minuti) da usare quando crescono complessità e rumore decisionale:
- Contesto: in che dominio sto operando e con quali segnali?
- Sistema: scopo, confini e interfacce critiche sono espliciti?
- Assunzioni: quali ipotesi reggono il piano e come le sto testando?
- Stock & flow: dove si accumulano lavoro, errori o attese e come stanno i trend?
- Decisioni: chi decide cosa, con quali soglie, tempi ed escalation?
- Vincoli minimi: quali regole proteggono qualità e interfacce?
- Apprendimento: ogni sorpresa produce un aggiornamento concreto?
Nel prossimo articolo faremo un passo ulteriore: quando i feedback diventano non lineari (soglie, amplificazioni, shifting dominance), il sistema cambia regime e le soluzioni “di buon senso” smettono di funzionare. Per orientarsi serve un’analisi di contesto più strutturata, quali fattori esterni stanno cambiando e quali vulnerabilità interne li amplificano.
