Es begab sich zu einer Zeit vor Beginn dieses Jahrtausends, als das Wörtchen Scrum lediglich von Rugby-Fans geführt wurde und das Agile Manifest noch nicht geschrieben war… Vielleicht passt bei meiner heutigen Praxis-Rückschau das Wörtchen "neulich" nicht ganz rein, aber ich habe in den seitdem vergangenen Jahren immer wieder Projektsituationen erlebt, für die das folgende Beispiel exemplarisch stehen kann.

Nah am Standard und doch ganz individuell – geht das?

Damals ging es 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 nahmen dies als Einladung, auch ihre Sonderwünsche freizügig "einzukippen", so dass die prognostizierten Kosten über alle Budgetgrenzen hinausschossen. Nun machte das Projekt, was Piloten tun, wenn sie keine Landeerlaubnis bekommen: Es drehte Schleifen.

Agiles und "klassisches" Projektmanagement gehen eine Symbiose ein

Damit es sich nun 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 einer jeweils 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.

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 Product Ownern (so nannten wir sie damals natürlich nicht) 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 konnten wir so nach 18 Monaten Projektlaufzeit etwa zwei Monate Entwicklungsarbeit einsparen. Diese Zeit steckten wir dann in ein gut vorbereitetes Change Management. Jenes ging zulasten von ca. 25% der Anforderungen des ursprünglichen Lastenheftes, die sich als Nice-to-Haves herausstellten und neuen, als wichtiger eingestuften Anforderungen weichen 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, bevor der ursprünglich geplante Roll-Out begonnen hätte. Alles zusammen genommen haben wir auf der Kostenseite zwar nicht viel gespart, auf der Produktivitäts- und Business-Seite jedoch viel gewonnen.

Ein Beispiel für Best Practice

Warum ich über dieses Projekt hier gerne schreibe? 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.