Agile Methoden haben in der Softwareentwicklung das klassische Projektmanagement abgelöst und Projektkomplexität ist der Grund, wieso Methoden wie Scrum insbesondere in der Data-Science angewendet werden. Wodurch sich Data-Science-Projekte im Speziellen auszeichnen und warum agile Ansätze geeignete Verfahren ihrer Projektsteuerung liefern, erfahren Sie in diesem Beitrag.
- Die Stacey-Matrix als Leitfaden für den Projektmanagementprozess
- Kennzeichen von Data-Science Projekten
- Agil managed Komplexität, indem die Projektziele variabel bleiben
- Risikosteuerung durch Proof-Of-Concept Entwicklungen
- Zusammenfassung
Die Stacey-Matrix als Leitfaden für den Projektmanagementprozess ¶
Welche Methode des Projektmanagements für welche Problemklasse anzuwenden ist, hat der Professor für Management an der Hertfordshire Business School in Großbritannien Ralph-Douglas Stacey in einer Matrix beschrieben. Die nach ihm benannte Stacey-Matrix unterscheidet einfache, komplizierte, komplexe und chaotische Projekttypen. Einfache Projekte kennzeichnen scharf umrissene Projektziele und eine definitive Methodenwahl zur Lösung des Problems. Je unschärfer das Projektziel und das Vorgehen zur Zielerreichung, desto mehr tendiert das Projekt dazu, chaotische Formen anzunehmen. In dieser Extremform gilt es aus einer Losung wie „Wir wollen mit der Digitalisierung schritthalten“ oder „Wir wollen führend im Bereich Predictive Maintainance sein“ zunächst konkrete Ziele zu definieren und Verfahren zur Zielerreichung mit Hilfe von Trail-and-Error-Ansätzen zu entwickeln.
Kennzeichen von Data-Science Projekten ¶
In der Data-Science begegnen wir in der Regel Zielstellungen die greifbar sind (Wir wollen gezielte Kundenansprache! Wir wollen Prognosen machen! Wir wollen vorausschauende Instandhaltung!), aber deren Was und Wie noch konkretisiert werden müssen. Die Projekte lassen sich auf den Achsen der Stacey-Matrix mit relativ hoher Unschärfe verorten. Einige Gründe dafür sind:
Die Zielerreichnung ist im Vorfeld nicht absehbar¶
Im Vorfeld des Projekts ist oftmals nicht abzuschätzen, ob das Projektvorhaben mittels der verfügbaren Daten überhaupt erreicht werden kann. Inwieweit die Ergebnisse „erfolgreich“ sind, kann nunmal erst geurteilt werden, wenn sie vorliegen.
Technologieauswahl findet erst während der Projektphase statt¶
Die Projektphase ist in der Regel dadurch gekennzeichnet, dass die zur Zielerreichung eingesetzen Technologien im Vorfeld nicht definiert sind. Dies betrifft sowohl die zur Datenmodellierung einzusetzenden Verfahren, als auch die Reportingtools, mit denen die Ergebnisse in die Unternehmensprozesse fließen sollen.
Späte Anforderungsänderungen der Anwender¶
Data-Science und das Reporting von Prognosen und Analyseergebnissen sind in der Entwicklungsphase stark auf das Feedback der Fachabteilungen und User angewiesen. Dieses wiederum kann permanent neue Anforderungen bzw. Spezifikationen an das Produkt erzeugen.
Anforderungsänderungen durch Technologiesprünge¶
Insbesondere bei Projekten die sich über einen längeren Zeitraum erstrecken, können neue Technologien die Produktentwicklung erheblich beeinflussen. Data-Science Anwendungen unterliegen einer hohen Innovationsdynamik:
- Datenquellen werden erschlossen
- Verfahren werden entwickelt oder entwickeln sich weiter
- Leistungsstärkere Hardware wird Marktfähig
Projektziele sind nicht eindeutig oder unterschiedlich interpretierbar¶
Vielleicht ist Ihnen diese Abbildung bekannt. Sie zeigt, welches Bild unterschiedliche Rollen von einem vermeintlich einfachen Produkt haben können.
Wie für andere Disziplinen trifft dieses Problem auch auf die Data-Science zu. In der Data Science spitzt sich das Schaukel-Problem zu: Hier werden Technologien eingesetzt, die den Projekt-Stackeholdern in der Regel nicht vertraut sind. Ungekehrt fehlt der Data-Science das unternehmerische, branchenspezifische Expertenwissen aus der Fachabteilung. Das bedeutet auch an dieser Stelle: Data-Science spielt sich in einem komplexen Umfeld ab, in dem Rückkopplungen zwischen ihr und Stakeholdern eine umso größere Bedeutung hat. Die Notwendigkeit von Kommunikation verhält sich gemäß der Stacey-Matrix: Je mehr das Projekt zum Chaos tendiert, desto mehr Bedarf an Austausch besteht.
Analyseprozesse und das entwickeln von Reportings spielen sich immer im Team ab: Mit den Fachabteilungen, dem Management und den Anwendern von Analytic-Apps. Jede dieser Rollen hat seine Anforderungen an Ergebnisse, Nutzen und Wirtschaftlichkeit des Data-Products. Fehlen innerhalb von Projekten Rückkopplungen zwischen Data-Science und den Stakeholdern, steigt die Gefahr von Fehlmanagement. Die Folgen:
- Modelle, die am Business-Case vorbeigehen
- Falsche Modelle durch invalide Datengrundlagen oder Artefakten in den Modellierungsvariablen
- Ergebnisse die nicht Unternehmensprozesse eingebunden werden, weil sie nicht Anwendergerecht aufbereitet sind
Datenvalidität wird überschätzt¶
Unternehmensinterne Sichten auf die Eignung von Daten für Data-Science Projekte (bspw. Prognosemodelle) sind häufig verzerrt – sie neigen dazu, die Qualität der Daten zu überschätzen. Der Grund: Unternehmensdaten aus dem Data-Warehouse oder den internen Datenbanken sind auf etablierte Business-Intelligence Anwendungen optimiert und liefern über diese zuverlässige Reports. Prognosemodelle und tiefergehende Modelle haben jedoch eigene Anforderungen an das Format der Daten. Auch wenn BI erfolgreich praktiziert wird, muss dies nicht zwangsläufig auf Datenformate hindeuten, die sich ohne Weiteres in Data-Science Anwendungen einbinden lassen.
Agil managed Komplexität, indem die Projektziele variabel bleiben ¶
Agile Managementprozesse lösen sich von dem Glauben, dass die Zielrealisation in komplexen Projekten planbar ist. Sie versuchen vielmehr proaktiv der Unvorhersehbarkeit zu begegnen – und diese sogar in positive Energie umzusetzen. Rückkopplungen, enge Kommunikationszyklen und Teamstrukturen geben Impulsen, Ideen und Hürden notwendigen Raum sich zu entfalten und ermöglichen es, dynamische Anpassungen an dem Produkt vorzunehmen, wenn es die Situation erfordert. In der Forschung wird diese Form des Denkens „Effectuation“ genannt. Die Kernaussage dieses Ansatzes: „Wer in der Zukunft steuern kann, braucht diese nicht vorherzusagen.“ [Sarasvathy, S. 2008: ‚Effectuation: Elements of Entrepreneurial Expertise‘]
Klassisches Projektmanagement unterstützt dagegen das Vermeidungsverhalten für Projektveränderungen. Es gilt die Prämisse, dass die Zielrealisation hinsichtlich Umfang, Kosten und Zeit planbar ist und nach präziser Vorüberlegung und Kalkulation ein akkurat dokumentiertes und insbesondere dauerhaft gültiges Pflichtenheft erstellt werden kann. Ist einmal der Projektplan erstellt, das Pflichtenheft geschrieben, die Stakeholder informiert, das Budget geplant, sind die Hürden für Änderungen an dem Vorhaben hoch – oftmals zu hoch.
Anhand des sog. Magische Dreieck des Projektmanagements lassen sich die unterschiedlichen Perspektiven auf das Projektgeschehen deutlich zeigen. Das klassische Projektmanagement setzt ein fixes Ziel, welches durch einen geschätzten Umfang von Kosten und Zeit erstellt werden soll. Im agilen Ansatz werden Kosten- und Zeitbudget festgelegt um damit einen Projektfahrplan zu gestalten.
Risikosteuerung durch Proof-Of-Concept Entwicklungen ¶
Aufgrund ihrer Komplexität, werden Data-Science Projekte häufig sukzessiv in zweit Schritten aufgebaut: Einer gelungenen Proof-Of-Concept-Phase folgt die Entwicklung der Produktreife.
Agil gesteuerte Projekte unterstützen diesen Umstand: Sie zielen darauf ab, in möglichst kurzer Zeit erste Analysenergebnisse zu generieren und kleine Stücke funktionierender Software auszuliefern. In einem iterativen Prozess entwickelt sich aus diesem Stück Software das Gesamtprodukt. Damit erbringen agile Projekte gewissermaßen naturgemäß ein Proof-Of-Concept schon in frühen Stadien der Gesamtprojektlaufzeit (vorausgesetzt der Product-Owner setzt die richtigen Prioritäten im Product-Backlog). Proof-Of-Concept und anschließende Produktentwicklung sind daher eine fortlaufende Folge von Meilensteinen. Stellt das Projektteam schon in der Frühphase des Projekts erheblichen Mehraufwand fest, oder sind die Daten möglicherweise nicht geeignet für die geplanten Modelle, kann diese Entwicklung bei entsprechender Budgetierung abgebrochen werden.