Neulich haben wir im “State of DevOps 2019“-Report die DevOps Lead Time als Metrik kennengelernt: von Commit (Code-Änderung übernommen in die Versionsverwaltung) bis zur Auslieferung in Produktion. Die besten Organisationen brauchen für diese Phase weniger als einen Tag, dann sind alle Tests abgeschlossen und man hat genügend Vertrauen, um diesen Code in Produktion zu geben.

Diese Vorlaufzeit zu verkürzen bringt viele Vorteile, u.a. schnellere Feedback-Zyklen in der Softwareentwicklung. Aber die Entwicklung macht oft nur einen Teil (manchmal einen kleinen Teil) der gesamten Zeit “von der Idee bis zur Umsetzung” aus. Genauso bedeutsam ist die Phase, bevor der erste Code geschrieben wird. Bei einem Bauvorhaben wäre das der Zeitraum von “Jemand möchte ein Haus bauen” bis zum ersten Spatenstich.

Man kann einige Zeitpunkte festlegen, die für die globale Durchlaufzeit in Projektorganisationen relevant sind.

1. Jemand hat eine Idee. Diese kann zielgerichtet auf eine neue Funktionalität oder Dienstleistung sein (“Wir sollten Kaffee im Abo anbieten”), oder das Wahrnehmen einer Veränderung bei Kundenwünschen (“Unsere Kunden erwarten, dass es dafür eine App gibt”) usw. Unvermeidliche Anforderungen von außen würde ich auch noch hier einordnen (“Wir müssen bis zum 1. Mai DSGVO-Konform werden”).
2. Ein Vorhaben wird formuliert. Es gibt also eine Beschreibung, was wir eigentlich machen wollen und warum wir es tun sollten, sowie eine Schätzung zum zeitlichen und finanziellen Aufwand.
3. Das Vorhaben wird als Projekt bewilligt. Das heißt, wir entschließen uns dazu, Geld für die Umsetzung auszugeben. Alle Vorhaben durchlaufen dazu einen “Projektfilter”, der nur wenige Vorhaben durchlässt und die anderen ablehnt oder verschiebt.
4. Erste Spezifikation ist geschrieben.
5. Erster Commit, d.h. die ersten Zeilen Code sind geschrieben.
6. Erster Test / erstes Demo
7. Erstes Release in den Produktivbetrieb
8. Letztes Release in den Produktivbetrieb, Beginn der Wartung

Wir hatten schon früher darüber gesprochen, warum kurze Durchlaufzeiten wichtig sind. Auf dem Weg zum ersten Commit (Zeitpunkt 5) wird oft unnötig Zeit verschenkt.

• Vom Vorhaben zum Projekt: Wenn Sie nur einmal im Jahr entscheiden, welche Projekte angefangen werden, verliert ein Projekt im ungünstigsten Fall ein ganzes Jahr (“Alle Mittel für dieses Jahr sind verplant, aber im nächsten Jahr kann es klappen.”) Das durchschnittliche Projekt verliert immer noch ein halbes Jahr. Wenn quartalsweise über den Start von Projekten entscheiden wird (weil irgendein Lenkungsausschuss tagen muss), verliert man immer noch durchschnittlich sechs Wochen.
• Von der Projektbewilligung bis zum ersten Commit: Hier verliert man Zeit durch Warten, weil Leute noch nicht verfügbar sind, weil Dienstleister noch angeheuert werden müssen usw. Auch die aufwendige Erhebung von Anforderungen, Ausschreibungen u.ä. gehören hierher.

Reinertsen hat (für die Produktentwicklung) den Begriff vom “Fuzzy Front End” geprägt, d.h. alles, was vor dem eigentlichen Start stattfindet. Im Gegensatz zum Projektmanagement, das viel Aufmerksamkeit der Manager und Methodenvertreter bekommt, ist dieser Zeitabschnitt relativ unstrukturiert und unterbelichtet. Sicher, man muss andere Maßstäbe anlegen, um die Reifung von Ideen zu sinnvollen Projekten sinnvoll zu gestalten.

Das Schöne am “Fuzzy Front End” ist, dass man in diesen frühen Phasen manchmal mit wenig Aufwand die globale Durchlaufzeit erheblich verkürzen kann. Schon das Aufzeigen der Vorlaufzeiten und etwas Nachdenken darüber, wie sie zu verkürzen wären, kann helfen. Hier ein paar weitere Anstöße:

• Kleinere Projekte machen. Wenn Zeit und Budget geringer sind, kann man schneller entscheiden. Unsere Empfehlung im Flow Check lautet: maximale Projektlaufzeit 6 Monate.
• Ein standardisiertes Format für Vorhaben entwickeln, das keine unnötigen Hürden aufbaut und schnelle Entscheidungen unterstützt.
• Häufiger entscheiden, das verkürzt die Wartezeit bis zu einer Entscheidung.
• Kapazität im Reserve halten, damit man nötigenfalls nicht bis zum Ende eines anderen Projektes auf Ressourcen warten muss.
• Und schließlich: Projekte in Produkte transformieren.

Beim letzten Punkt können die “Kunden” dieser Produkte auch interne Abteilungen bzw. Geschäftsprozesse sein. Im Gegensatz zu Projekten werden Produkte laufend weiterentwickelt, es gibt langfristig stabile Teams, ein stabile Finanzierung, und ein kontinuierliches Feedback zum Erfolg (am Markt, oder innerhalb der eigenen Organisation). Wenn man immer kleinere Projekte macht, wird aus Projektmanagement allmählich Produktmanagement, aus Mini-Projekten werden auf diesem Weg einzelne Features bzw. Gruppen von Features.

Haben Sie eine Vorstellung davon, wieviel Zeit Projekte in Ihrer Organisation im “Fuzzy Front End” verbringen?

Matthias Berth