Neulich wurde ich beauftragt, ein in Schwierigkeiten geratenes Projekt zu begutachten.
Das Projekt arbeitete agil nach Scrum und kam nach interner Meinung gut voran – beim Kunden war die Erfahrung mit agilen Vorgehensweisen noch begrenzt, so dass in diesem Projekt das Team durch einen Product Owner, einen Scrum Master und einen Projektleiter intensiv begleitet wurde.
Der Projektleiter hatte das Projekt auf Basis einer initialen Aufwandsschätzung und Scope Beschreibung aus einem Vorprojekt aufgesetzt und reportete den Projektfortschritt und daraus abgeleitete Projektendetermine regelmäßig an das Management. Besonders heikel war die Situation dadurch, dass dieses Projekt firmenpolitische Bedeutung hatte und sich deswegen ein Vorstand regelmäßig über den Projektfortschritt unterrichten ließ. Ein belastbarer Endetermin des Projekts sollte aus Imagegründen schnellstmöglich in der Presse kommuniziert werden können.
Das Team hatte in voran gegangenen Monaten die eigene Aufwandsschätzung wiederholt nach oben korrigiert, bis der Vorstand auf einen externen Projektreview gedrungen hatte.
Bei der Untersuchung des Projekts zeigte sich, dass die jeweiligen Aufwandsschätzungen nicht mit ausreichend detaillierten Schätzannahmen hinterlegt waren. So waren zwar Fehler in der Schätzung in Summe offensichtlich, die dahinterliegen-den Ursachen aber waren nicht ermittelbar. Diese handwerklichen Probleme ließen sich relativ einfach durch eine bessere Schätzmethodik und aus-reichende Dokumentation beheben. So war für alle Beteiligten die Aufwandsschätzung nachvollziehbar und die Stellhebel für mögliche Budgetüberschreitungen bekannt.
Schwerer wog jedoch, dass der zuständige Fachbereich die Ergebnisse des Vorprojekts als definierten Scope zu einem vorausgesagten Preis auf-gefasst hatte – die IT Organisation verstand das Projekt als agil mit definiertem Budget und durch den Fachbereich zu optimierenden Scope.
Dieser Zielkonflikt war im Projekt bisher nicht aufgefallen - zwar gab es einen von Fachbereich und IT unterschriebenen Projektauftrag, der viele Details zu Projektprozessen regelte, aber dieses Detail der Projektmethodik ausgespart hatte. Die Situation war umso überraschender, da sich Fachbereich und IT Organisation auf die agile Vorgehensweise geeinigt hatten, gerade weil der Fachbereich zum Zeitpunkt des Projektbeginns noch nicht in der Lage war, alle Projektinhalte wie bei einem Festpreisprojekt vollständig und detailliert zu spezifizieren.
Allgemein empfehle ich Projektleitern deswegen viel Zeit in das Setup eines Projekts (und damit auch in den Projektauftrag) zu investieren, um Konflikte im Projektablauf vorherzusehen und zu regeln noch bevor diese im Projekt wirklich auftreten.
