Der Erfolg vieler Unternehmen begründet sich in der Priorisierung von Datenprojekten und Datenprodukten. Ein effektives Portfoliomanagement basiert auf erwarteter Wertgenerierung und den Kosten, aber schon bei der Bewertung von Projekt versus Produkt scheiden sich die Geister. Die Basis ist standardisiert und zahlengetrieben. Das Zulassen intuitiver Anteile und die Orientierung an Trends, zahlen in die Unternehmensstrategie ein.
Portfoliomanagement als Prozess in einem System
Ein Portfolio von Projekten gegeneinander abzuwägen, ist ein Prozess, bei dem meist Unternehmensbereiche gegeneinander antreten. Unsere Kunden setzen vorzugsweise auf wertbasierte Beurteilung mit Risiko und Investmentkosten verknüpft, meist auf Basis von Umsatz, Margen und Opportunitätskosten. Produkte in einem Portfolio müssen genau so bewertet werden. Die Handhabung der Komplexität erfordert eine auf einer systemischen Haltung basierenden Vorgehensweise. Differenziertes Einbeziehen und Abwägen verschiedenster Aspekte und deren Wechselwirkungen erfassen den „echten“ Bedarf von Projekt und Produkt: mit Berücksichtigung von klein gegen groß, langfristig gegen kurzfristig, rechtlichen Aspekten. In einem rein standardisierten Vergleich verlieren Basisprojekte ohne direkten Wertbeitrag, wie der Aufbau von Data Assets.
Sind Datenprodukte andere Produkte?
Datenprodukte verhalten sich finanziell betrachtet, wie andere Produkte – sie benötigen ein Initialinvestment, die Kosten für ein Datenprojekt selbst und später Wartung und Betrieb.
Der Schritt zum Aufbau der Datenplattform und des Datenteams leidet regelmäßig unter fehlender Vertretung und Finanzierung. Im Vergleich dazu ist der einzelne Usecase ein Selbstläufer – er baut auf bestehendem auf. Portfoliomanagement leidet darunter, dass sich alle den kleinen Selbstläufer zurechnen wollen, aber keiner das Investment in Datenteam und Plattform tragen will.
Die Herausforderung im Projekt mit Daten und beim Aufbau von Produkten besteht in der Qualität der Daten. Auf bereits vorhandenen und gesicherten Daten ein Projekt zu bauen, ist einfacher, in der Unternehmensrealität kommt das aber selten vor. Hier besteht die zweite große Hürde: Alle wollen gesicherte qualitativ hochwertige Daten, aber auch hier will dafür keiner das Investment tragen. Zugegeben, das Thema Datenqualität wird immer noch als leicht „esoterisch“ angesehen. Zu oft gibt es Vertreter der Auffassung, das kann man „smart“ lösen. Gemeint ist hiermit, dass mit geringem Aufwand und der richtigen Methode ein Quick Win generiert werden kann. Zu groß sind die Versprechen von Produktherstellern und Unternehmensberatern, die es mit nur wenig Aufwand schaffen wollen.
Jedes Projekt zur Integration von neuen Daten ist individuell und einzigartig. Die Arbeit am Datenverständnis und der Spezifikation ist aufwändiger als die Implementierung selbst. Die Reifung der Daten, also der Aufwand für Integration, Test, Produktivsetzung und Stabilisierung, dauert fast immer länger als der erste durchgeplante und durchstrukturierte Teil des Projektes.
Priorisierungs-Frameworks
Am Markt gibt es diverse Standards oder Frameworks zur Projekt- und Produktpriorisierung, die den Business-Bedarf anhand von Wertbeitrag und Kosten gegenüberstellen. Wenn man Projektanwärter mit möglicher Umsetzbarkeit ins Verhältnis setzt, erleben im Konzernumfeld das Verhältnis von einem Fünftel bis zur einer Hälfte Umsetzbarkeit. Dieses Verhältnis und diese Aussage ist mit Vorsicht zu genießen, sie berücksichtigt oft nicht die fehlende Reife des Datenproduktes/-projektes.
Priorisierungsframeworks oder -guidelines sind bei wachsendem Bedarf unabdingbar. Der Weighted Shortest Job First (WSJF) ist hier eine gute Basis – also der erwartete Wertbeitrag durch den Aufwand mit Berücksichtigung der Laufzeit. Die Methode ist weitgehend bekannt, weil sie sich mit SaFe verbreitet hat. In ihr stecken doch einige interessante Facetten: Cost of Delay wird durch Job Duration geteilt. Allerdings sind inCost of Delay nicht nur monetärer Wertbeitrag, sondern auch Zeitkritikalität und das Risiko verpackt. Der Faktor Time to Market wird sehr stark betont und damit ist die Methode näher an der Produktentwicklung.
Aber deckt die Methode alles ab und taugt sie in jedem Fall? Kann es auch sein, dass WSJF nur auf der Ebene eines Backlogs funktioniert?
Grenzen von Priorisierungs-Frameworks
Wie schon mehrfach erwähnt, haben Datenprodukte meist nicht diesen klar definierten Zustand, den man für eine Standardmethode benötigt. Die WSJF-Methode bevorzugt Produktfeatures, die einen schnellen Wertbeitrag leisten.
Dogmatische Anwendung von WSJF würde aber dazu führen, dass nur kleine Features gebaut werden, zu denen Aufwände und Wertbeiträge ermittelbar sind. Kleine und klare Features würden immer bevorzugt werden. Bei typischer Auslastung der Keyplayer führt dies zwangsläufig dazu, dass neuartige Themen nicht berücksichtigt werden können. Diese vielen kleinen Machbarkeitsstudien und Discovery-Tasks müssen explizit gefördert werden, andernfalls leiden alle neuen Themen unter einer zu strikten Priorisierungsmethode. Das beschriebene Priorisierungsvorgehen führt unweigerlich zum Aufbau von technischer Schuld und fehlender Datenintegrität. Ein Ausweg hierfür sind erweiterte Konzepte und ein anderes Mindset.
Die fehlende Reife von Datenprodukten
Vor einem Datenprojekt fehlt es meist an Reife für das Projekt oder für den Beginn der Produktentwicklung. Wenn Analysen oder Daten zu einem neuen Produkt fehlen, dann bieten Priorisierungs-Frameworks keine ausreichende Bewertungsgrundlage. Diese fehlende Reife für die Priorisierung kann sehr facettenreich sein, wodurch die Präsenz des Managements hier besonders gefordert ist: Es geht um die Definition der Anforderungen, den Zugriff auf den Benutzer oder die Definition des Kunden. Üblich ist auch die Suche nach einem Sponsor und/oder Budget. Oft fehlt es auch an einem definierten Rahmen, um neue Projekte mit dem Charakter eines Datenproduktes zu beginnen, weil es an Erfahrungswissen fehlt. Es kann auch an Voranalysen und Architekturvorgaben mangeln oder an einer unklaren Zuständigkeit. Datenprodukte mit breiter und vielfältiger Datenbasis sind besonders für den Kunden und Nutzer, sind aber auch besonders herausfordernd, weil sich die Ownership weit im Unternehmen verteilt. Eine zentrale Rolle bei Datenprodukten spielen Produktmanager und Product Owner. Sind diese Rollen nicht besetzt, fehlen die Vertreter, die den Initialfunken geben, um die ersten großen Hürden zu nehmen. Und von diesen gibt es genug. Hierbei spielt die Datenqualität eine zentrale Rolle.
Der Aspekt der fehlenden Datenqualität ist für Außenstehende oft etwas schwer greifbar und erscheint banal. Es geht dabei nicht nur um fehlerhafte Datensätze an sich, sondern um Fälle, in denen Daten nicht verknüpft werden können, Dubletten entstehen oder einige Datensätze mit Verspätung ankommen. Aus Sicht des Endanwenders sind es Störungen und Fehler. Die Datenqualität nachhaltig zu verbessern, erfordert viel Aufwand, Mühe und Engagement. Hiervon können viele Stakeholder betroffen sein, aber auch die Lieferkette oder die IoT-Befähigung von Endgeräten, die erst Jahre nach langwierigen Rollouts entsteht. Hier ist alles möglich, nichts ist fix! Erst ab Sichtung der Daten beginnt die Entwicklung des Datenproduktes.
Vor dem Projekt gilt es vor allem die Erwartungshaltung zu managen. Es fehlt aber noch an einem Team und der Steuerung und trotzdem muss eine Richtung vorgegeben werden. In den letzten Jahren haben sich Technologien und Methoden herausragend entwickelt und Plattformen sind viel besser als früher, aber die Arbeit an Datenqualität ist nahezu unverändert aufwändig und ganz schwer abschätzbar. Es gibt sehr viel technologische Unterstützung, ganz viel an Evolution, aber keine revolutionäre Entwicklung, weil es diese kaum geben kann.
Management von Datenprodukten und -projekten
Die Kunst besteht darin, gegenzusteuern, einzugreifen und zu korrigieren. Das Management von Datenprojekten oder einem Projektportfolio beginnt beim Management der Erwartungshaltung. Dazu wir eine detaillierte Analyse und Aufwandschätzung benötigt ergänzt um eine Architekturentwurf. Die Erwartungshaltung ist deshalb ein so großes Thema, weil mit vielen Datenprojekten ein Weg beschritten wird, der zu einem Produkt führt.
Sehr viele Datenprojekte enden nicht geplant. Sie werden meist in vielen Zyklen produktiv gesetzt und trotzdem ist der Backlog weiterhin gefüllt. Sobald der Kunde das Produkt nutzt, füllt sich der Backlog weiter. Projektleiter haben den Auftrag, abzublocken und den Projektauftrag zu erfüllen, und aus gutem Recht das Budget zu begrenzen.
Oftmals sind Projekte und Produkte nicht reif, weil das Umfeld, die Daten, die Plattform oder die Mitarbeiter nicht bereit sind. Dieses Umfeld bearbeiten wir als Interimsmanager vor allem mit dem Aspekt Verantwortungsübernahme fördern und Teamaufbau forcieren. Zentrale Aufgaben sind das Etablieren von Projekt- und Portfoliomanagement, die Budgetgenerierung und damit verbundene Priorisierung, das Einbetten in ein agiles Framework und Herstellen von Arbeitsfähigkeit.
Mittelfristig ist dann die passende Aufstellung der Teams zu vereinbaren und die Lücken zu schließen. Im Weiteren ist es notwendig für den Umgang mit Daten und der AI den passenden Rahmen zu schaffen. Es folgen das Etablieren von DevOps/MLOps, das Vorantreiben des Enablements der Plattformen und der beständige Aufbau des Data Assests.
Der phasenweise Ansatz
Viele Produkte kann man nicht von Beginn an planen und alle Anforderungen ins Detail kennen. Bei externen Kunden benötigt man das Feedback des Endkunden, bei internen Kunden müssen Benutzer mit den Daten arbeiten lernen. Generell benötigt eine Organisation eine Entwicklung zu datenorientierter und faktenbasierter Entscheidungsfindung. Das dauert und ein phasenorientierter Ansatz macht im Unternehmensumfeld meist mehr Sinn, weil die vielen Facetten von Daten erlebt werden müssen. Die schnelle Lieferung eines POC oder das Forcieren der Produktivsetzung sind wichtig, damit das notwendige Feedback generiert werden kann, aus denen sich Anforderungen ableiten. Vermessen wäre es, von einem Product Owner oder einem Produktmanager zu fordern, für komplexe oder einmalige Produkte die Detailanforderungen sofort ableiten zu können, ohne das Kundenfeedback zu haben.
Als Interimsmanager hat man die Vergleichsmöglichkeit, dass viele Konzerne mit großem Budget große Schritte Richtung Datenorientierung machen. Lleinere Unternehmen mit geringeren Mitteln erreichen nahezu das gleiche Ergebnis und machen oft einen „Flying Start“ in die Entwicklung von Datenprodukten.
Die datenorientierte Organisation
Die Organisation entwickelt sich mit jedem Datenprodukt, aber nicht so sehr durch Powerpoint-Slides sondern mit Erfolgsgeschichten und auch Misserfolgsgeschichten, wenn diese als Lernprozess zugelassen werden. Datenprojekte tragen Tücken in sich, die hier ausreichend diskutiert wurden. Als Verantwortlicher und als Organisation muss man einige dieser „Pitfalls“ erlebt haben, um ein „echtes“ Verständnis dafür zu entwickeln.
Mitarbeitern kann man den Umgang damit nur vorleben und nicht diktieren. Noch viel wichtiger ist die Teamentwicklung. Entscheidend ist die Ausrichtung daran, dass man ein kleines Projekt zwar als Individuum entwickeln kann, aber große Projekte und Produkte werden von Teams gebaut, von Menschen, die sich ergänzen, vertrauen und kompensieren. Entscheidend ist der kontinuierliche Aufbau des Teams. Diesen gilt es zu fördern, zu forcieren, zu stützen. Nicht die Leistung einer Person, eines Product Owners oder des Produktmanagers, eines Data Scientists oder eines Data Engineers zählt. Es zählt nur, was gemeinsam erarbeitet wird. Das Team und das Datenprodukt muss vorankommen und die Organisation und der einzelne Mitarbeiter daran lernen – der Ansatz und das Denken im System.
Was sonst noch bleibt ist, dass ein echter Bedarf gedeckt wird – also die Erfüllung der Kundenanforderung. Damit kommt der Priorisierung von Datenprodukten/-projekten ein außerordentlicher Stellenwert zu. Am Ende bestimmt es dann aber doch das Mindset des Mitarbeiters in der Organisation und die Strategie des Unternehmens.
