The Phoenix Project – Buchnotizen zum Roman über IT Projekte in Unternehmen

Bereits sechs Jahre vor der Veröffentlichung von „The Unicorn Project“ erschien im Jahr 2013 vom gleichen Autor das Buch „The Phoenix Project – a novel about IT and DevOps“. Die Art der Erzählung und das Setting sind recht ähnlich, nur diesmal aus der Sicht des frisch beförderten Leiters von IT Operations, Bill Palmer.

Nachdem einige hohe IT Manager aus mysteriösen Gründen das Unternehmen verlassen haben bzw. mussten, wird Bill vom CEO genötigt, die Lücke zu füllen und beauftragt, dem Chaos und der Ineffizienz Herr zu werden. Alle Leute in der IT Abteilung sind Land unter mit Arbeit, aber der Output ist mäßig bzw. absolut enttäuschend aus Sicht der Business-Abteilungen. Das millionenschwere IT Hoffnungsprojekt „Phoenix“, mit dem die Firma verlorene Marktanteile zurückgewinnen will, ist trotz jahrelanger Entwicklung noch nicht live, d.h. hat bisher nur Kosten produziert ohne jeglichen Output. Zudem mahnen externe Auditoren zahlreiche IT Probleme in der Firma an, insbesondere bzgl. Datenschutz und Compliance. Dem Management erscheint als einziger logischer Schritt ein Outsourcing der gesamten IT, verbunden mit einer Personalreduzierung vor Ort.

Im Laufe der Geschichte wird Bill ständig mit neuen Herausforderungen konfrontiert. Gleich an seinem ersten Tag fällt das System zur Gehaltsauszahlung aus, weitere Vorfälle dieser Art folgen. Über die Zeit gelingt es ihm jedoch immer mehr, durch diverse Maßnahmen das Ruder herumzureißen und Verbesserungen zu erzielen. Dabei bekommt auch er Unterstützung von einem Mentor, der ihm vor allem klarmacht, dass klassische industrielle Fertigung und Arbeit in der IT, speziell Operations, mehr gemein haben, als man zunächst denken mag. Prinzipiell geht es um das Management und die Maximierung von „Flow“, d.h. die anfallenden Aufgaben zügig zu Ende zu bringen. Dabei lassen sich vier grundsätzliche Arten von Arbeiten im IT Betrieb unterscheiden:

1. Business Projekte
2. Interne IT Projekte
3. Changes
4. Ungeplante Arbeit / Firefighting

Nicht immer sind hier die Grenzen klar zu ziehen, daher ist es wichtig, hierfür ein gemeinsames Verständnis zu entwickeln. Was z.B. verstehen wir genau unter einem „Change“? Eine mögliche Definition: „Jede Aktivität, physisch, logisch oder virtuell, an Anwendungen, Datenbanken, Betriebssystemen oder Netzwerken, die einen Einfluss auf Services / Dienste haben könnte.“

Sollte Typ 4 ein wesentlicher Teil der täglichen Arbeit sein, so ist dies ein eindeutiger Indikator dafür, dass einiges im Argen liegt und die IT ständig nur reagiert, d.h. von ungeplanten Ereignissen wie plötzlichen Systemausfällen oder unerwarteten Seiteneffekten getrieben wird. Arbeit von Typ 4 ist immer dringend und raubt Zeit für die eigentlich wichtigen Arbeiten (Typ 1 -3). Dieser Anteil bzw. die Veränderung über die Zeit kann auch zur Messung einer allgemeinen Verbesserung genommen werden. Hier spielen auch die „Technischen Schulden“ als weiterer Treiber eine wesentliche Rolle. Sie müssen kontinuierlich zurückgezahlt werden, sonst steigen die „Zinsen“ immer mehr, meist in Form von Arbeit vom Typ 4.

Die Zielsetzung von IT Operations lässt sich daher so zusammenfassen: Eine schnelle, berechenbare und ununterbrochene Bearbeitung von geplanten Arbeiten sicherzustellen, die einen Mehrwert für das Geschäft schaffen, sowie gleichzeitig den Einfluss und die Unterbrechungen durch ungeplante Arbeiten zu minimieren, um damit einen stabile, vorhersehbare und sicheren IT Service zu bieten.

Im Buch werden dazu einige Maßnahmen thematisiert. Zunächst arbeitet Bill daran, den Change Management Prozess wieder zu beleben, der von den Beteiligten schon seit längerem bewusst ignoriert wird: Zu komplex, zu praxisfern, unnötige Bürokratie ohne Mehrwert. Vielmehr hat sich die allgemeine Überzeugung festgesetzt, außerhalb des Prozess am besten voran zu kommen. Doch nur wer durchgeführte sowie geplante Änderungen kennt, kann steuernd eingreifen und Abhängigkeiten frühzeitig erkennen. Einige der unerwarteten Systemausfälle hätten sich so verhindern lassen. Primäres Ziel ist daher die Schaffung von „situational awareness“, d.h. Lagebewusstsein und kontinuierliches Monitoring der Systeme.

Steuerung bedarf es auch, um einen weiteren stillen „Killer“ einzudämmen: „Work in Progress“, d.h. die Anzahl gleichzeitig bearbeiteter Aufgaben. Bevor eine Aufgabe abgeschlossen ist, werden zu gerne neue angefangen, so dass an zu vielen Sachen parallel gearbeitet wird und der Durchsatz leidet. Hier hilft beispielsweise ein einfaches Kanban Board, um einen Überblick über die aktuell im Bearbeitungsprozess befindlichen Aufgaben zu gewinnen und den „Parallelisierungsgrad“ zu steuern. Manchmal kann auch ein kompletter „Feature-Freeze“ oder die komplette Fokussierung auf ein wichtiges Projekt angezeigt sein.  

Arbeit fällt besonders dort an, wo sie erledigt wird. So gibt es in jedem Unternehmen meist einige wenige Schlüsselpersonen, die aufgrund ihrer großen Expertise besonders gerne bei Problemen oder auch wiederkehrenden Aufgaben hinzugezogen werden, gerne in direkter Ansprache, auf dem „kleinen Dienstweg“. Nicht selten wird ihre Mitarbeit sogar schon fest eingeplant, und das gleich mehrfach, oder es folgt ein Feuerwehreinsatz nach dem nächsten (Typ 4), so dass die eigentliche Arbeit ständig liegen bleibt. Bekanntlich ist die Arbeitskapazität jeder menschlichen Ressource beschränkt und so entstehen nicht nur viele Abhängigkeiten, sondern vor allem Engpässe in der Abarbeitung. Das Management muss daher den Arbeitszufluss an diese kritischen Ressourcen steuern und direkte Anfragen „von der Seite“ fernhalten. Auch ist es hilfreich, wiederkehrende Arbeiten zu dokumentieren bzw. zu standardisieren und dann an andere, ggf. noch weniger erfahrene Kollegen zu delegieren, auch wenn das zu anfangs eventuell etwas länger dauert.

Ziel sollte es ohnehin sein, wo immer möglich, eine Automatisierung anzustreben und den Menschen mit seinen unvorhersehbaren Fehlern aus dem Prozess zu nehmen. Dies gilt besonders beim (Build- und) Deployment Prozess, d.h. wenn verschiedene Softwarekomponenten zusammengeführt und bereitgestellt werden. Wie in der klassischen Fertigung haben kleine Losgrößen ihre Vorteile, da die Abhängigkeiten (meist) noch überschaubar sind und möglichen Fehlerquellen klein gehalten werden. D.h. lieber öfter (täglich, wöchentlich oder auch mehrmals täglich), als nur alle paar Monate als große Aktion, bei der dann erst mal nichts zusammenpasst und ein Großteil der Beteiligten nur genervt ist.

Im Buch gibt es dazu als Paradebeispiel die von oben verordnete Produktivsetzung von „Phoenix“. Aus Sicht der Managements wurde nun lange genug entwickelt und so wurde von oben einfach ein Termin festgelegt, unterstützt durch externe Marketingmaßnahmen, um den Druck zu erhöhen. Als Antwort auf Bedenken und Warnungen, von denen, die sich technisch auskennen, gibt es Durchhalteparolen wie „Wer ein Omlette will, muss bereit sein, Eier zu zerschlagen“. So kommt es dann auch, dass trotz durchgearbeiteter Nächste alles nur noch schlimmer wird und man Tage mit Schadensbegrenzung beschäftigt ist.

Leider ist IT Operations ja immer am Ende der Kette, d.h. es sind die, die es schließlich zum Laufen bringen müssen und damit schnell als Schuldige ausgemacht werden. Aus Managementsicht stellt sich dies dann meistens so dar, dass ja eigentlich alle bereit waren, außer eben die Kollegen vom IT Betrieb, die es – mal wieder – im letzten Moment verbockt haben.

Ohnehin fühlt und beklagt das Business die ständige Abhängigkeit von der IT. Sie fühlen sich eingeschränkt, weil ihre tollen Ideen und Projekte ewig in der Umsetzung hängen und (gefühlt) einfach nichts vorangeht. Gleichwohl sind die Wertschätzung und Bereitschaft für ausreichendes Budget eher gering. So kommt Bill schnell zu der Erkenntnis, dass die anstehenden Aufgaben mit der aktuellen Besetzung nicht zu leisten sind. Er opfert sein Wochenende für eine Präsentation, mit der er den Bedarf an mehr Personal vor seinem CEO fundiert begründen möchte. Leider wird seine Audienz wegen wichtigerer Termine auf 20min zusammengestrichen und er schnell mit dem Vorwurf rausgeschickt, dass die IT Kosten eh schon so hoch sind und der Output aktuell zu wünschen übriglässt. Die aufwändig erstellte Präsentation wandert ungezeigt in den Papierkorb.

Eigentlich sollte es ja eher umgekehrt sein, d.h. IT sollte sich (pro-)aktiv an den Business Zielen ausrichten. So sucht Bill im zweiten Teil des Buches auch verstärkt das direkte Gespräch zum CFO und COO, um unmittelbar zu erfahren, auf welche Zahlen sie schauen und wo der Schuh am meisten drückt, um damit Ansatzpunkte für eine spürbare Unterstützung zum Erreichen dieser Ziele abzuleiten. Damit gewinnt er schließlich deutlich an Wertschätzung und schafft neue Ebenen der Zusammenarbeit. Schließlich ist IT in der heutigen Zeit nicht nur eine Abteilung innerhalb eines Unternehmens, sondern eine Kompetenz der gesamten Organisation, um am Markt zu bestehen.

Neben den vier Typen von Arbeit spricht der Mentor auch immer wieder die drei Wege (oder auch Prinzipien) einer effizienten IT Organisation an, besonders im Zusammenspiel von Entwicklung (DEV) und Betrieb (OPS):

1. Flow-Prinzip: Reibungslose und direkte Zusammenarbeit und Fluss von Arbeit zwischen Entwicklung (DEV) und Betrieb (OPS)
2. Feedback-Prinzip, als fester Bestandteil der Prozesse, z.B. um Qualitätsprobleme an der Quelle zu beheben und Doppel-/ Nacharbeiten zu vermeiden
3. Schaffung einer Kultur des kontinuierlichen Lernens und Experimentierens, Praxis und Wiederholung als Voraussetzung für die Meisterstufe.

Grundsätzlich haben Entwicklung und Betrieb erst einmal sehr gegensätzliche Zielsetzungen. Während Entwickler schnellstmöglich auf Veränderungen reagieren müssen und das System verbessern/ weiterentwickeln wollen, ist der Betrieb für stabile, verlässliche und sichere Systeme und Services verantwortlich. Die Verbesserung der Zusammenarbeit zwischen den Abteilungen durch eine entsprechende Kultur und unterstützende Werkzeuge ist daher essentiell. So entstand vor einige Jahren das Kofferwort DevOps und damit auch gleich eine ganze Bewegung, um IT (Groß-) Projekte möglichst reibungsfrei zum nachhaltigen Erfolg zu führen. Dies schließt natürlich auch die anderen Beteiligten im IT Prozess mit ein, wie beispielsweise IT Sicherheit oder die Qualitätskontrolle (Test), die gerne auch als Fortschrittsverhinderer gesehen werden. Viele der im Roman dargestellten Punkte werden auch im DevOps Handbuch aufgegriffen, ebenfalls (u.a.) vom gleichen Autor. Interessanterweise empfehlen einige Kommentatoren, dass sich die im Handbuch dargelegte eher trockene Theorie am besten mit dem Lesen des Phoenix Project verstehen lässt. 

Fazit: Auch wenn das Buch nun fast schon 10 Jahre am Markt ist, habe ich es leider erst vor kurzem empfohlen bekommen. Meines Erachtens hat es jedoch trotz der Schnelllebigkeit der IT nichts an Relevanz verloren. Natürlich sind einige angeführten „Innovationen“ (z.B. Cloud-Computing) heute Standard, die organisatorischen Herausforderungen in der menschlichen Zusammenarbeit mit ihren Facetten und Interessen haben sich jedoch kaum verändert. So lesen sich auch einige jüngere Kommentare zum Buch: „War der etwa bei uns in der Firma?“

Die unterschiedlichen Charaktere bieten eine Vielzahl von Perspektiven, nicht nur aus Führungssicht, sondern auch „von unten“. Hier liegt meines Erachtens der größte Mehrwert: Die verschiedenen handelnden Personen einer Organisation mit ihren Zielen und Sichten auf die Herausforderungen besser zu verstehen. Natürlich sind die vorgestellten Lösungen nicht erschöpfend, letztendlich muss jede Organisation ihren Weg mit ihrem Personal finden. Ich kann daher die beide Bücher „Phoenix & Unicorn Project“ jedem empfehlen, der in einer großen Organisation arbeitet, egal auf welcher Ebene, und Bezug zu IT Projekten haben heutzutage eigentlich fast alle. Die Story würde meines Erachtens auch genug Stoff für einen unterhaltsamen (Lehr-)Film abgeben.