Auch wenn es vielleicht manchmal den Anschein hat, dass PLM-Blogger den ganzen Tag und die ganze Nacht nicht anderes tun, als über PLM nachzudenken, so muss ich doch mit diesem Mythos ein wenig aufräumen. Nein, auch wir haben so etwas wie ein privates Leben und das hatte mich in den letzten Monaten doch stark im Griff. Somit ist leider etwas Zeit ins Land gegangen, bevor ich wieder zum Schreiben eines Blogartikels kam.

Meine Erfahrungen mit agilen (Software-)Projektmanagementmethoden bei der Einführung von PLM-Systemen sollen heute im Fokus dieses Artikels stehen. Und es wird nicht nur bei diesem einem Blogpost bleiben. Dieses Thema gibt Stoff für mehrere Artikel her und so wird eine kleine Serie darüber entstehen.

Wenn ich im hiesigen Kontext von agilem Projektmanagement spreche, meine ich damit hauptsächlich Scrum als Vorgehensmodell und Kanban als unterstützende Projektmethode. Ehemalige Kollegen von mir konnten auch schon Erfahrungen mit extreme Programming sammeln und vielleicht lassen die sich ja mal zu einem Gastbeitrag hinreißen. Aber wie komme ich eigentlich darauf, dass agile Softwareentwicklung und eine Einführung oder Erweiterung eines PLM-Systems so gut zusammenpassen?

Am Anfang eines jeden PLM-Projekts steht der Wunsch nach einer Verbesserung des Engineeringprozesses oder eines Teilaspektes davon durch eine Softwareunterstützung. Das aktuelle Toolset passt aus verschiedenen Gründen nicht mehr (auch MS Excel hat seine Grenzen) oder bisherigen manuelle Prozesse sollten durch Software unterstützt werden. Gründe derer gibt es viele und somit auch mehr oder minder genau formulierte Anforderungen an die zukünftige Lösung. Die werden natürlich aufgeschrieben, in einem Benchmark mit unterschiedlichen PLM-Lösungen bewertet und sich dann für das richtige Tool entschieden.

Beim klassischen Vorgehen würde dann als erstes eine möglichst genaue Anforderungsspezifikation geschrieben werden. Der Stakeholder schildert seine Vorstellungen, die auf seinem bisherigen Erfahrungen mit dem Legacy-Toolset und mit dem, was er im Benchmark von neuen PLM-Tool gesehen hat, basieren. Die intellektuelle Leistung des Stakeholders, die dabei erbracht werden muss, ist immens. Er muss sich dabei seine bisherige Arbeitsweise vor seinem geistigen Auge mit dem neuen Werkzeug vorstellen und seine Anforderungen in verständlicher Form kommunizieren. Sicher gibt es viele Werkzeuge des Anforderungsmanagements, die hier unterstützen. Aber das Produkt dieser Arbeit ist eine Spezifikation, wie das zukünftige PLM-Tool arbeiten soll. Und auf Basis dieses Aufschriebs wird dann das PLM-Werkzeug angepasst, konfiguriert und programmiert. Und manchmal kommt sogar etwas raus, dass dem Anwender nutzt und er gebrauchen kann.

In einer agilen Vorgehensweise ersetzt man diesen Aufwand des Anforderungsanalyse durch eine direkte Kommunikation zwischen Stakeholder und Programmierer. Der Stakeholder schildert seine Anforderungen mündlich und der Implementierer kann direkt nachfragen, wenn Unklarheiten existieren. Des Weiteren hat der Consultant die Möglichkeit, dem Stakeholder best practice Ansätze und Standardlösungen in seinem Werkzeug zu zeigen, die vielleicht seine Anforderungen nicht zu 100% treffen. Die aber den Stakeholder potenziell begeistern können und ihm weitaus bessere Lösungen zeigen, als er bisher im Kopf hatte.

Diesen Effekt hatte ich einige Male in meiner Projektvergangenheit: Als Implementierer “verbiegt” man das PLM-System, damit man genau die in der ausführlichen Analyse aufgenommen Anforderungen umsetzt. Sonst ist ja der Kunde nicht zufrieden. Und dann schaut sich der  mal aus Zufall die Standardlösung an und findet die viel besser als das, was er sich ausgedacht und was er jetzt bekommen hat. Und über dieses Dilemma “Standard vs. Anpassung” und die Folgen (Hohe Implementierungskosten, Updatefähigkeit, Service und Support) habe ich mich in einem vergangenen Artikel bereits ausgelassen.

Neben diesem Aha-Effekt gibt es noch weitere Aspekte, die für eine agile Vorgehensweise bei der Einführung oder Weiterentwicklung eines PLM-Systems sprechen:

Minimierung der Unsicherheit in der Anforderungsanalyse:

Da Stakeholder und Implementierer direkt miteinander kommunizieren und alle Fragen im direkten Gespräch geklärt werden können, ist die Unsicherheit auf Seiten des Implementierers quasi nicht vorhanden. Missverständnisse in der Interpretation von Anforderungen können so kaum entstehen.

Höhere Transparenz durch sichtbare Zwischenergebnisse

Durch die unmittelbare Mitarbeit des Stakeholders und die iterative Vorgehensweise können schneller Ergebnisse präsentiert werden. Das Vertrauen auf beiden Seiten, in die richtige Richtung zu programmieren, wächst.

Basisanforderungen (Kano-Modell) werden nicht vergessen

Basisanforderungen sind laut dem Kano-Modell Anforderungen, die so selbstverständlich sind, dass sie vom Kunden nicht gesondert benannt werden. Sie führen bei Nichterfüllung zu maximaler Unzufriedenheit. Bei einer agilen Vorgehensweise fallen fehlende Basisanforderungen bereits während der gemeinsamen Entwicklung auf und somit zu einem maximal frühen Zeitpunkt.

Verhinderung von Goldplating

Funktionen, die zwar schön Aussehen, aber keinen wirklichen Nutzen bringen, fallen bei einer guten Priorisierung der zu entwickelnden Features schnell auf und werden bei jeder Sprintplanung neu auf den prüfstand gestellt. Somit werden wirklich nur Softwarefunktionen entwickelt, deren Nutzen klar dargestellt werden werden kann. Ich werde in einem der nächsten Blogartikel auf dieses Thema noch genauer eingehen.

Auf der anderen Seite ist eine agile Vorgehensweise auch an bestimmte Randbedingungen geknüpft, damit die oben beschriebenen positiven Effekte auch wirklich eintreten können. Als wichtigster und zentraler Punkt ist dabei die Kommunikation zwischen Stakeholder und Implementierer zu nennen.

Räumliche Trennung

Unternehmenssoftware wie PLM-Systeme sind fast immer standortübergreifend im Einsatz und somit sitzen die Stakeholder auch meist an verschiedenen Orten und Ländern. Sicher gibt es heute Videokonferenzen und andere Möglichkeiten der virtuellen Zusammenarbeit. Diese können durchaus eine Hilfe sein, um Entfernungen zu überbrücken. Aber trotz aller modernen Technik möchte ich hier eine Lanze für die gemeinsame Arbeit an einem Ort brechen. Meine Erfahrung zeigt, dass bereits unterschiedliche Räume am gleichen Standort zu Störungen in der Kommunikation führen können. Ein gemeinsamer Projektraum, in dem dann jeweils die relevanten Stakeholder temporär einziehen, trägt in einem großen Maß zum Projekterfolg bei.

Die berühmten “social skills”

Stakeholder und Implementierer müssen einfach “miteinander können”. Gerade auf Seiten des Implementierers ist neben dem technischen Wissen ein gerütteltes Maß an kommunikativen Skills notwendig. Er muss sich auf unterschiedliche Stakeholder einstellen können und ihn durch den gemeinsamen Entwicklungsprozess führen. Konflikte bleiben in keinem Projekt aus und bei einer agilen Vorgehensweise müssen diese im gemeinsamen Gespräch “an der Basis” gelöst werden. Ein gewisses Talent zum Hineinversetzen in die Lage des anderen schadet da auf keinen Fall. Bei internationalen Projekten kommt noch das Wissen um kulturelle Unterschiede und Fremdsprachen dazu.

Zeitliche Verfügbarkeit  der Stakeholder

Stakeholder sind in agile Projekte stark eingebunden und arbeiten Hand-in-Hand mit den Implementierer zusammen. Das ist nicht möglich, wenn sie für die Projektarbeit nur einen Teil Ihrer Zeit aufwenden können. Während der Implementierung ist eine nahezu einhundertprozentige Verfügbarkeit unbedingt erforderlich. Belohnt wird das mit genau der PLM-Funktionalität, die benötigt wird und Expertenwissen, dass beim Unternehmen verbleibt, wenn der Implementierer längst zum nächsten Kunden weitergezogen ist.

Technische Randbedingungen

Was aus technischer Sicht notwendig ist, um PLM-Systemanpassungen mit einem agilen Vorgehen ausliefern zu können, wird Thema von mindestens einem weiteren Blogartikel sein. Aspekte wie Continuous Deployment and Integration oder Test-driven Development verlangen nach mehr als einem kurzen Absatz.

Mit diesem Ausblick auf weiteren Lesestoff zur Agilität bei PLM-Softwareeinführungen möchte ich heute enden. Über Kommentare, Anregungen, Erfahrungen oder auch Kritik würde ich mich sehr freuen. Die Kommentarfunktion ist genau richtig dafür.