Bessere Entscheidungen treffen, um Ziele zu erreichen

Je dynamischer unser Umfeld ist, desto sinnvoller ist es, Entscheidungen zu zerlegen und damit häufiger, kleine Entscheidungen zu treffen. Spannend ist in dem Zusammenhang auch die Frage, nach welchen Kriterien und wann wir Entscheidungen treffen. Bevor wir diesen Aspekten nachgehen, betrachten wir zuerst, was Entscheidungen eigentlich sind beziehungsweise was sie so schwierig macht.

Alea iacta est – Der Würfel ist gefallen

Im vorchristlichen Rom war es den Heerführern nicht gestattet, sich mit ihren Soldaten Rom zu nähern. Der Fluss Rubicon bildete die Grenze zur römischen Provinz Gallia Cisalpina und damit auch die Grenzlinie für Gaius Julius Cäsar, die er nicht mit seinem Heer aus Gallien überschreiten durfte, ohne die Gefahr eines Bürgerkriegs einzugehen. Nach längerem Zögern und Abwägen überschritt Cäsar am 10. Januar 49 vor Christus den Rubicon und veränderte den Lauf der europäischen Geschichte.

Wir verwenden den Ausspruch „über den Rubicon gehen“ noch heute in Bezug auf Entscheidungen, die folgenschwere, unumkehrbare Konsequenzen nach sich ziehen. Es sind also die möglichen Konsequenzen einer Entscheidung, die sie so schwierig machen. Doch das ist es nicht alleine. In der Regel wissen wir nicht, was durch eine Entscheidung alles in Gang gesetzt wird und was wirklich passieren wird. Eine Reihe von Ergebnissen ist möglich.

Wir treffen Entscheidungen also unter Ungewissheit über deren Konsequenzen. Diese Ungewissheit können wir noch weiter differenzieren. Wenn wir die Eintrittswahrscheinlichkeiten für bestimmte Zustände einschätzen können, sprechen wir von Entscheidungen unter Risiko. Wenn die Eintrittswahrscheinlichkeiten nicht für uns fassbar sind, haben wir es mit Entscheidungen unter Unsicherheit zu tun. Wir haben zu wenig Informationen, was uns die Entscheidung so besonders schwer macht [1].

Viele kleine anstatt weniger großer Entscheidungen

Entscheidungen unter Unsicherheit sind nun auch noch besonders häufig bei der Umsetzung komplexer Aufgaben zu treffen. Wie können wir damit umgehen, um dennoch unsere Ziele zu erreichen? Eine Idee ist es, Entscheidungen zu zerlegen und so zu kleineren Entscheidungen zu kommen, deren Konsequenzen weniger dramatisch sind. Wir können dann die Entscheidungen Schritt für Schritt treffen und umsetzen. So lernen wir mit jeder Entscheidung mehr und können auf dieser neuen Basis die nächste Entscheidung treffen.

Wie kann so etwas aussehen? Ein Beispiel für eine zentrale Entscheidung ist, über die Entwicklung einer neuen, mobilen App für unser Produktportfolio zu befinden. Entlang des Prozesses einer App-Entwicklung können wir diese zentrale Entscheidung in mehrere Teilentscheidungen zerlegen und so schrittweise bearbeiten:

• Grundlagen bereitstellen – Ziel und Kernfunktionen festlegen: Was soll die App können und welche Kernfunktionen sind notwendig?
• Technologische Grundsatzentscheidungen treffen – Technologie-Stack definieren: Möchten wir eine native App für iOS und Android entwickeln oder eine Cross-Plattform-App wie beispielsweise über Flutter oder React Native einsetzen?
• Grundlegende Architekturentscheidungen treffen: Soll die App zum Beispiel cloudbasiert sein? Wie wird die Datenbank strukturiert?
• Security – Von vorneherein eingeplante und integrierte Sicherheitsmaßnahmen: Wie wird die App vor Angriffen geschützt? Welche Datenschutzanforderungen müssen erfüllt werden?
• UI/UX Design – Usability und intuitive Bedienung: Wie soll die Benutzeroberfläche aussehen?
• Qualität – Teststrategie entwickeln: Wollen wir testgetrieben vorgehen? Welche Testfälle müssen abgedeckt werden? Welche Tests sollen automatisiert werden, und welche werden manuell durchgeführt?
• Software-Lifecycle – Bereitstellung der App und ihre Wartung: Wie erfolgen die Veröffentlichungen und Updates beziehungsweise schnelle Bugfixes? Wie soll die nachhaltige und langfristige Wartung umgesetzt werden?

Durch vorherige Entscheidungen werden oft die nachfolgenden Entscheidungen beeinflusst. Das bedeutet, dass wir uns den Entscheidungen in dieser Reihenfolge widmen und auch für jede Entscheidung eine Rückmeldung aus der technischen Umsetzung benötigen. Diese Umsetzung wird jedoch nicht vollständig vorgenommen, sondern nur insoweit, dass wir die Entscheidung beurteilen können. Meist reicht dafür ein Durchstich (Spike) aus, manchmal kann ein Prototyp notwendig sein. So sichern wir jeden Schritt ab und können jede der Teilentscheidungen zum passenden Zeitpunkt treffen. Doch wann ist der passende Zeitpunkt für eine Entscheidung?

Last Responsible Moment

Wann ist der richtige Moment für eine grundlegende Entscheidung? Das Timing ist deshalb so wichtig, weil darauf das Lernfenster beruht. Von dessen Länge hängt ab, wie gut es sich nutzen lässt und welche anderen relevanten Erkenntnisse währenddessen vorliegen. Dieser ideale Zeitpunkt ist im Lean Management von besonderer Bedeutung und wird Last Responsible Moment (LRM) oder auf Deutsch der letzte vernünftige Moment genannt (Bild 1). Zu einem späteren Zeitpunkt kann man die Entscheidung nicht mehr frei treffen, sondern das Faktische schreibt den Weg vor [2] [3].

Entscheidungen werden dabei möglichst spät getroffen, auch wenn das Problem selbst schon früher bekannt ist. Diese zeitliche Verzögerung dient dem Erkenntnisgewinn und ermöglicht bessere Entscheidungen. Gleichzeitig wird ein virtueller Moment definiert, an dem eine Entscheidung spätestens getroffen werden muss, um negative Effekte zu vermeiden, die den Lerneffekt zunichtemachen. Im Zweifel wandert eine entsprechende Fragestellung lieber zu früh in den Entscheidungsprozess. Wenn dies dort erkannt wird, kann eine Entscheidung verschoben werden, um bei passenderer Gelegenheit wieder betrachtet zu werden.

Fragestellungen wandern mit der Zeit zum LRM (Bild 1, rechts). Dieser Moment ist für jede Fragestellung individuell und eher metaphorisch zu verstehen. Für Entscheidungen, die später nur noch sehr aufwendig und damit teuer zu ändern sind, ist es der Zeitpunkt, an dem mindestens eine wichtige Entscheidungsalternative wegbricht beziehungsweise eine Option abläuft.

Wovon hängt jetzt die Platzierung einer Fragestellung auf den beiden Achsen aus Bild 1 ab? Da spielen verschiedene Aspekte eine Rolle [3]. Für die Risikoachse sind das die folgenden:

• Die Entscheidung ist später nur aufwendig änderbar.
• Die Umsetzung ist eher aufwendig beziehungsweise teuer.
• Es gibt sehr hohe qualitative, also nicht funktionale Anforderungen.
• Die Integration in die bestehenden Teile ist schwierig beziehungsweise aufwendig.
• Im Team liegt nur wenig Erfahrung im Lösungsspektrum vor.

Auf der Dringlichkeitsachse befinden sich die folgenden Bewertungsaspekte:

• Termindruck kommt aus der Organisation oder von Kundenseite.
• Wenn man die Fragestellung weiter offenlässt, stellen sich negative Seiteneffekte ein.
• Ein weiteres Nichtentscheiden erhöht die Gefahr von impliziten De-facto-Entscheidungen.
• Es bestehen Abhängigkeiten zu anderen Entwicklungen oder Projekten.
• Es ist eigentlich alles so weit klar, und es kann guten Gewissens entschieden werden.

Die Metapher des LRM hilft uns dabei, Entscheidungen in eine Reihenfolge zu bringen und einen Zeitraum zu definieren, in dem wir Antworten auf bestimmte Fragen haben möchten, um zu lernen und die bestmögliche Entscheidung zu treffen. Doch was ist die bestmögliche Entscheidung? Woran orientieren wir uns, um unsere Ziele zu erreichen?

Satisficing

Mit agilen Vorgehensweisen entstehen Lösungen, die mit möglichst wenig Vorabanalyse auskommen und möglichst späte Grundsatzentscheidungen ermöglichen. Dabei wird das Konzept des Satisficing angewendet. Satisficing ist eine Wortschöpfung von Herbert A. Simon, die sich aus den englischen Begriffen satisfying und suffice zusammensetzt [4]. Damit wird eine Strategie bezeichnet, in der die erste ausreichend befriedigende Lösung umgesetzt wird, die den Zweck erfüllt, und nicht weiter nach einer optimalen Lösung gesucht wird.

Der eigene Begriff Satisficing ist auch deswegen eingeführt worden, um diese Vorgehensweise vom Prozess einer Optimierung abzugrenzen. Bei einer Optimierung wird so lange nach Lösungsalternativen gesucht, bis die bestmögliche gefunden ist. Beim Satisficing dagegen werden nur wenige, meist sogar nur zwei Alternativen betrachtet, bis eine ausreichend befriedigende Lösung gefunden wurde. Der Fokus liegt hierbei auf einem guten Aufwand-Nutzen-Verhältnis, weshalb zwar nicht perfekte, aber sehr kostengünstige Lösungen verfolgt werden. Gerade in komplexen Projekten sind Entscheidungsfindungen wie das Satisficing sinnvoll, bei denen der Realisierungsaufwand eher überschaubar und vergleichsweise gering bleibt, was die Kosten minimiert und es leichter macht, Termine einzuhalten.

In agilen Vorgehensweisen wird dies mit dem Wert der Einfachheit adressiert: What is the simplest thing that could possibly work? Dadurch, dass die Lösungen schneller fertig sind, bekommt man schneller eine Rückmeldung vom Auftraggeber beziehungsweise den Anwendern. Gerade dann, wenn dem Auftraggeber viele Aspekte und Konsequenzen seines Anforderungsbereichs noch nicht ganz klar sind, führt dieses Vorgehen der frühen Konkretisierung schneller zur Klarheit auf Auftraggeberseite. Das ist selbst dann ein Vorteil, wenn sich herausstellt, dass eine Lösung anders aussehen muss.

Auf einen tückischen Fehler bei der Umsetzung des agilen Werts der Einfachheit gilt es noch kurz hinzuweisen. Daran lässt sich erkennen, dass es für wirklich gute Entscheidungen von Vorteil ist, reichlich Erfahrungen gemacht zu haben. Der Wert von Retrospektiven kann dabei nicht hoch genug eingeschätzt werden. Ein falsch verstandener Wert der Einfachheit kann, wenn einfach mal drauflosgearbeitet wird, zu einem naiven beziehungsweise gar keinem Lösungsdesign führen, das viele Probleme bereiten wird. Mit einem einfachen Design dagegen werden möglichst einfache Strukturen angestrebt, sodass sich der Designaufwand besser über die Projektlaufzeit verteilen lässt. Damit ist explizit nicht gemeint, sich nur daran zu orientieren, was im Augenblick mit dem geringsten Aufwand erzielt werden kann, sondern die Aspekte des Software-Lifecycle wie Wartung und Erweiterungen mit zu berücksichtigen [2].

Fazit

Um herausfordernde Ziele für komplexe Aufgaben zu erreichen, ist die Art und Weise, wie und wann Entscheidungen getroffen werden, essenziell. Da wir Entscheidungen fast immer unter Unsicherheit treffen müssen, sind drei Konzepte zur Entscheidungsfindung besonders wertvoll. Wir zerlegen größere Entscheidungen in mehrere kleine, um sie dann nacheinander zu betrachten. Wir nutzen die Metapher des Last Responsible Moment, um das Lernfenster bis zum Treffen einer wichtigen Entscheidung zu maximieren. Dabei orientieren wir uns am Konzept des Satisficing, um jederzeit handlungsfähig zu sein und unerreichbaren Perfektionismus zu vermeiden.

Literatur

[1] Uwe Vigenschow, Björn Schneider, Ines Meyrose, Soft Skills für IT-Führungskräfte und Projektleiter, 3. Auflage, dpunkt.verlag, 2016

[2] Uwe Vigenschow, APM – Agiles Projektmanagement, dpunkt.verlag, 2015

[3] Stefan Toth, Vorgehensmuster für Softwarearchitektur, 4. Auflage, Hanser, 2025

[4] James G. March, Herbert A. Simon, Organizations, 2. Auflage, Blackwell Business, 1993