Welche Herausforderungen entstehen, wenn Partner auf ein gemeinsames Ziel hinarbeiten, dabei aber unterschiedliche Vorgehensmethoden anwenden? Der Beitrag schildert Erfahrungen aus Sicht eines Projektleiters.
Kick-Off
Kürzlich bin ich von einem Kunden zu einem Kick-Off Meeting eingeladen worden. Dabei hat uns der Kunde über ein neues Geschäftsmodell informiert, das schon sehr bald am Markt erprobt werden soll. Wie erwartet wurden gewohnte Themen wie Vision, Ziele, Systemarchitektur und natürlich die Time erläutert. Wir als Lieferant dieser langjährigen Partnerschaft sollen dabei den logistischen Materialfluss zu diesem Modell sicherstellen. Soweit so gut.
Da wir in unserem Unternehmen ein klassisches Projektmanagement betreiben, ging ich davon aus, dass die nächsten Schritte die Planung der Detailworkshops sind. An diesen werden normalerweise die Anforderungen an uns als Lieferanten erhoben und anschliessend in Spezifikationen für die Anpassungen von Systemen oder Prozessen umgemünzt.
Doch für die Entwicklung dieses neuen Geschäftsmodells hat der Kunde die agile Vorgehensweise nach SAFe gewählt. So verliess ich das Kick-Off-Meeting ohne Termine für Workshops und ohne Meilensteinplanung. Dafür aber mit einer Einladung zu einem PI-Planning.
Herausforderungen
Dank meinen Weiterbildungen wusste ich, was an einem PI-Planning ungefähr passiert. In der Praxis war dies für mich aber neu. Ich erlebte einen spannenden und lehrreichen Tag. Jedoch musste ich in der Nachbearbeitung feststellen, dass ich keine konkreten Anforderungen für uns ableiten konnte. Ich wusste zwar, welche Themen wann ungefähr im Detail besprochen werden. Requirements an unsere IT oder den Betrieb konnte ich aber nicht spezifizieren. Da für gewisse Lieferobjekte mit langer Durchlaufzeit zu rechnen war, musste dies aber zeitnah geschehen. Mit dem Kunden einigte ich mich auf zweiwöchentliche Abstimmungen. Doch anstatt konkreter zu werden hatte ich das Gefühl, dass sich die Anforderungen im Zweiwochen-Rhythmus regelmässig ändern. Der Auftrag und die Erwartungshaltung bezüglich Leistungserfüllung unsererseits blieben unverändert bestehen. Ich wusste einfach noch nicht wie dies im Detail geschehen soll.
Risiko Management
So beschäftigte ich mich im Rahmen des Risiko Management vermehrt mit folgenden Fragestellungen:
- Wie können wir den Leistungsauftrag erfüllen, ohne die notwendigen Features zu entwickeln?
- Kann ich einzelne Lieferobjekte für die Entwicklung freigeben obwohl diese dann später die Anforderungen nicht zu 100% erfüllen?
- Wie stelle ich in einer klassischen Organisation Entwicklungsressourcen auf «stand by» sicher?
- Wie ist die Motivation oder Akzeptanz unserer Leistungserbringer, so lange der Auftrag noch nicht klar definiert ist?
- Wie viel Aufwand wollen wir in unklare Absichten investieren, ohne dass die Projektkosten aus dem Ruder laufen?
- Wann werden wir Klarheit erlangen?
Von Zeit zu Zeit entwickelte ich dank des regelmässigen Austausches ein Gefühl dafür, welche Rahmenbedingungen als gegeben betrachtet werden können. Diese begann ich dann zu beschreiben und liess sie vom Kunden freigeben. Ich erhielt die Freigaben, jedoch mit vielen Vorbehalten. Begründung: «Diesen Teil schauen wir erst später im Detail an». So strich ich diesen Teil aus dem Konzept und begann immer kleinere Pakete zu schnüren. So erlangte ich wenigstens für einzelne Prozesse ein Commitment seitens Kunde. Diese konnte ich dann endlich den Entwicklern übergeben. Für die offenen Punkte kreierte ich zusammen mit dem Betrieb organisatorische Workarounds, welche dann aber schnellstmöglich automatisiert werden sollen.
Das Projekt ist immer noch ongoing. Das Projektmanagement bleibt weiterhin spannend und herausfordernd.
