Decision Deadlock - Wenn ein Team feststeckt

“Bevor wir das jetzt live nehmen, müssen wir uns noch mit dem C-Level abstimmen. Das kann starke Implikationen auf unsere Sales haben.”

“Da muss ich mich noch mit meinem Head abstimmen.”

“Das betrifft das andere Team. Wir müssen noch klären, ob das so okay für sie ist.”

“Wir warten noch auf den Input der Agentur, aber dann müssen wir sofort loslegen sonst läuft uns die Zeit davon. Könnt ihr nicht schon was vorbereiten?”

Statt eine Entscheidung zu treffen und weiterzumachen, ist ein Team blockiert und kann nicht an der wichtigsten Sache arbeiten.

Es gibt eine (sehr) lange Liste von Bedenken, die immer wieder durchgegangen wird. Man springt von einem Punkt zum nächsten, stimmt sich hier und dort ab, ohne der Lösung auch nur ein kleines Stückchen näher zu kommen.

Die Deadline rückt immer näher und nichts passiert.

Das Team steck fest. Diagnose: “Analysis Paralysis” bzw. “Decision Deadlock”

Wie kommt ein Team da wieder heraus? Dazu müssen wir die Situation des Teams zuerst etwas genauer verstehen, insbesondere das Dilemma in dem es feststeckt.

Das Dilemma: schnell vs. abgesichert

Kurz zusammengefasst steckt das Team in folgendem Dilemma:

• Auf der einen Seite muss das Team jetzt loslegen und entscheiden, um rechtzeitig fertig werden zu können.

• Auf der anderen Seite darf darf das Team jetzt noch nicht loslegen und entscheiden, um alle relevanten Einflussfaktoren zu berücksichtigen sowie alle betroffenen Parteien abzuholen.

Beides muss gegeben sein, damit das Projekt erfolgreich ist: Das Team muss rechtzeitig fertig werden und alle relevanten Einflussfaktoren berücksichtigen sowie alle betroffenen Parteien abholen.

Um diesen scheinbaren Widerspruch zu lösen schauen wir uns die Annahmen hinter den Aussagen genauer an.

Die Annahmen

Wenn wir nicht alle relevanten Faktoren kennen, können wir nicht loslegen, weil sonst das Risiko besteht, Nutzer und damit Umsatz zu verlieren oder die Erwartungen an uns nicht zu erfüllen.

• Sehr wahrscheinlich kennt man nicht alle relevanten Faktoren, egal wie lange man analysiert. Es ist bei der Komplexität heutiger Systeme (damit meine ich nicht nur die Software, sondern das gesamte Unternehmen und dessen Kunden) unmöglich, alle Faktoren zu kennen und zu verstehen.

• Des weiteren besteht immer das Risiko, durch eine Änderung in der Software Umsatz zu verlieren. Das Risiko einer konkreten Änderung hängt von den Auswirkungen auf den Nutzer und der Möglichkeit die Änderungen rückgängig zu machen ab. Je geringer die Auswirkung auf den Nutzer und je leichter eine Änderung reversibel ist, desto geringer ist das Risiko.

Es ist deutlich teurer sich lange abzustimmen und zu warten, als gelegentlich etwas falsch zu machen.

• Diese Annahme steckt hinter dem ‘Bias to Action’. Dem Wunsch direkt loszulegen, ohne groß zu forschen. Leider stimmt diese Aussage nicht in allen Fällen. Wenn die Entscheidung z.B. dazu führt, dass User die Plattform nicht mehr richtig nutzen können, kann das sehr wohl hohe Kosten verursachen und starke Auswirkungen auf das Unternehmen haben. Insbesondere wenn es sehr aufwändig ist, die Entscheidung rückgängig zu machen. Möglicherweise ist der Image-Schaden dadurch auch gar nicht rückgängig zu machen.

Es gibt sicherlich noch jede Menge mehr Annahmen, die hinter diesem Dilemma stecken. Aber diese beiden helfen uns schon, uns einen Schritt näher in Richtung Lösung zu bewegen.

Die Lösung

Some decisions are consequential and irreversible or nearly irreversible – one-way doors – and these decisions must be made methodically, carefully, slowly, with great deliberation and consultation. If you walk through and don’t like what you see on the other side, you can’t get back to where you were before. We can call these Type 1 decisions. But most decisions aren’t like that – they are changeable, reversible – they’re two-way doors. If you’ve made a suboptimal Type 2 decision, you don’t have to live with the consequences for that long. You can reopen the door and go back through. Type 2 decisions can and should be made quickly by high judgment individuals or small groups. - Jeffrey P. Bezos

Mit seiner Aufteilung von Entscheidungen in Type 1 und Type 2 Entscheidungen liefert Jeff Bezos den ersten Baustein zur Lösung: Wenn eine Entscheidung leicht rückgängig gemacht werden kann (Type 2), lohnt es sich nicht viel und lange darüber zu reden, es ist einfacher zu handeln. Das passt gut zur Analyse der zweiten Annahme, ist aber aus meiner Sicht noch nicht ausreichend.

Eine weitere Dimension ergibt sich aus der Diskussion der Annahmen: Der Einfluss auf den Nutzer bzw. der Business Impact. Wenn eine Entscheidung keinen großen Einfluss auf den harten Business Value eines Unternehmens hat (wie z.B. die genaue Formulierung in einer Umfrage oder ein rein technisches Refactoring) kann anders vorgegangen werden als bei allem was sich direkt auf die Verkäufe auswirkt.

Damit kommen wir zu folgenden vier Fällen (siehe Abbildung 1):

Low Business Impact / Easily Reversible

Just do it. Hier gibt es keinen Grund große Abstimmungen Test oder ähnliches zu machen, diese Dinge können lokal im Team umgesetzt und live genommen werden. Beispiele sind:

• Änderungen einer Datenstruktur / kleinere Refactorings

• Alle Anpassungen, die nicht auf der zentralen User Journey liegen (Ausspielung von Nutzerumfragen, FAQ Seiten, Zusatzinformationen an verschiedenen Stellen… )

Low Business Impact / Hardly Reversible

Hier ist eine kurze Abstimmung mit oder Information an die Betroffenen Stakeholder sinnvoll. Beispiele finden sich hauptsächlich im Kontext von technischen Umbauten. Um das Risiko gering zu halten, ist es hier absolut sinnvoll (aus meiner Sicht) die Aufgabe in kleinere Schritte zu zerlegen, um so das Risiko gering zu halten und im Laufe des Prozesses schnell lernen und ggf. korrigieren zu können.

High Business Impact / Easily Reversible

Hier kann man gut den experimentellen Weg gehen. Sprich, kurze Abstimmung und dann testen, z.B. durch einen AB-Test oder Vorher/Nachher-Vergleich. Das betrifft vor allem Änderungen in der zentralen User Journey, wie zum Beispiel dem Kaufprozess bei einem Online-Shop.

High Business Impact / Hardly Reversible

Das ist die schwierigste Kategorie (Überraschung!). Die erste Frage, die man sich hier stellen sollte:

Gibt es eine Möglichkeit, das Problem in kleinere Schritte zu zerlegen, so dass man für jeden Schritt in einen anderen Quadranten landet?

Das ist fast immer möglich. Falls sich kein Weg findet, wird es allerdings spannend. Dann kann es tatsächlich notwendig sein, die große Runde zu drehen, alle abzuholen und so viel Informationen wie möglich zu sammeln. Ich persönlich bin aber kein großer Fan davon und würde alles daran setzen, das Problem in kleinere, risikoärmere Schritte zu zerlegen.

Fazit

Um den Decision Deadlock aufzulösen, sollte man zuerst verstehen, womit man es zu tun hat. Zwei Fragen muss man sich hier stellen:

• Wie stark ist der Einfluss auf den Nutzer / das Geschäft?

• Wie leicht ist die Änderung rückgängig zu machen?

Wenn man weiß wo man steht, kann man viel leichter bestimmen wie viel Abstimmungsaufwand und Absicherung notwendig sind, bevor man loslegen bzw. etwas live nehmen kann.

Sobald man feststellt, dass etwas schwer rückgängig zu machen ist, ist es - aus meiner Sicht - absolut notwendig, das große Ganze in kleinere Schritte zu zerlegen, um so das Risiko zu minimieren.