Montag, 28. April 2025

Der Unterbau von OKRs

Für sich genommen klingt die Idee der Objectives and Key Results (OKRs) erstmal einfach. Man setzt ein abstraktes, mittelfristiges Ziel (z.B. Erschliessung eines neuen Kundensegments im nächsten Quartal) und verbindet es mit wenigen konkreten, messbaren Ergebnissen (z.B. X Nutzer nach dem ersten Monat, Y Wachstumsrate im 2. Monat, Z Prozent Verlängerungen nach der Probezeit). Die Herausforderung, die dadurch entsteht ist aber: wie lässt sich das mit dem Alltagsgeschäft verbinden?


Die erste und naheliegende Antwort ist es, in kurzen Abständen (z.B. wöchentlich) zu überprüfen, ob Forschritt in der gewünschten Richtung stattfindet und ggf. Anpassungsmassnahmen zu beschiessen, falls die bisherigen Ergebnisse zu wünschen übriglassen. Auch hier bleibt aber offen, was genau es ist, das da begutachtet wird. Natürlich kann man sich immer wieder die OKRs selbst vorlegen, die Verbindung zum Alltagsgeschäft wäre damit aber noch immer nicht gegeben.


Ein häufig anzutreffender Ansatz zum Schliessen dieser Lücke ist, für die jeweiligen Key Results einen weiteren Work Breakdown durchzuführen und die Umsetzung der sich so ergebenden Arbeitspakete mit Hilfe eines Backlogs oder einer Roadmap zu planen.1 Damit wird nicht nur die Umsetzungslücke geschlossen, es ist darüber hinaus möglich, die OKR-Aufwände und die sonstigen Tätigkeiten in einer gemeinsamen Planungssicht zusammenzufassen und so Redundanzen und Überplanung zu vermeiden.


Die Art der jeweiligen Arbeitspakete kann schliesslich variieren. Sie können die Bereitstellung der (Infra-)Strukturen zum Gegenstand haben, die für die Erbringung von Leistungen Voraussetzung sind, sie können aus der Fertig- und Bereitstellung von neuen Produkten, Features oder Services bestehen, sie können aber auch die Form von Business-Experimenten haben, durch die erforscht wird, auf welche Art und Weise sich Nutzergewohnheiten ändern oder Kaufanreize setzen lassen.


Wichtig bei der Definition dieses Unterbaus unterhalb der OKRs ist dabei weniger, um was für Arbeitspakete es sich genau handelt, sondern eher ob sie zur Erreichung der übergeordneten messbaren Ergebnisse, der Key Results, beitragen. Stellt sich heraus, dass sie einen Beitrag leisten, sollten sie ggf. wiederholt und intensiviert werden können, leisten sie keinen erkennbaren Beitrag muss es möglich sein, sie unbürokratisch zu variieren oder zu verwerfen. Auf keinen Fall dürfen sie zum Selbstzweck werden.


Der Vollständigkeit halber sei noch erwähnt, dass diese Art mit Objectives and Key Results zu arbeiten weder die einzige ist, noch eine die per Definition besser als andere Vorgehensweisen wäre. Es ist aber eine, mit der sich die Verbindung zwischen OKRs und Alltagsgeschäft gut herstellen lässt. Wer in diesem Bereich Verbesserungspotential sieht, kann daher einen Versuch wagen und überprüfen, wie gut dieser Ansatz für ihn funktioniert - idealerweise anhand von im voraus definierten Erfolgskriterien.



1Ein naheliegender Ansatz ist die Nutzung der Key Results als Sprintziele in Scrum

Related Articles