Am Freitagmorgen muss Alex eine Nachricht an die ganze IT-Abteilung und an fast alle anderen Abteilungen des Unternehmens senden. Inhalt: "Das Software Release, das wir letzten Montag eingespielt haben, wird wegen anhaltender technischer Probleme mit der Anbindung unserer externen Datenlieferanten zurückgesetzt. Ab nächsten Montag steht wieder die vorherige Releaseversion zur Verfügung."

Das ganze Projektteam, Alex eingeschlossen, ärgert sich. Die Arbeit von mehr als drei Monaten wird quasi auf den Anfangszustand zurückgesetzt. So erscheint es jedenfalls den (unbeteiligten) Lesern von Alex Nachricht. Hinter den Kulissen ist ein ganzes Entwicklerteam mit Bugfixing und Testen beschäftigt. Alex ist vor allem deswegen so verärgert, weil sie diese Situation vorausgesehen hatte. Was war geschehen?

Während der Testphase des Release hatte der Fachbereich neue Funktionen gefordert. Alex hatte sich daraufhin dafür ausgesprochen, das Risiko des Rollbacks auf der Risikoliste ganz nach oben zu setzen. Anschließend hatte es Gespräche mit dem Lenkungskreis des Projekts gegeben. Alle anwesenden Bereichs- und Abteilungsleiter waren der Meinung, Alex schätze die Situation viel zu pessimistisch ein: In den letzten Versionen gab es zwar auch immer mal Schwierigkeiten, aber keine gravierenden Fehler.

Bis die Finger glühen

Soweit Alex sich erinnerte, hatte sie ein Einspeisen neuer Anforderungen während der Testphase noch nicht erlebt. "Ja, wir übernehmen die Verantwortung dafür", lautete die lapidare Antwort der verantwortlichen Führungskräfte aus der Fachabteilung. Natürlich wurde diese Funktionen dann "mit heißer Nadel gestrickt", nicht ausreichend getestet und zu allem Überfluss die Anbindung externer Datenlieferanten schlichtweg vergessen.

Wer hat Schuld? Klar, das Entwicklerteam, das die Fehler programmiert hat. Oder doch eher die Führungskräfte, die ein "Nein" aus dem Projekt nicht akzeptierten und mit viel Druck Ihre Änderungen durchgesetzt haben?

Nimmt man während der Testphase neue Anforderungen in ein Projekt auf?

Nie im Leben. Das ist viel zu spät, die Anforderer sollen auf das nächste Release warten (Projektmanagement-Grundkurs, 1. Semester).

1. Passiert das trotzdem?
   Ja, leider.
2. Warum?
   siehe Frage eins.
3. Handelt es sich dabei um eine Ausnahme?
   Nein, ist es nicht.
4. Hat Alex darauf hingewiesen?
   Ja, hat sie.
5. Konnte sie die Entscheidung des Bereichsleiters aus der Fachabteilung beeinflussen?
   Nein, denn der interessierte sich nicht für technische Details aus der IT. Das ist schließlich Alex' Aufgabe.
6. An welcher Stelle hätte Alex "Nein" sagen sollen?

Falsche Frage. Alex hat Nein gesagt. Es hat nur niemanden interessiert, der die Auftraggeber-Rolle des Projekts vertreten hatte. "Ihr habt das in der IT doch bisher auch immer hingekriegt.", lautete die Antwort. Die Fachabteilung hat Alex' Nein nicht gehört, weil die Kollegen nicht gewohnt sind, dass die IT sie mit Regeln und Einschränkungen konfrontiert.

Das Problem liegt im Umfeld

Ein Projekt kann immer nur so gut geplant werden, wie das Umfeld es zulässt. Wenn die Rahmenbedingungen nicht "zuverlässig" sind – d.h. das ursprünglich vereinbarte im Laufe des Projekts immer wieder abgeändert wird – kann das Projekt auch keine zuverlässige Qualität abliefern. Alle Stellschrauben in der Projektplanung und im Risikomanagement helfen dann nicht weiter.

Dass nach Beginn der Implementierung keine Änderungen mehr zugelassen werden darf, weil sonst das Ergebnis in Gefahr gerät oder gleich die ganze Arbeit vergeblich ist, stellt eine Binsenweisheit im Projektmanagement dar.

Alex hat eine neue Rolle in ihrer Projektorganisation entdeckt: den "Manager für Binsenweisheiten", der vor allem alle Beteiligten, die eher selten mit dem Projekt in Kontakt kommen, an grundlegende Binsenweisheiten und Erfahrungen aus früheren Projekten erinnert. Sie ist gespannt, ob es funktioniert.

Alex lädt nun außerdem alle verantwortlichen Abteilungsleiter aus den Fachbereichen des Unternehmens zu einem Workshop über die Abhängigkeiten von fachlichen Entscheidungen in IT Projekten ein. Um "das große Ganze" für alle sichtbar und verständlich zu machen.

Workshop mit Domino

Sie bereitet dafür ein Dominospiel vor und spielt folgende Szenarien mit den Abteilungsleitern durch und lässt die Zeit stoppen, die die Teams für die einzelnen Szenarien brauchen:

• a) Wenn man in einer Dominostein-Kette ganz vorne etwas verändert, hat das Auswirkungen auf die ganz Kette, je mehr Verzweigungen und Besonderheiten die Kette hat, umso komplexer die Auswirkungen.
• b) Wenn man den ersten Stein der Kette umgestoßen hat, kann man den Verlauf der Kette nur dann bremsen, wenn man vorher entsprechende Stopps eingebaut hat.
• c) Wenn man eine Dominostein-Kette aufgestellt hat und in letzter Minute vor dem Start Änderungen im Verlauf fordert, muss das Aufsteller-Team ab der Stelle der geforderten Änderung nochmal von vorne anfangen.
• d) Wenn das Team noch daran arbeitet, die Kette aufzustellen, und der erste Stein schon umgestoßen wird, gerät alles durcheinander und die Arbeit des Aufsteller-Teams ist für die Katz.

Die Verbindung zum gescheiterten Release war allen Abteilungsleitern nach kurzer Zeit klar. Etwas länger dauerte es, die daraus resultierenden Maßnahmen zu diskutieren und eine einvernehmliche Lösung zu finden. Schließlich waren es die Fachabteilungen gewohnt, dass die IT es bisher "immer irgendwie geschafft hat", war sich aber über die langfristigen Auswirkungen und den hohen Ressourceneinsatz nicht im Klaren.

Der Workshop bot nun die Gelegenheit, die verschiedenen Standpunkte transparent zu machen und eine Vorgehensweise festzulegen, die allen – einschließlich Alex' Projektteam – tragbar erschien. Alex ist gespannt auf das nächste Release.