Agiles ERP Projektmanagement – geht das?

Ist agiles ERP Projektmanagement (noch) ein Modewort? Kann das funktionieren? Oder bleiben dabei sogar erfahrene (Wasserfall) Projektmanager auf der Strecke? Anlässlich der Manage Agile Veranstaltung 2012 durfte ich dazu einen Vortrag halten. Im Zentrum meiner Ausführungen stand ein Praxisbeispiel aus der öffentlichen Hand. Wie wurde ein agiles ERP Projektmanagement eingeführt? Welche Hürden waren dabei zu bewältigen? Damals hätte ich mir durchaus gewünscht, dass 2016 schon viele der Inputs Realität sind. Meine Wahrnehmung ist jedoch, dass sich die Art und Weise des Verständnis zu agilem ERP Projektmanagement nicht merklich verändert hat. Woran liegt das? Und was sind die entscheidenden Hürden?

Das Pflichtenheft / das Lastenheft …

Wann haben Sie das letzte Mal seitenweise Anforderungen an die zukünftige ERP Lösung ermittelt und dokumentiert? Haben Sie sich dann zeitweise Vorlagen und Musterkataloge gewünscht? Diese dann aber gleich wieder als nicht so ideal klassifiziert und auf die Seite gelegt? Aus meiner Wahrnehmung besteht ein stark abnehmendes Interesse für sogenannte Standard Anforderungskataloge. Zu recht! Den was ist schon ein Standard und welcher Kunde sieht sich als Standard Kunde? Aber irgendwie muss man ja zu diesen Anforderungen kommen, denn angeblich lehrt uns die Vergangenheit, dass der Anbieter Lücken im Pflichtenheft nicht zu unseren Gunsten auslegen könnte. Und früh im Projekt steht fest, was im Pflichtenheft definiert wird muss später auch genau so umgesetzt werden. Auch wenn die Anforderungen mehr oder weniger ungeprüft aus einem Standardkatalog übernommen wurden. Zu diesen Anforderungen fehlt dann oft auch der Sponsor. Aber definiert ist definiert.

… als konstante Grösse!?

Welcher Weg auch immer gewählt wird, irgendwann bestehen viele Seiten mit Anforderungen an das neue ERP System. Mit diesen Pflichten konfrontieren wir die ERP Lösungsanbieter. Diese wiederum kalkulieren die Aufwände, die Kosten und den benötigten Zeitbedarf. Zu den einzelnen Anforderungen gehen Rückmeldungen ein. Beispielsweise, ja ist im Standard umsetzbar oder ist mit Anpassungen realisierbar. Jedoch sind die Anforderungen selten verhandelbar. Zugegeben, manchmal sind nicht einmal die erwarteten Termine verhandelbar.

Halten wir fest: der Kunde beschreibt detailliert und umfangreich den erwarteten Leistungsumfang, den Scope. Dieser ist praktisch nicht verhandelbar, wird also einseitig festgelegt. Das Ziel steht fest und ist zu erreichen. Punkt!

Der Vertrag …

Der Anbieter mit dem besten Angebot erhält den Zuschlag und startet schon bald mit den Projekt Aktivitäten. Im Verlauf des Projekts werden die Kosten und die Termine kontrolliert, diskutiert und nicht selten angepasst. Die Umsetzung der festgelegten und somit unantastbaren Anforderungen (ist ja klar, die stehen jetzt schwarz auf weiss da) steht über allem.

Erfahrungsgemäss wird jetzt am Leistungsumfang festgehalten, und sowohl Kostenanpassungen wie auch Terminverschiebungen kennen nur eine Richtung.

Und wie sichern wir dies ab? Genau, mit einem Vertragswerk. Dieses basiert auf einem umfassenden und den Leistungsumfang gut beschreibenden Pflichtenheft. Die Umsetzung wird damit auch rechtlich verbindlich definiert. Damit sichern wir uns quasi den ERP Projekterfolg per Papier zu. Soweit mal etwas überspitzt formuliert, vielleicht jedoch gar nicht so weit weg von der alltäglichen Praxis.

… als vertrauensbildende Grundlage!?

Zusammenfassend bedeutet dies nun, dass der Kunde den kompletten Leistungsumfang vorgibt und die Erbringung vertraglich absichert. Selbstredend mit einer Kombination aus Kostendach und Gesamtverantwortung durch den Anbieter. Das könnte sich nun etwas gar einseitig anhören. Und was sind die gewohnten Reaktionen auf diese Grundlagen? Änderungsanträge, Zeitverschiebungen, gegenseitige Missverständnisse, bis hin zu Krisensitzungen oder sogar zu einem Abbruch. Natürlich läuft dies manchmal auch richtig problemlos, die Statistik sagt bei etwa einem Drittel aller ERP Projekte. Für die anderen Fälle haben wir ja einen Vertrag, hoffentlich.

Agiles ERP Projektmanagement – 2 Hürden überwinden

Gelingt es uns (GEMEINSAM!) die zwei Hürden zu überwinden, dann kann agiles ERP Projektmanagement richtig erfolgsversprechend sein:

  1. Hürde: Kosten und Termin lösen den Scope als fixe Grösse ab, der Scope wird verhandelbar
  2. Hürde: Kommunikation steht über dem Schriftverkehr, regelmässige Abstimmung und Anpassungen sind selbstverständlich

Im klassischen Projektmanagement werden Phasen festgelegt. Jede Phase wird abgeschlossen bevor die Nächste startet. Eine Phase heisst bspw. Konzept. HERMES sagt dazu: Am Ende der Phase Konzept wird geprüft, ob es sinnvoll ist, das Projekt zu realisieren. Die Basis dazu ist der festgelegte Scope. In der Regel durch ein Pflichtenheft. Wir die nächste Phase freigegeben, dann wird für die Realisierung und Einführung das Vertragswerk unterzeichnet.

Gedankensprung!

Stellen Sie sich vor, zu diesem Zeitpunkt wären bereits die wichtigsten Funktionen gemeinsam mit dem Anbieter diskutiert und in Teilen realisiert. Diese lauffähigen Funktionen stehen zur Prüfung und Abstimmung bereit. Sie hätten bereits eine konkrete Vorstellung bis wann, welche weiteren Funktion realisiert werden könnten. Und das auf der Basis von gemeinsamen Erfahrungswerten. Willkommen bei: agiles ERP Projektmanagement.

Die erste dazu zu überwindende Hürde: Legen Sie als Kunde Zeit und Kosten verbindlich fest. Und sammeln Sie gemeinsame Erfahrung welchen Funktionsumfang sie innerhalb dieser Vorgaben  realisieren können. Hierzu stehen verschiedene Methode zur Verfügung. Dies bedeutet, dass die Funktionen priorisiert werden müssen. Das Wichtige kommt zuerst! Irgendwann tendiert entweder das verfügbare Budget oder die Zeit gegen Null. Dann spätestens ist es Zeit das Projekt zu beenden. Da wir alle wichtigen Funktionen bereits umgesetzt und lauffähig zur Verfügung haben, kommt das dann auch ziemlich gelegen. Den wer möchte noch viel Aufwand in unwichtige Funktionen investieren?

Zugegeben, zu der zweiten Hürde steht noch keine über alles erhabende Methode zur Verfügung. Insbesondere nicht im Bereich des öffentlichen Beschaffungswesens. Ansätze stehen jedoch einige zur Verfügung:

  • Hohe Priorisierung auf die gemeinsame Kommunikation setzen
  • Sehr regelmässige Planungs- und Fortschrittsmeetings sicherstellen
  • Regelmässige und lauffähige Softwareteile einfordern
  • Änderungen akzeptieren und schätzen
  • Klare und im Voraus festgelegte Akzeptanzkriterien (definition of done)
  • Steter, wiederkehrender Einbezug der Projektbeteiligten
  • Realisierung von hohem Mehrwert stiftenden Funktionen an den Anfang stellen
  • Klare Festlegung, dass wenn sich die Zeit oder das Geld dem Ende zuneigt, das Projekt abgeschlossen wird

Ich bin überzeugt, dass agiles ERP Projektmanagement funktioniert. Und nicht nur das, es wird sogar noch Spass und Freude bereiten. Für alle Beteiligten.

Veröffentlicht am 16. September 2016

Kommentar schreiben