Ausgangssituation

Ein großer Deutscher Automobilhersteller mit 120.000 Mitarbeitern und 16 Fertigungsstätten verwaltet seine Fertigungs- und Betriebsmittel sowie Fertigungsanlagen noch nicht über ein PLM-System und kann deshalb Anforderungsermittlung, Entwicklung, Inbetriebnahme, Nutzung und Verwertung nur mit großem Aufwand und unvollständig nachvollziehen. Abläufe und Anwendungen unterscheiden sich nicht nur zwischen den Fertigungswerken, sondern auch zwischen Abteilungen innerhalb eines Fertigungswerks. Ein Großteil der Informationen ist in eMails, PDFs, Word-Dokumenten und Excel-Listen lokal auf Arbeitsplätzen von Mitarbeitern oder in deren Köpfen gebunden. Daten und Informationen gehen bei interner und externer Fluktuation verloren. Freigaben werden über Besprechungen erteilt und sind nicht lückenlos nachvollziehbar. Aus diesem Grund ist die Ursachenforschung für Fehler und eine Abstellung der Ursachen schwierig.

Der Überblick über den Gesamtprozess ist eine Voraussetzung zur Nutzung neuer Simulationslösungen z.B. für die virtuelle Inbetriebnahme von mechatronischen Systemen in Fertigungslinien, die teure Verzögerungen bei der Inbetriebnahme reduzieren sollen. Zur effizienten Handhabung sollen Simulationen über ein Simulations-Lifecycle-Management (SLM) verwaltet werden. Zudem sollen die mehrheitlich manuellen Tätigkeiten soweit möglich automatisiert oder automatisierbar gemacht werden, redundante Informationen und Daten mit unterschiedlichen Versionsständen aufgelöst und die Funktionalität einer Vielzahl unterschiedlicher Bestandsanwendungen in die PLM-Lösung integriert werden. Dazu gehört auch die Automatisierung von Arbeitsprozessen im CAM-Bereich. Von der dadurch erreichten Tool-Konsolidierung erwartet sich das Unternehmen zusätzliche Kosteneinsparungen.

Die Einführung eines transparenten Release- und Change Managements ist die Voraussetzung für schnellere und sichere Fertigungsanläufe und soll zudem allen Ebenen einen Einblick in den aktuellen Stand der Zielerreichung geben, um Fehlentwicklungen rechtzeitig gegensteuern zu können. Fertigungsanläufe und Änderungen sollen schneller, reibungsloser und mit weniger Aufwand umgesetzt werden.

Die zu implementierende Lösung soll möglichst weit auf kundenspezifische Anpassungen verzichten, weil das Unternehmen aufgrund von Eigenentwicklungen und stark angepassten Anwendungen um die hohen Folgekosten und fast unüberwindbare Hindernisse bei der Wartung und Aktualisierung innerhalb großer vernetzter IT-Strukturen Bescheid weiß.

Das Unternehmen legt großen Wert auf eine gute Usability und eine zukunftstaugliche Technologie-Plattform sowie die nahtlose Integration in die bestehende IT-Systemarchitektur. In einem Nachfolgeschritt soll die Lösung in die vollautomatisierte CI/CD-Umgebung eingebunden werden und eine Vielzahl automatischer Testtypen unterstützen. Das Unternehmen verfügt bereits über ein Spezialisten-Team für den Betrieb der zu implementierende Standardanwendung mit mehreren Bestandsumgebungen, in welche sich die Lösung einfügen soll.

Das Budget und der Zeitrahmen sind knapp bemessen. Aus diesem Grund möchte das Unternehmen möglichst viele Leistungen selbst erbringen. Dazu gehört auch die Anforderungsermittlung. Das Projekt soll agil organisiert sein, wird jedoch nach Festpreis mit festgelegten Arbeitspaketen und Meilensteinen beauftragt.

Fragestellung

• Wie kann die geforderte Usability zur Verfügung gestellt werden, wenn diese nur durch den stark funktionsreduzierten Web-Client und nicht durch die leistungsfähige Hauptanwendung zur Verfügung stellt wird?
• Welche Lösung wird beim Unternehmen implementiert, wenn es anbieterintern 2 Lösungsansätze aus unterschiedlichen Produktlinien gibt, bei welchen der langfristig orientierte Ansatz noch nicht einsatzbereit und der kurzfristig ausbaubare Ansatz voraussichtlich auf Dauer eingestellt werden könnte?
• Wie können Anforderungen des Unternehmens mit einer Standardlösung umgesetzt werden, die es im Anforderungsumfang selbst im kurzfristig ausbaubaren Ansatz noch gar nicht gibt?
• Wie kann das Unternehmen ohne tiefe Produktkenntnis über die Standardanwendung und ohne MVP qualitativ verwertbare Anforderungen definieren?
• Wie kann die Prozessautomatisierung im CAM-Bereich gegen den Widerstand aus den Fachabteilungen durchgesetzt werden?
• Daraus abgeleitet: wie kann die bestehende CAM-Anwendung beim Unternehmen möglichst unauffällig durch die eigene CAM-Anwendung abgelöst werden?
• Wie können die Aufwendungen für die Implementierung maximal reduziert werden, weil es sich um ein strategisches Investment handelt, das die Kosten nie decken wird?
• Und wie kann aus diesem Projekt eine Grundlage für die Ablösung der bestehenden PDM-Umgebung durch eine neue PLM-Umgebung gelegt werden?

Lösung

Der PLM-System-Anbieter akzeptiert das nicht kostendeckende Verhandlungsergebnis, setzt aber seinerseits im SOW strikte Voraussetzungen zur Umsetzung, um den Verlustrahmen zu begrenzen. Dazu gehört eine besonders strenge Definition der Readiness-Kriterien von Anforderungen, ein Black-Box-Konzept für das Lösungsteam, bei dem der Zugriff auf Spezialisten verhindert wird und separate ALM-Umgebungen für das Unternehmen und den Lösungspartner, so dass kein unautorisiertes Wissen an das Unternehmen gelangen kann.

Das Lösungsteam erhält einen Crash-Kurs für Scrum mit verschärften XP-Bestandteilen um die Effizienz möglichst hoch zu schrauben. Zudem steht dem Lösungsteam, dem Steuerungsteam des Unternehmens und Fachbereich-Teams ein Scrum Coach zur Verfügung.

Der funktionsreduzierte Web-Client soll anhand der Anforderungen des Unternehmens erweitert werden und damit den OOTB-Standard für andere Kunden setzen. Der dabei erreichte Mehrwert rechtfertigt die strategische Projektkalkulation und erfüllt gleichzeitig eine zentrale Kundenforderung. Die Basis-Implementierung wird anhand eines alten Client vorbereitet und bei Verfügbarkeit der notwendigen Funktionalität im neuen Client umgesetzt.

Das Unternehmen muss Anforderungen für jegliche Funktionalität inklusive der Basisfunktionalitäten mit den vorgegebenen Readiness-Kriterien zur Verfügung stellen. Ein Proxy-PO steht dem Product Owner des Unternehmens unterstützend zur Verfügung und bildet die Schnittstelle zum Lösungsteam.

Umsetzung

Die zum Projektstart zugesagten Anforderungen lagen aufgrund fehlender Produktkenntnis über die einzuführende Standardlösung noch nicht vor. Aus diesem Grund hat der PLM-System-Anbieter das Unternehmen bei den ersten Schritten außerhalb des vereinbarten Leistungsumfangs in einem begrenzten Zeitrahmen und Umfang unterstützt. Resultat war, dass das Lösungsteam zum Projektstart keine umsetzungsfähigen Anforderungen erhalten hat und demnach über 3 Monate lang Kosten ohne Wertschöpfung verursacht hat.

Nach Einstellung der Unterstützung wurden abermals keine umsetzungsreifen Anforderungen gemäß festgelegter Readiness-Kriterien abgeliefert, so dass der Bedarf eines produkterfahrenen Business Analysten unübersehbar wurde. Die notwendige Ressourcenanpassung war allerdings weder im Budget des Unternehmens, noch im Vertragswerk unterzubringen. Folge war eine weitere Verzögerung, bei dem das Lösungsteam Kosten ohne Mehrwert verursacht hat. Zahlungen hat das Unternehmen mit dem Verweis auf Festpreise pro abgelieferte Arbeitspakete abgelehnt.

Als Reaktion auf die Verzögerungen und ausbleibende Zahlungen hat der PLM-System-Lieferant die Leistungen deutlich eingeschränkt und aufgrund der Covid19-Situation in Absprache mit dem Unternehmen das Projekt auf unbestimmte Zeit eingefroren. 1,5 Jahre später wurde das Projekt in reduziertem Umfang wieder aufgenommen. Dieser reduzierte Umfang war um die strategischen Ziele des PLM-Anbieters gekürzt. Andere Projekte des PLM-System-Anbieters beim Unternehmen wurden währenddessen an andere Dienstleister vergeben.

Projektmethode

Das Lösungsteam sollte nach Scrum arbeiten um aufgrund der Unterbudgetierung mit höchster Effizienz möglichst wenig Kosten zu verursachen. Der Einsatz von Hardcore-Scrum war allerdings problematisch, da es im Team keine erfahrenen Scrum-Anwender gab und die dafür notwendige besondere Wesenseigenschaften sowie effizienzgesteuerter Demut nur begrenzt verfügbar waren. Folge war die offene Verweigerung des Proxy-PO und der Hälfte der Team-Mitglieder in Form einer offenen Revolution, die Scrum-Prozesse schlicht abgelehnt und nicht praktiziert haben.

Als Reaktion darauf hat der Agile Coach die Arbeit eingestellt, das Team ist bereits vor dem Project Freeze auf die Hälfte reduziert worden und agile Leitungsbestandteile wurden nicht mehr erbracht.

Herausforderung

In diesem Projekt gab es viele ungelöste Herausforderungen, die mit etwas gutem Willen, Offenheit, Erfahrung, Flexibilität und Mut sehr wohl lösbar gewesen wären.

Die erste Herausforderung war sicherlich die zur Projektmethode unpassende Auftragsform. Mit Festpreisen ist keine Agilität und Flexibilität bei der Leistungserbringung möglich, die bei einer Lösung ohne absehbarem Lösungsweg aber unabdingbar ist. Eine Anpassung an den Bedarf hat es von Kundenseite aus leider nicht gegeben. Der Scrum Master hätte das Projekt bereits am ersten Projekttag einfrieren müssen, um die Rahmenbedingungen so anzupassen, dass eine realistische Lösungsentwicklung möglich wird.

Eine weitere Herausforderung war die Unterbudgetierung und der damit zusammenhängende Verzicht auf einen erfahrenen Business Analysten oder Consultant, der dem Kunden bei der effizienten und vollständigen Definition seiner Anforderungen unterstützt. Ein Good Practice ist ein Business Analyst des Lösungsteams, der unabhängige Anforderungen in der richtigen Reichenfolge ermittelt und gut vorbereitet sowie Refinement-bereit beim Product Owner abliefert, so dass das Lösungsteam immer gut ausgelastet ist. Der Scrum Master hätte das Projekt sofort nach Kick-Off und Scrum-Training einfrieren müssen, weil bekannt war, dass es für ein bereitstehendes Lösungsteam keine Anforderungen zur Umsetzung gibt. Der Scrum Master ist für das Ressourcenbudget und die Sprintzielerreichung verantwortlich! Die Ressourcen hätten währenddessen in anderen Projekten wertschöpfend eingesetzt werden können. Das Projektbudget wäre bei korrekter Handlungsweise nicht ohne Leistungserbringung zerschmolzen.

Wie soll eine Partnerschaft entstehen, wenn ein Partner den anderen von Beginn an über den Tisch ziehen möchte? Offenheit und Transparenz sind grundlegende Prinzipien der Agilität, die in diesem Projekt jedoch von Anfang ausgeschlossen waren. Wie passt ein Black-Box-Konzept zur Agilität? Wie passen nach Unternehmen und Lösungsteam getrennte Projektwerkzeuge zur Agilität? Wie passt ein Proxy-PO zur Agilität, der dem Product Owner den Zugriff auf das Team verwehrt? Außer überhöhtem Druck und der Wortwahl war an diesem Projekt nichts agil. Die agil bezeichneten Zeremonien wurden mit Tätigkeiten einer Planungsorganisation gefüllt. Die Teams und das Projekt wurden von Planungsorganisationen gesteuert. Der Scrum Master hätte diese Konfiguration nie akzeptieren dürfen, weil sie nichts mit Agilität zu tun hat.

Die im Projektteam integrierten Spezialisten aus Management-Ebenen haben sich der agilen Teamarbeit gänzlich verweigert, kein Wissen geteilt oder keine Wertschöpfung erbracht. Die zu den Rollen gehörenden Aufgaben wurden nicht wahrgenommen und entsprechende Leistungen wurden nicht erbracht. Fehlende Arbeitsergebnisse haben andere Teammitglieder vor unlösbare Herausforderungen gestellt. Der Scrum Master mit seiner Sprintzielverantwortung hätte das Team bei Bekanntwerden des Defizits neu besetzen und deshalb bis zur Lösung der Rahmenbedingungen einfrieren müssen.

Mein regelmäßiger Hinweis zum notwendigen Project Freeze und der damit verbundenen Korrektur der Rahmenbedingungen hat keine der Vertragsparteien berücksichtigt. Der eingesetzte Scrum Master hatte keine vorherige Projekterfahrung und hat deshalb nicht die notwendigen Konsequenzen gezogen. Letztendlich hat der Scrum Master versagt, weil er seine Sprintziele nicht erreicht und das Budget verschwendet hat.

Projektinformationen

Projektdauer: 6 Monate bis zum Project Freeze

Projektteam: 1 Proxy PO, 1 Scrum Master, 8 Teammitglieder

Projektbudget: unbekannt

Fazit

Ein Agile/Scrum Master, der seine Rolle nicht ausfüllt, bringt ein Projekt zum Scheitern. Für einen Scrum Master gibt es keine Schuldverschiebung: er alleine ist für die Sprintzielerreichung verantwortlich und benötigt deshalb auch die entsprechenden Kompetenzen wie Teambesetzungs- und Teilbudgetverantwortung. Ohne diese Kompetenzen ist der Agile/Scrum Master kein Agile/Scrum-Master, sondern ein zahnloser Tiger. Das gilt erst Recht, wenn der Agile/Scrum Master von einer Planungsorganisation gesteuert wird und keinerlei Kompetenzen hat.

Wenn zwei große Planungsorganisationen aufeinander prallen und sich dann als agil bezeichnen, dann ist nicht viel Agilität zu erwarten. Die agile Transformation ist vor allem Einstellungssache. Die agile Transformation erfordert eine agile Umstrukturierung der Organisation. Und die agile Transformation ist weder eine kurzfristige Angelegenheit, noch in Inseln umsetzbar. Die Agile Transformation wächst von oben nach unten durch das Unternehmen und muss dabei die komplette Breite mitnehmen, weil an den Schnittstellen zwischen Planungsorganisation und agiler Organisation nahezu unlösbare Probleme zu überwinden sind. Von oben nach unten auch deshalb, weil Vorgesetztenebenen nach unten weisungsberechtigt sind, nicht aber in der Gegenrichtung. Und weil das gute Beispiel von oben zur Nachahmung animiert, während die Nichtbeachtung vorgesetzter Ebenen zur Vernachlässigung und Ablehnung führen.

Meine Lösung bis zur Durchdringung der Agilität in die Teamebene ist deshalb: Großunternehmen sollten sich bis dahin an die Wasserfallmethode halten, um unvermeidliche Spannungsfelder und Reibungsverluste zu umgehen. Großunternehmen sind aufgrund ihrer starren Hierarchie und Regeln nicht in der Lage Konflikte flexibel zu lösen.

Mein Arbeitgeber

PLM Implementierungspartner des PLM-System-Anbieters, in dessen Unterauftrag mein Arbeitgeber beim Unternehmen tätig ist.

Meine Rolle

Ich habe als PLM Consultant das Projekt-Setup unterstützt, das Unternehmen als Business Analyst bei den ersten Schritten der Anforderungsermittlung unterstützt, eigehende Anforderungen auf Readiness geprüft und Defizite an den Proxy-PO zurückgegeben, den Proxy-PO bei der Priorisierung von unabhängigen Anforderungen unterstützt, das Refinement unterstützt und den Scrum Master bei seinen ersten Projekterfahrungen unterstützt. Ich habe neben dem externen Scrum Coach die Fachbereich-Teams und das Steuerungsteam des Unternehmens genauso wie das Lösungsteam mit meiner agilen Erfahrung bei der Entwicklung von Lösungen für Herausforderungen unterstützt. Daneben habe ich das ALM-System des Lösungsteams aufgesetzt, konfiguriert, administriert, die teaminternen Prozesse im Wiki dokumentiert, die Teammitglieder geschult und im Projektverlauf unterstützt. In Einzelfällen habe ich auch kleine Implementierungsaufgaben ausgeführt sowie die dafür notwendigen Review-Videos erstellt.