Projektrettung

Delivery-System eines B2B-SaaS-Anbieters neu aufgebaut: 220 Tsd. € Umsatzverlust pro Monat aufgedeckt

220 Tsd. €/Monat: sichtbarer Umsatzverlust aufgedeckt
>90 %: der User Stories hatten keinen Bezug zu einer Business Capability
100 %: des Backlogs nach dem Umbau auf Geschäftsergebnisse zurückführbar

Eine senkrechte Leiter mit Sprossen von Ideen über Opportunities, Business Capabilities, Features, User Stories und Sprints bis zu Releases. Die Sprosse für User Stories ist pink umrandet, eine Linie führt von dort hinauf zu den Business Capabilities. — Abb. 01: Die neu aufgebaute Delivery-Hierarchie. Jede User Story lässt sich bis zu einer Business Capability und einem Geschäftsziel zurückverfolgen.

Fallakte

Branche: B2B-SaaS, Produkt mit vielen Integrationen
Region: Europa
Leistung: Projektrettung / Engineering Operating System
Team: Wayne ArendseLeiter Delivery & TransformationYurii KotulaCEO & Leiter Engineering
Systeme: Jira, von Grund auf neu strukturiert

Über den Kunden

Ein europäischer B2B-Softwarehersteller mit einem Produkt, das von vielen Integrationen lebt, und einer langfristigen kommerziellen Roadmap.

Intelvision war bereits mehr als drei Jahre als fest eingebundener Engineering-Partner tätig, bevor es dieses Audit anstieß. Der Kunde hatte das Audit nicht angefragt. Die Delivery-Daten schon.

Das geschäftliche Problem

Die Entwicklung hatte sich unbemerkt von den Geschäftsergebnissen gelöst. Tickets wurden erledigt, Releases gingen raus, aber welchen Wert die Arbeit hatte, war nicht mehr klar.

Ideen wurden nicht systematisch erfasst. Es wurde mehr angefangen als abgeschlossen, der Work in Progress wuchs, und über Systemverfügbarkeit und fehlgeschlagene Integrationen gab es nur wenig Transparenz. Es gab immer wieder Nacharbeit.

Was auf dem Spiel stand

Rund 220.000 € pro Monat an sichtbaren finanziellen Verlusten durch potenziell entgangenen Umsatz.
Rund 315.000 € Umsatz pro Monat, der potenziell gefährdet war.
Bis zu 400.000 $ pro Jahr an Kosten durch mangelnde Qualität, das entspricht rund 10 % des gefährdeten Jahresumsatzes.

Was nicht funktionierte

Über 90 % der User Stories hatten keinen Bezug zu irgendeiner Business Capability
Ideen und Opportunities wurden nicht systematisch erfasst
Mehr angefangen als abgeschlossen: Der Work in Progress lief aus dem Ruder
Wenig Transparenz über Systemverfügbarkeit und fehlgeschlagene Integrationen
Ständige Nacharbeit band Kapazität im Engineering

Vorgehen bei der Diagnose

Die Intervention setzte auf drei Ebenen gleichzeitig an, denn das Leck saß nie nur an einer Stelle.

Strategie
Wozu dient die Arbeit?
Die Produktrichtung wurde ausformuliert, die Business Capabilities wurden kartiert und die kommerziellen Prioritäten festgelegt.
- Produktrichtung ausformuliert
- Business Capabilities kartiert
- Kommerzielle Prioritäten festgelegt
Abläufe
Wie wird aus Arbeit Wert?
Die Prioritäten wurden in Epics, Features und Release-Pläne übersetzt, die jeweils an Capabilities hängen.
- Prioritäten in Epics und Features übersetzt
- Release-Pläne an Capabilities gekoppelt
- Zyklus von Sprint bis Release auf das Abschließen ausgerichtet
Technologie
Zeigt das System, wie es wirklich steht?
Das Delivery-System wurde so umgebaut, dass sich jede Story auf Features, Capabilities und Geschäftsziele zurückführen lässt.
- Lückenlose Nachverfolgbarkeit durchgesetzt
- Delivery-Daten sichtbar gemacht
- Qualität und Verfügbarkeit messbar gemacht

Was sich geändert hat

Das Delivery-System wurde für lückenlose Nachverfolgbarkeit neu aufgebaut
Jira wurde zu einem durchgängigen Delivery-System für das Produkt umgebaut, mit einer strengen Hierarchie: Ideen → Opportunities → Business Capabilities → Features → User Stories → Sprints → Releases. Jede User Story muss sich jetzt nach oben bis zu einer Capability und einem Geschäftsziel zurückführen lassen.
Investitionsentscheidungen fallen jetzt vor der Arbeit
Seit sich jedes Backlog-Item auf eine Capability, eine Priorität der Roadmap, einen Kundenbedarf und ein kommerzielles Ergebnis zurückführen lässt, kann das Management Investitionen bewerten, bevor die Arbeit beginnt, und nicht erst, wenn sie ausgeliefert ist.
Kennzahlen für die Steuerung eingeführt
Drei Kennzahlen steuern jetzt das System: First-Time Yield, Systemverfügbarkeit und Transparenz sowie Work in Progress.

Entscheidungen

Nachverfolgbarkeit als feste Regel
Keine User Story kommt in einen Sprint ohne übergeordnetes Feature, ohne Capability und ohne Geschäftsziel. Keine Richtlinie, sondern ein Gate.
Abschließen vor Anfangen
Der Zyklus von Sprint bis Release wurde darauf ausgerichtet, Arbeit fertigzustellen. Der Work in Progress wird dabei bewusst gesteuert.
Kennzahlen, die aufdecken statt schmücken
First-Time Yield, Systemverfügbarkeit und WIP wurden gewählt, weil jede dieser Kennzahlen eine bestimmte Art von Fehler sichtbar macht.

Ergebnisse

Kennzahl	Vorher	Nachher
Nachverfolgbarkeit von Story zu Capability	<10 % verknüpft	100 % nachverfolgbar
Umsatzverlust	~220 Tsd. € pro Monat sichtbarer Verlust	Erkannt, beziffert und auf Systemebene angegangen
Investitionsentscheidungen	Bewertet nach der Auslieferung, wenn überhaupt	Bewertbar, bevor die Arbeit beginnt
Kennzahlen für die Steuerung	Aktivitäts-Reporting	First-Time Yield, Systemverfügbarkeit, WIP

Strike Team

Erfahrene Engineering-Leads finden in einer Engineering Diagnostic zum Festpreis den eigentlichen Engpass und bleiben, bis er behoben ist. Project Rescue, Fractional CTO, Architektur und Business Cases.

Mehr zum Strike Team