03
Feb 2017
Meilenstein – Der Projektmanagement-Blog

Wenn "Nein" sagen nicht reicht

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."

Anzeige

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.

Bisher gibt es 1 Kommentar
Es ist ein gutes Zeichen, wenn die Manager der Fachabteilungen auch zu dieser Domino-Veranstaltung kommen. Dann sind diese ja lernfähig und stehen zu ihrem Teil der Verantwortung.
Dass Alex immer noch Projektleiterin und nicht Sünderbock (was ist die weibliche Form von Sündenbock?) ist, werte ich als positiv.
Normalerweise werden Risiken erst ernst genommen, wenn eine gescheiterte Einführung schon früher in der Zeitung stand, die Kunden in Scharen zum ‚Mitbewerber‘ weggelaufen sind, etc. Dann hilft bei solchen Risiken der Verweis darauf, aber nicht immer. Von der IT ist man sich gewohnt, dass diese beliebig viele Stunden während Wochen (auch am Wochenende) arbeiten kann. Die Fluktuation wird hoch und die Qualität sinkt immer tiefer. Die ausgelieferten ‚grünen Bananen‘ qualifiziert der Kunde, weil ja keine Zeit zum Testen bleibt – das Produkt kommt zurück, nicht aber der Kunde. Das ist der Startpunkt vom Teufelskreis.
Variante: Agile Ideen ausprobieren wie Scrum. Das reduziert das Risiko vom Alles oder Nichts beim Wasserfallvorgehen, lässt auch zwischenzeitlich gelerntes einfliessen und man kann elegant Subito-Anforderungen auf den nächsten Sprint verschieben. Kein Allheilmittel, aber ein Anfang.
vor 25 Wochen 6 Tagen Thomas Spörri
Wählen Sie hier Ihre bevorzugte Anzeigeart für Kommentare aus und klicken Sie auf „Einstellungen speichern“ um die Änderungen zu übernehmen.
Kommentar verfassen
Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Bitte geben Sie Ihren Namen an: *
Tech Link