Anatomie eines gescheiterten Projekts: Wie eine fehlende DoA 500.000 Euro verbrannt hat

Wie ein fehlendes „D“ ein Projekt kippt

Die Geschichte beginnt harmlos: Ein cross-funktionales Projektteam soll einen neuen Service aufsetzen. Budget: 500.000 Euro, Zeitplan: 9 Monate, Beteiligte aus Produkt, IT, Vertrieb und Operations. Die Fachseite ist überzeugt, die IT ist motiviert, das Management will „Endlich Tempo“.

Die Szene: Viele Meetings, wenige Entscheidungen

In den ersten Wochen läuft alles scheinbar gut: Kick-off, Workshops, erste User Stories, bunte Boards. Doch nach 3–4 Monaten kippt die Stimmung. Symptome:

• Entscheidungen werden immer wieder „mitgenommen“ und tauchen in der nächsten Runde wieder auf.
• Tickets werden „on hold“ gesetzt, weil Freigaben fehlen.
• Teams arbeiten an unterschiedlichen Annahmen, weil niemand die Richtung final gesetzt hat.
• Die Projektleitung moderiert, dokumentiert, erinnert – entscheidet aber nicht.

Nach außen sieht es nach normalem Projektstress aus. Intern fühlt es sich an wie Dauerschleife.

Wo die 500.000 Euro verschwinden

Wenn man den Case rückwärts durchrechnet, zeigt sich, wo das Budget tatsächlich verbrannt wurde:

• Meeting-Overhead: Führungskräfte verbringen 3–5 Stunden pro Woche in Abstimmungsrunden, in denen dieselben Themen wieder aufgerufen werden.
• Rework: Funktionen werden entwickelt, zurückgebaut und neu entschieden, weil die ursprüngliche Entscheidung nie sauber getroffen oder dokumentiert wurde.
• Wartezeiten: Teams stehen, weil unklar ist, wer bei Konflikten oder Unsicherheiten die Entscheidung hat.
• Schattenprojekte: Bereiche starten „eigene Lösungen“, weil sie der zentralen Entscheidung nicht mehr trauen.

In Summe ist das kein „bisschen Reibung“, sondern massiver Wertverlust. Die eigentlichen Kosten liegen in Stunden, Verzögerungen und Opportunitäten – nicht nur im Beraterhonorar.

Die eigentliche Ursache: Niemand hatte offiziell die Entscheidung (DoA)

Wenn man die Timeline auf eine einzige Frage herunterbricht, landet man bei einem simplen Muster:

Wer hat bei diesem Thema die Entscheidung?

Im Case oben war die Antwort diffus:

• „Eigentlich entscheidet das Steering Committee.“
• „Fachlich müsste es doch Produkt entscheiden.“
• „IT hat ja die Umsetzung, also müssen sie am Ende zustimmen.“
• „Das hängt noch an der Bereichsleitung.“

Mit anderen Worten: Keiner hat die Entscheidung – alle irgendwie mit. Es gab keine klar definierte Delegation of Authority (DoA) für Kernentscheidungen des Projekts. Damit fehlte:

• ein klarer Decision Owner (D),
• ein definierter Schwellenwert (bis wann darf das Team entscheiden, ab wann geht es hoch?),
• ein schlanker Eskalationspfad, wenn es hängt.

Wie Decision-Governance den Schaden begrenzen würde

Mit sauberer Decision-Governance hätte derselbe Case anders ausgesehen. Konkret:

• DoA-Matrix: Für die 5–7 wichtigsten Entscheidungstypen im Projekt ist festgelegt, wer entscheiden darf, wer einbindet, wer informiert wird.
• RACI/RAPID: Rollen sind pro Entscheidungstyp geklärt – nicht pro Workshop. Das reduziert Streit um „wer darf das überhaupt entscheiden?“.
• Decision-Log: Jede wesentliche Entscheidung hat einen Eintrag: Kontext, Variante, Entscheidung, Owner, Datum, nächster Review. Nachjustieren ja – aber nicht jedes Mal bei Null anfangen.
• Standard-Gremien: Es ist klar, welche Entscheidungen in welchem Takt wohin gehören (operativ, taktisch, strategisch).

Der Unterschied ist kein perfektes Lehrbuchmodell, sondern ein deutlich geringerer Budget-Verlust – und eine bessere Chance, das Projekt überhaupt zu einem sinnvollen Ende zu bringen.

Was Sie aus diesem Case mitnehmen können

Wenn Ihnen diese Szenen bekannt vorkommen, lohnt ein nüchterner Blick auf Ihre Decision-Governance:

• Erkennen Sie „Dauerthemen“, die immer wieder auf dem Tisch landen?
• Gibt es Entscheidungen, für die niemand offiziell das „D“ hat?
• Werden Entscheidungen in einem einfachen Log nachgehalten – oder leben sie in E-Mails & Folien?
• Wissen Teams, bis zu welchem Budget/Risiko sie selbst entscheiden dürfen?

Mit Decision-OS setzen wir genau hier an: Wir schaffen Klarheit über Rollen, DoA und Entscheidungswege – und machen die Kosten von Nicht-Entscheidungen sichtbar.

Im nächsten Schritt geht es nicht um „noch ein Framework“, sondern um ein leichtgewichtiges Decision-OS, das Ihre bestehende Organisation befähigt, schneller und klarer zu entscheiden – bevor das nächste 500.000-Euro-Projekt in der Schleife hängen bleibt.