Es begab sich zu einer Zeit vor Beginn des Jahrtausends, als die Wörter Scrum und agil noch nicht erfunden und das Agile Manifest noch nicht geschrieben war… Vielleicht ist bei meiner heutigen Praxis-Rückschau dann das „neulich“ nicht ganz richtig, aber ich habe in den seither vergangenen Jahren immer wieder Projektsituationen erlebt, für die das Beispiel für hybrides Projektmanagement hier exemplarisch stehen soll.
Nah am Standard und doch ganz individuell – geht das?
Es ging darum, ein Pilotprojekt für ein ERP-Template durchzuführen, das in der Folge dann seinen Roll-out in alle Niederlassungen des weltweit operierenden Kundenunternehmens erfahren sollte. Das Template sollte zur Kostenminimierung nahe am Standard bleiben und dennoch möglichst gut die Markt-Besonderheiten und gesetzlichen Anforderungen in den Niederlassungen adaptieren. Eine Quadratur des Kreises?
Es kam wie es kommen musste. Das Lastenheft erfuhr immer wieder Change Requests für neue oder geänderte Anforderungen aus den Niederlassungen, die Abteilungen im Hauptsitz des Unternehmens sahen das als Einladung, auch ihre Sonderwünsche freizügig einzukippen, die prognostizierten Kosten schossen über alle Budgetgrenzen hinaus. Nun machte das Projekt, was Piloten immer tun, wenn sie keine Landeerlaubnis bekommen: es drehte Schleifen.
Agiles und „klassisches“ Projektmanagement gehen eine Symbiose ein
Damit es sich nun auch von der Anforderungs- und Planungsphase einmal in Richtung Umsetzung bewegte, entschlossen wir uns, aufbauend auf den Kernfunktionalitäten des Standards iterativ vorzugehen. Als Strategie wurde vereinbart, nach jeweils einer festgelegten Zeitspanne ein funktionsfähiges Template fertig gestellt und getestet zu haben, das in folgenden Iterationen um priorisierte Inkremente ergänzt werden sollte, bis entweder der Zeit- bzw. Budgetrahmen erschöpft wäre oder das Template den Ansprüchen des Kunden hinreichend genügte.
Entsprechend wurden in der „klassischen“ Projektplanung abgegrenzte Zeit- und Kostenblöcke eingesetzt, aus denen die Geschäftsleitung jederzeit belastbare Vorschauen erhalten konnte. Das gab dem Management Kalkulations- und Planungssicherheit. Wir konnten so außerdem anhand der Prioritäten recht genau vorhersagen, wann wir den Fachbereichen welche Funktionalitäten zum Testen und zur Bewertung bzw. Abnahme würden liefern können, was uns in der Entwicklung Stabilität und Sicherheit brachte und dem Projekt wohlgesonnene Stakeholder.
Der Erfolg: Quick Wins, Flexibilität und Sicherheit
Auf diese Weise erreichten wir zweierlei: Erstens konnten wir mit der Entwicklung ohne weitere Verzögerungen beginnen, also ohne auf umfängliche Detailplanungen warten zu müssen, denn der Standard und die unstrittigen Grundfunktionalitäten für die ersten Entwicklungsphasen (Sprints) standen ja schon fest. Innerhalb von fünf Monaten hatten wir ein Deployment-fertiges Grundrelease, das ca. 70% der Prozesse unterstützte und für das die Mappings für die Datenmigration von den Altsystemen entworfen werden konnten.
Zweitens zogen wir so den „Anforderungsstreit“ aus dem Team heraus. Der fand fortan unter den (heute würde man sagen) Product Ownern aus den Niederlassungen und Fachabteilungen statt, die sich auf eine priorisierte Anforderungsliste (Stories) einigen und ein minimales Lastenheft (Product Backlog) definieren mussten. Später stellten wir in den Release-Planungen fest, dass wir um einen gemeinsamen Kern (das Template Backlog) durchaus individuelle, länderspezifische Erweiterungen in „Country Backlogs“ entwickeln konnten, deren inkrementelle Freigabe von ihrer sauberen Integration mit dem Kern abhängig gemacht wurde.
Top-effizient: auf Entwicklungsebene agil, im Projektmanagement „klassisch“
Während der gesamten Entwicklungszeit waren die Entwicklerteams nur gebunden an das, was sie für die jeweils 4- bis 6-wöchigen Release-Zyklen vom priorisierten Backlog-Stapel von oben herab geschätzt und Deployment-fertig zu liefern zugesagt hatten. Das ging in 90% der Fälle auf. Die Entwicklung war in der Masterplanung des Projekts als Control Account zeit -und budgetmäßig eingearbeitet, Risiko- und Issue Management arbeiteten eng mit den Teamleitern (Scrum Masters) zusammen, die Projektleiter und Qualitätssicherer (Product Owner) intensiv mit den verschiedenen Stakeholdern.
Insgesamt konnte nach 18 Monaten Projektlaufzeit etwa zwei Monate Entwicklung eingespart werden. Die haben wir lieber in ein gut vorbereitetes Change Management gesteckt, zulasten von ca. 25% des ursprünglichen Lastenheftes, die sich als Nice-to-haves herausstellten und eher neuen, als wichtiger eingestuften Anforderungen Platz machen mussten.
Und noch etwas: Wir waren mit dem 14. Release des Templates um Monate früher live als mit dem ursprünglichen Endprodukt geplant. Viele der Niederlassungen hatten ihre Varianten schon im operativen Betrieb als der anfangs geplante Roll-out hätte erst beginnen sollen. Alles zusammen haben wir auf der Kostenseite nicht so viel gespart, aber auf der Produktivitäts- und Business-Seite viel gewonnen.
Ein Beispiel für Best Practice
Warum ich über dieses Projekt hier gern erzähle? Weil wir damals noch nicht wussten, dass viele unserer Vorgehensweisen heutigen agilen Entwicklungsmethoden entsprachen. Und weil ich in vielen Projekten seither immer wieder feststellen konnte, dass sich diese mit dem „klassischen“ Projektmanagement nicht beißen, sondern, richtig und versiert miteinander verknüpft, hohe Produktivitäts- und Effizienz-Potenziale in sich tragen, die so manchem Projekt und Business Case gut täten.
