Theory-of-Change-Modell: das Non-Profit-Framework, das deinen OKRs fehlt

Bitte eine Programmverantwortliche einer Non-Profit-Organisation, einen Förderantrag zu rechtfertigen, und innerhalb von fünf Minuten zückt sie ein Diagramm: Inputs, Aktivitäten, Outputs, Outcomes, Impact – jede Box führt logisch zur nächsten. Bitte einen Product Manager zu erklären, warum ein Roadmap-Punkt eine Umsatzkennzahl bewegen soll, und du bekommst meistens nur ein Schulterzucken, eine Folie mit einem Hockeyschläger-Chart oder ein „weil unser Wettbewerber etwas Ähnliches gebaut hat“.

Dieses Diagramm hat einen Namen. Es ist ein Theory-of-Change-Modell, eines der konsequentesten Planungstools überhaupt, und fast kein Business-Team nutzt es. Nicht, weil es nicht passt. Sondern weil fast niemand außerhalb von internationaler Entwicklungszusammenarbeit, öffentlicher Gesundheit und Bildungsförderung je damit in Berührung gekommen ist.

Schade eigentlich. Die Logik hinter einem Theory-of-Change-Modell, eine explizite Wenn-dann-Kette von dem, was du tust, zu dem, was sich dadurch ändert, ist genau das, was den meisten OKRs, Roadmaps und Strategieplänen fehlt. Teams verpflichten sich ständig zu Initiativen, ohne je aufzuschreiben, warum sie glauben, dass diese Initiative die angepeilte Kennzahl bewegen wird. Ein Theory-of-Change-Modell zwingt diese Annahme aufs Papier, öffentlich, wo jemand sie tatsächlich infrage stellen kann.

Hier ist, was ein Theory-of-Change-Modell wirklich ist, warum die Non-Profit-Version den Kontakt mit einem Unternehmen nicht übersteht, und wie du eines so umsetzt, dass es nicht zur nächsten Folie wird, die nie wieder jemand öffnet.

Was ein Theory-of-Change-Modell wirklich ist

Ein Theory-of-Change-Modell bildet die Kausalkette zwischen dem, was eine Organisation tut, und der Veränderung ab, die sie erreichen will, üblicherweise in fünf Stufen:

• Inputs: die Ressourcen, die du einsetzt (Menschen, Budget, Zeit)
• Aktivitäten: was du konkret mit diesen Ressourcen machst
• Outputs: das direkte, zählbare Ergebnis der Aktivität (ein durchgeführtes Programm, ein ausgeliefertes Feature)
• Outcomes: das Verhalten oder der Zustand, der sich durch den Output verändert
• Impact: das langfristige Ziel, dem das Ganze dienen soll

Was es von einem einfachen Projektplan unterscheidet, sind die Pfeile, nicht die Boxen. Zwischen jeder Stufe steckt eine Annahme: Wenn wir diese Aktivität durchführen, folgt dieser Output, aus diesem konkreten Grund. Ein Theory-of-Change-Modell verlangt, diesen Grund laut auszusprechen, statt anzunehmen, dass sowieso alle einer Meinung sind.

Hier bringen viele es auch mit einem Logic Model durcheinander. Ein Logic Model bildet dieselben fünf Boxen ab und dokumentiert vor allem, was passieren soll. Ein Theory-of-Change-Modell geht einen Schritt weiter und dokumentiert, warum du glaubst, dass es passieren wird, einschließlich der Annahmen und Risiken, die die Kette unterwegs zerreißen könnten. In der Praxis werden die beiden Begriffe meist synonym verwendet, aber genau genommen gilt: Ein Logic Model ist die Landkarte, und eine Theory of Change ist die Landkarte plus die Begründung dahinter.

Warum die Non-Profit-Version den Kontakt mit einem Unternehmen nicht übersteht

Non-Profits erstellen Theory-of-Change-Modelle, um Geldgeber zufriedenzustellen, nicht um die Organisation Woche für Woche zu steuern. Es wird einmal gebaut, vor einem Förderantrag, bekommt von wem auch immer gut mit dem Whiteboard umgehen kann einen hübschen Diagramm-Anstrich und verschwindet dann in einem Ordner, bis der nächste Förderzyklus jemanden zwingt, es wieder hervorzuholen.

Business-Teams, die sich das Framework ausleihen, machen tendenziell genau denselben Fehler. Es taucht als Folie bei einem Strategie-Offsite auf, alle nicken, und danach nimmt nie wieder jemand Bezug darauf, bis sechs Monate später jemand fragt: „Moment, warum machen wir dieses Projekt eigentlich?“, und sich niemand mehr so richtig an die ursprüngliche Begründung erinnert. Das Dokument war nie falsch. Es war nur nie dafür gemacht, mehr als einmal benutzt zu werden.

Wie sich das auf OKRs übertragen lässt

Wenn du bereits mit OKRs arbeitest, hast du im Grunde schon zwei Drittel eines Theory-of-Change-Modells, nur ohne die Begründungsebene. Das Objective ist der Impact. Die Key Results sind die Outcomes. Die Initiativen unter jedem Key Result sind die Aktivitäten und Outputs.

(siehe auch: Outputs vs. Outcomes)

Der Teil, den fast alle überspringen, ist die Annahme, die eine Initiative mit einem Key Result verbindet: das „weil“, das erklärt, warum genau diese Arbeit genau diese Zahl bewegen sollte. Überspringst du das, werden OKRs zu einer To-do-Liste mit angeflanschtem Scoreboard. Baust du es ein, werden OKRs zu dem, was sie sein sollen: eine Übersetzungsschicht zwischen Strategie und Umsetzung, genau die Rolle, die wir in Strategieumsetzung beschrieben haben. Ein Theory-of-Change-Modell ist nur ein disziplinierterer Weg, diese Übersetzung aufzuschreiben, bevor du echte Ressourcen dafür einsetzt.

In vier Schritten zu einem Modell, das nicht einstaubt

1. Schreib die Kette für jeweils eine Initiative, nicht für das ganze Unternehmen. Ein unternehmensweites Theory-of-Change-Modell ist zu abstrakt, als dass irgendjemand ihm widersprechen könnte. Eines auf Initiativ-Ebene, „wenn wir X liefern, dann Y, weil Z“, ist konkret genug, dass jemand tatsächlich anderer Meinung sein kann.
2. Benenne die Annahme bei jedem Pfeil, nicht nur die Boxen. „Wir bauen eine Onboarding-Checkliste“ ist eine Aktivität. „Weil ein schnellerer Time-to-Value eine niedrigere Churn-Rate verursacht und nicht nur mit ihr korreliert“ ist die Annahme, die die eigentliche Arbeit leistet.
3. Verknüpfe es mit einem festen Rhythmus, nicht mit einem Jahresplanungsdokument. Ein Theory-of-Change-Modell, das nur einmal im Jahr wieder geöffnet wird, ist ein Non-Profit-Förderdokument im Business-Anzug. Kombiniere es mit denselben Check-ins, die du ohnehin schon für deine OKRs durchführst, damit die Annahme an echten Zahlen geprüft wird, statt nur wehmütig in Erinnerung zu bleiben.
4. Überprüfe die Kette regelmäßig und entferne kaputte Glieder. Wenn sich ein Outcome nicht so entwickelt, wie die Kette es vorhergesagt hat, ist die Lösung meist nicht eine neue Taktik, die an dieselbe Annahme angeflanscht wird. Es bedeutet, einzugestehen, dass die Annahme falsch war, und dieses Kettenglied neu zu schreiben, bevor das nächste Quartal denselben Fehler wiederholt.

Ein durchgerechnetes Beispiel

Ein 40-köpfiges B2B-SaaS-Team glaubt, dass sein 90-Tage-Churn-Problem in Wirklichkeit ein Time-to-Value-Problem ist. Sauber aufgeschrieben, sieht sein Theory-of-Change-Modell so aus:

• Inputs: zwei Engineers, eine Designerin, drei Wochen
• Aktivitäten: eine In-App-Onboarding-Checkliste bauen, die die fünf Einrichtungsschritte abdeckt, die mit gehaltenen Accounts korrelieren
• Outputs: Anteil der neuen Accounts, die die Checkliste innerhalb der ersten Woche abschließen
• Outcomes: die mittlere Time-to-First-Value sinkt von 12 auf 4 Tage; der 90-Tage-Churn unter denen, die die Checkliste abgeschlossen haben, sinkt
• Impact: die Net Revenue Retention verbessert sich für diese Kohorte

Die Annahme auf dem Pfeil zwischen Output und Outcome ist diejenige, über die es sich zu streiten lohnt, bevor jemand eine Zeile Code schreibt: Führt ein schnelleres Abschließen der Checkliste tatsächlich zu niedrigerem Churn, oder waren die Accounts, die sie am wahrscheinlichsten schnell abschließen, ohnehin schon diejenigen, die am ehesten geblieben wären? Das ist eine testbare Frage, keine rhetorische. Ein wöchentlicher Check-in zum Frühindikator, der Abschlussquote der Checkliste, zeigt dem Team innerhalb eines Monats, ob die Theorie trägt, statt erst beim nächsten QBR festzustellen, dass ein ganzes Quartal Engineering-Zeit einer Korrelation statt einer Ursache hinterherjagte.

Häufige Fehler

• Von der Impact-Kennzahl ausgehen und rückwärts zu Aktivitäten arbeiten, die plausibel klingen, statt von dem auszugehen, was das Team tatsächlich kontrollieren kann, und vorwärts zu arbeiten.
• Die Annahme überspringen und eine plausibel klingende Geschichte so behandeln, als wäre sie bereits der Plan selbst.
• Es als Dokument statt als Hypothese behandeln. Abgeheftet statt getestet, überarbeitet oder gelegentlich verworfen.
• Es mit einer Roadmap verwechseln. Eine Roadmap sagt, was du baust und wann. Ein Theory-of-Change-Modell sagt, warum du glaubst, dass es wichtig ist, genau der Teil, den eine Roadmap meist komplett weglässt.

Wo Tability ins Spiel kommt

Nichts davon erfordert neue Software. Es erfordert, die Annahme irgendwo aufzuschreiben, wo alle sie sehen können, und sie in einem festen Rhythmus zu überprüfen statt einmal im Jahr. Tools wie Tability sind genau dafür gebaut: ein Ort, um eine Initiative mit dem Key Result zu verknüpfen, das sie bewegen soll, mit einer laufenden Check-in-Historie, die zeigt, ob die zugrunde liegende Annahme standhält oder still und leise zerbröckelt. Das ist dieselbe operative Ebene, die wir in StratOps und im OKR-Framework beschrieben haben.

Wenn du dein Team dazu bringen willst, über Annahmen zu diskutieren, bevor du ein ganzes Quartal Engineering-Zeit dafür einsetzt, oder wenn du die StratOps-Funktion aufbaust, die diese Art von Denken zur Routine macht, dann registriere dich kostenlos bei Tability oder buche 30 Minuten mit uns, und wir helfen dir herauszufinden, wie das für dein Team aussieht. Ob mit oder ohne Tability, das „weil“ aufzuschreiben lohnt sich so oder so.