Worum es geht
Im Kern geht es um drei Dinge: Geld sparen, schneller arbeiten, und die Arbeit priorisieren, die tatsächlich zählt. Das lässt sich nur erreichen, wenn zuerst klar ist, wie teuer ein Problem tatsächlich ist — erst dann lässt sich beurteilen, ob eine Investition sich lohnt, und der Return messbar machen, statt ihn zu behaupten.
Das im Folgenden beschriebene Vorgehen — das Problem-Ownership-Modell — strukturiert, wie Business und IT gemeinsam ermitteln, welches Problem den größten finanziellen Unterschied macht, und wie diese Erkenntnis in messbare Ergebnisse übersetzt wird.
Ausgangslage: warum Kontrolle das falsche Werkzeug ist
Fehlendes Vertrauen zwischen Business und IT führt in vielen Organisationen zu Kontrollmechanismen: Status-Meetings, detaillierte Schätzungen, umfangreiche Lastenhefte. Diese Mechanismen sind gut gemeint — sie sollen Sicherheit schaffen. In der Praxis kosten sie jedoch IT-Zeit und -Fokus, was Ergebnisse verschlechtert und dadurch wiederum mehr Kontrolle nach sich zieht. Ein sich selbst verstärkender Kreislauf, der sich nicht durch noch mehr Kontrolle durchbrechen lässt, sondern nur durch eine andere Grundlage: verifizierbares Vertrauen.
Warum das gerade jetzt relevant ist
Künstliche Intelligenz macht die reine Umsetzung — das Schreiben von Code — zunehmend zu einer commoditisierten Fähigkeit. Die knapper werdende, wertvollere Fähigkeit ist Problemverständnis: zu wissen, welches Problem überhaupt gelöst werden sollte und warum. Das verschiebt den Wert innerhalb von IT-Teams strukturell.
Diese Verschiebung macht sichtbar, was schon immer galt, aber lange durch die schiere Arbeitslast des Programmierens verdeckt war: Gute Lösungen entstehen aus Teamarbeit, nicht aus Arbeitsteilung entlang starrer Grenzen. Business bringt das Wissen mit, welches Problem den größten Unterschied macht — es kennt die Kunden, die Zahlen, die strategische Richtung. IT bringt das Wissen mit, wie sich ein Problem tatsächlich lösen lässt — technisch fundiert, nachhaltig, ohne Folgeschäden an anderer Stelle. Keine der beiden Seiten kann die Aufgabe der anderen zuverlässig übernehmen, und keine sollte es müssen.
Wo das Modell wirkt — und wo nicht
Dieses Modell ist nicht für jede Art von IT-Arbeit geeignet. Bei reiner Wartung, Compliance-Anforderungen und regulatorischen Pflicht-Features bleibt ein klar definiertes Lastenheft der richtige Ansatz — hier besteht wenig Interpretationsspielraum, und der Nutzen einer offeneren Herangehensweise wäre gering. Das Modell entfaltet seine Wirkung bei Vorhaben mit echtem Lösungsspielraum: neuen Features, Prozessverbesserungen, allem, wo die Art der Lösung mehr Wert schafft als die reine Umsetzungsgeschwindigkeit einer vorgegebenen Spezifikation.
Voraussetzung: verlässliche Kundendaten
Bevor das Modell überhaupt greifen kann, muss eine Grundfrage geklärt sein: Verfügt die Organisation über verlässliche Quellen, um zu wissen, was bei Kunden tatsächlich geschieht? Dazu zählen Support-Tickets im Original, Nutzungsdaten, UX-Research und dokumentierte Abwanderungsgründe. Ohne diese Datenbasis lässt sich die zentrale Priorisierungsfrage — welches Problem ist am teuersten — nicht seriös beantworten.
Fehlt diese Infrastruktur, ist der sinnvolle erste Schritt nicht die Einführung des Gesamtmodells, sondern der gezielte Aufbau dieser Feedback-Infrastruktur als eigenständiger, vorgelagerter Schritt.
Grundprämisse: Priorisierung ist unausweichlich
Ideen zu entwickeln kostet nahezu nichts — ein Gedanke, ein Satz in einer Besprechung. Die Umsetzung dagegen kostet immer Zeit, Geld und Aufmerksamkeit, und diese Ressourcen sind endlich. Diese Asymmetrie erzeugt in jeder Organisation zwangsläufig mehr Ideen, als je umgesetzt werden können — unabhängig von der Qualität des Managements.
Priorisierung bedeutet deshalb nicht, dass am Ende alles umgesetzt wird, nur in der richtigen Reihenfolge. Sie bedeutet, bewusst zu entscheiden, was zurückgestellt wird, während Kapazität auf das Wichtigere konzentriert wird.
Die fünf Phasen des Modells
Phase 0 — Leitplanken definieren
Bevor IT mehr Lösungshoheit erhält, müssen die Rahmenbedingungen eindeutig geklärt sein. Mehr Autonomie für IT setzt mehr Führungsklarheit von Business voraus, nicht weniger. Zu klären sind: Budget- und Zeitrahmen als feste Grenze, ein definierter Eskalationspfad, klare Entscheidungsrechte, und explizit kommunizierte Werte und strategische Prioritäten (z. B. „in diesem Quartal hat Kundenbindung Vorrang vor Neukundengewinnung").
Der Berater Allan Kelly beschreibt, wie Product Owner ohne reale Entscheidungsbefugnis faktisch zu reinen Backlog-Administratoren werden — weil die Rolle zwar formal Verantwortung trägt, die Entscheidungsrechte jedoch nie explizit geklärt wurden. Das Muster betrifft nicht nur die PO-Rolle — es tritt bei jeder Position auf, die vermitteln soll, ohne dass Entscheidungsrechte klar zugewiesen sind.
Phase 1 — Direkter Zugang statt gefilterter Anforderung
IT erhält direkten Zugang zur eigentlichen Problemquelle: Kundengespräche, unbearbeitete Support-Tickets, Nutzungsdaten, relevante Geschäftskennzahlen — anstelle eines Lastenhefts, das bereits durch mehrere Ebenen interpretiert und gefiltert wurde. Praktisch lässt sich das umsetzen, indem einzelne Entwickler an ausgewählten Kundengesprächen teilnehmen, Lesezugriff auf Support-Dashboards erhalten oder an Quartals-Reviews der Geschäftsziele teilnehmen.
Phase 2 — Gemeinsames Problem-Briefing
Zu Beginn jedes Vorhabens findet ein kurzes, verpflichtendes Format statt (30–45 Minuten), in dem Business und IT gemeinsam vier Fragen beantworten — mit belastbaren Zahlen, nicht mit Einschätzungen allein:
- Business: Welches Problem verursacht den größten nachweisbaren Schaden? Priorisierung nach entgangenem Umsatz, Supportaufwand oder Kundenabwanderung — nicht nach Dringlichkeit des Vortrags.
- Business: Welche Art von Lösung ist angemessen? Ein kurzfristig entlastender Quick-Win, eine Kosteneinsparung oder eine langfristig wartbare Grundlage für weiteres Wachstum.
- IT: Welcher Aufwand ist zur Lösung realistisch zu erwarten? Eine Größenordnung, keine Scheingenauigkeit.
- IT: Wie lässt sich das Problem in nachvollziehbaren Teilschritten liefern? Eine Aufteilung, bei der jeder Abschnitt einen erkennbaren Mehrwert liefert.
Aus diesen vier Antworten ergeben sich das messbare Erfolgskriterium für das Vorhaben sowie die konkretisierten Leitplanken aus Phase 0.
Phase 3 — Lösungshoheit für IT
IT entwirft die Lösung eigenständig innerhalb der definierten Leitplanken. Die Bewertung durch Business erfolgt am Ende gegen das vereinbarte Erfolgskriterium, nicht gegen die Einhaltung einer detaillierten Spezifikation.
Phase 4 — Vertrauens-Ersatzmetriken statt Status-Meetings
Anstelle regelmäßiger Status-Updates werden asynchron einsehbare, automatisch aktualisierte Kennzahlen für beide Seiten bereitgestellt — etwa Deployment-Häufigkeit oder Fortschritt gegenüber dem vereinbarten Erfolgskriterium. Kontrolle wird durch Transparenz ersetzt.
Phase 5 — Review und kontrollierter Ausbau
Nach Abschluss jedes Vorhabens erfolgt eine kurze, gemeinsame Retrospektive: Wurde das Erfolgskriterium erreicht, wurden die Leitplanken eingehalten, wo entstand Reibung? Erst nach mehreren erfolgreich verlaufenen Durchläufen wird der Kreis der Vorhaben, auf die das Modell angewendet wird, schrittweise erweitert.
Einführung: Pilot vor unternehmensweiter Skalierung
Eine unternehmensweite Einführung auf einmal ist nicht empfehlenswert — sie würde Vertrauen eher kosten als aufbauen. Stattdessen empfiehlt sich: ein klar abgegrenztes Pilotprojekt mit vorab definiertem Erfolgskriterium, Messung nach Abschluss (Durchlaufzeit, Anzahl der Status-Meetings, Zielerreichung), und Ausweitung erst bei nachgewiesenem Ergebnis.
Häufige Einwände
Was, wenn IT das Problem falsch versteht und in eine falsche Richtung entwickelt?
Dafür sind der Eskalationspfad aus Phase 0 sowie die frühzeitige Sichtbarkeit aus Phase 4 vorgesehen — Abweichungen werden früh erkennbar, nicht erst am Ende eines Vorhabens.
Wir verlieren die Kontrolle über Budget und Zeitrahmen.
Budget und Zeitrahmen sind feste Leitplanken aus Phase 0, keine Verhandlungsmasse. Kontrolliert wird das Ergebnis, nicht der Weg dorthin.
Das funktioniert nur mit sehr erfahrenen Entwicklern.
Das trifft zu — und ist kein Nachteil des Modells, sondern eine seiner Wirkungen: Es macht sichtbar, wo im Team tatsächlich Problemlösungskompetenz vorhanden ist und wo gezielte Entwicklung sinnvoll wäre.
Anhang A: Methoden für die zwei zentralen Führungsentscheidungen
Wirksames Management trifft zwei Arten von Entscheidungen im Voraus, nicht im Einzelfall: Welches Problem hat Vorrang — und nach welchen Grundsätzen wird grundsätzlich gearbeitet?
A1. Finanziellen Wert eines Problems bemessen
| Methode | Was sie leistet | Bezug zum Modell |
|---|---|---|
| Cost of Delay (CoD) | Berechnet die Kosten, die entstehen, solange ein Problem ungelöst bleibt (Reinertsen). | Direkt anwendbar auf Phase-2-Frage 1. |
| WSJF | Aus SAFe: Cost of Delay geteilt durch Umsetzungsaufwand. | Verbindet Business-Frage 1 mit IT-Frage 3. |
| RICE-Scoring | Reichweite × Wirkung × Sicherheit, geteilt durch Aufwand. | Geeignet, wenn Nutzen nicht rein monetär ist. |
| Activity-Based Costing | Ordnet Kosten konkreten Geschäftsprozessen zu. | Liefert die Ausgangsdaten für CoD/WSJF. |
| Applied Information Economics | Quantifiziert schwer messbare Faktoren über Wahrscheinlichkeitsbereiche. | Nützlich bei nicht-monetärem Schaden. |
A2. Ziele und Werte festlegen und kommunizieren
| Methode | Was sie leistet | Bezug zum Modell |
|---|---|---|
| OKRs | Quartalsziele mit messbaren Ergebnissen, kaskadiert über Ebenen. | Liefert die strategische Priorität für Phase 0. |
| Hoshin Kanri | Strategie wird über eine X-Matrix auf die operative Ebene heruntergebrochen. | Definiert auch die Arbeitsweise, nicht nur das Ziel. |
| Balanced Scorecard | Verknüpft Finanz-, Kunden-, Prozess- und Lernperspektive. | Geeignet bei mehrdimensionaler Zielabwägung. |
| Amazon „Working Backwards" | Erfolg wird vor Projektbeginn konkret beschrieben. | Deckt sich mit dem Erfolgskriterium aus Phase 2. |
| Dokumentierte Leitprinzipien | Kurze, konkrete Prinzipien statt allgemeiner Werteaussagen. | Macht Arbeitsweise nachvollziehbar und wiederholbar. |
Praktisches Rechenbeispiel: Cost of Delay berechnen
Mit Platzhalterzahlen, die durch reale Unternehmensdaten zu ersetzen sind:
| Problem A: Abbruchrate im Checkout | Problem B: Veraltetes Styling im Admin-Panel | |
|---|---|---|
| Häufigkeit | 2.000 abgebrochene Warenkörbe/Monat | — |
| Anteil rettbar | 20 % würden bei Behebung kaufen | — |
| Ø Warenkorbwert | €80 | — |
| Kosten der Verzögerung | ≈ €32.000/Monat | ≈ €0 (kein direkter Umsatzeffekt) |
| Geschätzter Aufwand | 120 Std. × €33,60 ≈ €4.030 | 40 Std. ≈ €1.340 |
| Amortisationszeit | unter 1 Woche | nicht dringlichkeitsrelevant |
Problem A verursacht täglich höhere Kosten, als seine vollständige Behebung einmalig kosten würde — die Priorisierung ergibt sich aus der Rechnung, nicht aus subjektiver Einschätzung.
Was dieses Modell nicht ersetzt
Die fünf Phasen sind offen dargelegt und lassen sich grundsätzlich auch ohne externe Begleitung umsetzen. Erfahrungsgemäß scheitert die Einführung selten am Verständnis der Methode, sondern an drei anderen Stellen: der Moderation von Phase 0 (wo interne Versuche oft an denselben Konflikten scheitern, die das ursprüngliche Vertrauensproblem verursacht haben), der eigenen Zahlenbasis (oft lückenhaft oder verstreut), und der Phase nach der Einführung (wo gewohnte Kontrollstrukturen mit nachlassendem Anfangsschwung zurückkehren).