{"id":4543,"date":"2025-11-26T15:40:44","date_gmt":"2025-11-26T14:40:44","guid":{"rendered":"https:\/\/www.fullo.net\/blog\/?p=4543"},"modified":"2025-11-26T15:40:49","modified_gmt":"2025-11-26T14:40:49","slug":"theory-of-change-e-unknown-unknowns","status":"publish","type":"post","link":"https:\/\/www.fullo.net\/blog\/2025\/11\/26\/theory-of-change-e-unknown-unknowns\/","title":{"rendered":"Theory of Change e unknown unknowns"},"content":{"rendered":"\n

TL;DR<\/strong>: Durante un workshop per costruire una ToC su sostenibilit\u00e0 digitale, mi \u00e8 stata fatta una domanda molto intelligente: “E se cambia tutto?<\/em>” La risposta non \u00e8 nella precisione del piano, ma nel distinguere cosa non cambia mai (l’Impact) da cosa deve essere flessibile (tutto il resto). Gli unknown unknowns non si prevengono, si navigano.<\/p>\n\n\n\n\n\n\n\n

Quando la mappa incontra la realt\u00e0<\/h2>\n\n\n\n

Workshop di due giorni con il team di un’azienda per costruire una Theory of Change su un progetto di sostenibilit\u00e0 digitale. Avevamo fatto tutto bene: backwards mapping preciso dal goal a lungo termine (“riduzione del 40% dell’impatto ambientale delle infrastrutture IT per utente entro 2 anni<\/em>“), outcomes intermedi chiari, assunzioni esplicitate, metriche definite a ogni livello. Sulla lavagna di Miro c’era una prima versione della ToC che sembrava perfetta.<\/p>\n\n\n\n

Poi \u00e8 arrivata la domanda.<\/p>\n\n\n\n

Uno delle persone del team, quello che di solito sta zitto e ascolta, alza la mano: “Scusa Fullo, ma questa roba funziona fino a quando non cambia niente, giusto? Tipo, noi abbiamo mappato tutto assumendo che la nostra architettura resti quella. Ma se tra sei mesi il CTO decide di migrare tutto su una piattaforma diversa? O se esce una tecnologia che rende obsoleto quello che stiamo ottimizzando? O se il fornitore cloud cambia le sue metriche di sostenibilit\u00e0 e non possiamo pi\u00f9 misurare nello stesso modo?<\/em>“<\/p>\n\n\n\n

Silenzio in stanza. Perch\u00e9 aveva ragione. Nella testa delle persone si era formata una mappa bellissima di un territorio che poteva cambiare completamente sotto i nostri piedi.<\/p>\n\n\n\n

“Esatto<\/em>,” gli ho risposto. “Questa ToC non ti protegge dagli unknown unknowns. Non pu\u00f2 farlo. Ma ti d\u00e0 qualcosa di pi\u00f9 importante: la struttura per navigarli quando emergono senza andare nel panico o buttare via tutto.<\/em>“<\/p>\n\n\n\n

Da l\u00ec \u00e8 partita una discussione di un’ora che ha cambiato completamente il modo in cui quel team guardava la loro ToC. Non come un piano rigido (“se succede X facciamo Y<\/em>“), ma come una bussola (“vogliamo arrivare l\u00ec, e quando cambia qualcosa troviamo una strada diversa mantenendo la direzione<\/em>“).<\/p>\n\n\n\n

Quella discussione mi ha fatto capire che \u00e8 importante, nel far utilizzare concetti come quelli della Theory of Change, di evitare semplificazioni che portano a ragionare come se ci fosse una precisione assoluta nelle assunzioni originali ma nel dare gli strumenti per distinguere cosa non cambia mai<\/strong> (l’Impact che si vuole creare) da cosa deve essere flessibile<\/strong> (le Activities per arrivarci).<\/p>\n\n\n\n

La ToC e il suo punto cieco strutturale<\/h2>\n\n\n\n

Parliamoci chiaro: la Theory of Change ha un punto cieco gigantesco.<\/p>\n\n\n\n

Si basa su backwards mapping<\/a> da un futuro che immagini<\/strong>. Ma per definizione, gli unknown-unknowns sono fuori dalla tua immaginazione. Non puoi mapparli a ritroso se non sai che esistono.<\/p>\n\n\n\n

Facciamo una distinzione fondamentale:<\/p>\n\n\n\n

Known unknowns<\/strong> (rischi mappabili nella ToC):<\/p>\n\n\n\n