Der Auftrag
Das Projekt ist einfach. Wie so oft soll eine Software im Unternehmensbereich implementiert werden. Andere Bereiche nutzen das Programm schon, es gibt also Erfahrungswerte für Projekt und Programmierung. Für den neuen Geschäftsbereich bedarf es der Konfiguration, einiger Programmierung, und genauer Abstimmung mit dem Fachbereich über Prozesse und Daten. Der Rest ist Change Management.
Die Erstellung des Projektantrages mit Zeitplanung, Scope und Budget soll während der Auftaktberatung entstehen. Das anschliessende Coaching während der Implementierung hat das Ziel, den Projekterfolg zu sichern und dem Team als Sparring Partner zu dienen.
Die Herausforderung
Die bisherigen Rollout-Pläne passen nicht mit den notwendigen Szenarien für dieses Projekt zusammen, die Herausforderung liegt in den Rahmenbedingungen. Aufgrund von konzernweiten Abhängigkeiten müssen deutlich kürzere Zeitpläne eingehalten werden. So hat der Business Rollout ebenso wie die SAP-relevante Technik einen festen Abschlusstermin. Zudem bestehen innerhalb der auszurollenden Software technische Abhängigkeiten zu anderen Projekten, die während des gleichen Zeitraums bearbeitet werden und einem strengen Release-Plan folgen. Dieser diktiert den Projekten Development-Pausen von bis zu vier Wochen, um anstehende Go-lives nicht zu gefährden – eine Herausforderung für den ohnehin schon schwierigen Zeitplan.
Ein neuer Ansatz musste her, sonst würde dem Team auf halber Strecke entweder die Zeit oder die verfügbare Technik ausgehen. Bisherige Experimente mit agilen Methoden waren gescheitert, das Wort „agil“ dadurch verbrannt.
Das Vorgehen
Während der Gespräche zur Projektplanung entstand bei mir die Idee eines dedizierten Teams für dieses Projekt, in dem zusätzlich zu den benannten internen Consultants auch die Provider-Ressourcen zur Entwicklung zugeordnet sein würden. Völlig undenkbar zu dem Zeitpunkt, wurden die doch zentral über alle Projekte beauftragt und gemanagt.
Das weitere Vorgehen war geprägt von Verhandlungen und Überzeugungsarbeit.
Knifflig waren einerseits die vertraglichen Regelungen mit dem externen Implementierungspartner. Wäre eine solche Konstellation überhaupt denkbar? Vertraglich abbildbar? Was müssten wir organisatorisch und vertraglich beachten? Es gab einige Hürden, über die sich der Projektmanager des Beratungshauses intern abstimmen musste (Werkvertrag, Beauftragungsformalitäten bei einzelnen Bausteinen). Und noch mehr, die wir gemeinsam mit dem Kunden klären mussten (Kapazitäts- und Demand-Planung, Zuordnung dedizierter Ressourcen, Einordnung von Fachspezialisten, die für beide Projektbereiche benötigt werden).
Beim Kunden intern mussten wir vor allem beim Management Werbung für unser Vorgehen machen. Da das Wort „agil“ so einen schlechten Ruf hatte, war das Mantra in den Verhandlungen „Ich nenne das jetzt mal bewusst nicht agil“ und „Wir machen hier keinen methodischen Überbau mit Scrum Master oder ähnlichem“. Trotzdem war allen klar, worauf wir hinauswollten.
Das Team versprach, den übergreifenden Prozess einzuhalten und sich an bestehende Reportings zu halten. Der Release-Manager würde wie gewohnt eine Liste der technischen Objekte erhalten, die im ersten Release auf jeden Fall fertig sein würden. Dafür bekamen wir die Zusage für ein dediziertes Team und eine lange Phase „Build – Test – Show-Me“, statt der bisherigen klaren Abschnitte mit Zwischen-Meilensteinen für „Development done“, „Functional Test“, und „UAT“. Erster anvisierter Meilenstein: Ein Show-Me mit der Business Unit nach 6-8 Wochen Development.
In einer traditionell orientierten Management-Umgebung ein hohes Mass an Zutrauen.
Das Ergebnis
Das Development der Software war deutlich schneller fertig als bisher (8 statt bisher 12-15 Wochen). Zudem war die Qualität der Software bei Ankunft auf der Testumgebung signifikant besser als in vorherigen Projekten.
Grösster Einflussfaktor für Geschwindigkeit und Qualität war die enge Zusammenarbeit zwischen Programmierern und Consultants schon während der Entwicklungsphase. Durch Tests im Entwicklungssystem wurden Fehler und Missverständnisse frühzeitig gefunden und die Qualität der Software schon vor dem Transport auf die Testumgebung deutlich gesteigert. Während sonst zwischen Mail-Anfragen und Antworten, eventuellen Rückfragen und einer Online-Konferenz Tage vergehen konnten, in denen die Entwicklung ruhte, wurde jetzt direkt per Chat geantwortet, Online-Meetings direkt einberufen und die Ergebnisse der Klärung konnten sofort eingearbeitet werden. Durch die Konzentration des gesamten Teams auf nur ein Projekt und ein Thema gab es kaum Versatz und wenig Diskussion um Prioritäten.
Die Atmosphäre im Team war über Organisationsgrenzen und Kontinente hinweg positiv, engagiert und motiviert.
Das Beste: Mit den kontinuierlich guten Ergebnissen fand der alternative Ansatz steigende Akzeptanz im Management-Kreis. Heute gibt es bereits Überlegungen, die Release-Projekte ebenfalls mit kleineren dedizierten Teams durchzuführen.
Schwierigkeiten lauerten vor allem an den Grenzen des dedizierten Teams. So war es äußerst schwierig, die Zeit von Spezialisten ausserhalb des eigenen Projektes zu bekommen, um die vorher mit ihnen geplanten Aktivitäten für das eigene Projekt durchzuführen. Hier konkurrierten andere Prioritäten massiv mit der projekt-internen Planung.
Auch die Erwartungen an das Status-Reporting mussten angepasst werden. Bei diesem Setup änderte sich nach außen hin über Wochen kaum etwas am Status, da sich das Team nicht an die markanten Zwischen-Meilensteine hielt. Hier kam es besonders auf die Gespräche mit dem Management an, um gleichzeitig Transparenz über den Fortschritt im Projekt zu schaffen und die Erwartungen an die gewohnte Berichterstattung aufzufangen. Zudem entstand für das interne Team teilweise erhöhter Aufwand, um die bewährten Tracking-Tools zusätzlich zu pflegen, während das eigene Projekt anders tickte.
Fazit
Projekte und Teams leben nicht im luftleeren Raum. Es gibt einen Kontext von Kollegen, Verfahren, Genehmigungsprozessen, Verträgen, Erwartungen und Anforderungen. Dabei kämpfen klassische Projektorganisationen mit Ressourcen-Zuordnung, Kapazitätsplanung, Priorisierung der Aufträge für Spezialisten, Steuerung der Provider und Management der zugehörigen Vertragswerke.
In diesem Fall war agiles Arbeiten das Mittel der Wahl für die Development-Phase. Für den Rest des Projektes gab es eine klassische Rollout-Planung, die dem Geschäftsbereich die Kommunikation und Koordination erleichterte und den Beteiligten Orientierung gab.
Was wir eingeführt haben, ist Scrum ohne Scrum. Agil ohne Methodenfokus. Freiraum in der Zusammenarbeit und Vertrauen in die Projektführung. Nutzen von neuen Teamstrukturen, ohne sämtliche eingefahrenen Prozesse und Rahmenbedingungen über den Haufen zu werfen.
Stolperfallen für neue Ansätze lauern nicht nur im Engagement der designierten Team-Mitglieder, sondern auch in schwer veränderbaren Strukturen des Unternehmens – siehe Release-Fahrplan und Provider-Beauftragung. Die Gespräche über Erwartungen, Transparenz und Umgang mit den Aussengrenzen waren essentiell für den Erfolg dieses Vorgehens.
Es gibt nicht den einen einzigen Weg.
Dieser Beitrag ist Teil der Blogparade 2019 des projektmagazins.