Einführung
AK: Konnichiwa. Willkommen im AI Automation Dojo. Die Show, in der wir uns das moderne Projektmanagement ansehen und uns fragen, ob das Gun-Chart nicht einfach durch ein Ouija-Brett ersetzt werden sollte. Heute wagen wir uns in die tückischen Gewässer der Auslieferung von KI-Projekten. Ihr wisst schon, wo der Projektplan eher eine starke Empfehlung ist und Deliverables gelegentlich ein Eigenleben entwickeln.
Um uns dabei zu leiten, haben wir einen besonderen Gast eingeladen, einen echten Delivery Manager aus dem echten Leben, der in den KI-Abgrund geblickt hat und überlebt hat, um davon zu erzählen. Wir werden über Projekte sprechen, bei denen die Anforderungen ein bewegliches Ziel sind. Die Schlüsselkomponente, das KI-Modell, ist im Grunde eine Blackbox mit einem „Here be dragon“-Schild darauf, und Erfolg wird oft definiert als: „Nun, diesmal hat es den Server nicht in Brand gesetzt.“
Ich bin euer Gastgeber, Andrzej Kinastowski, einer der Gründer von Office Samurai, wo wir glauben, dass der wichtigste Teil eines jeden Projektplans ein klar gekennzeichneter Notausgang ist. Wenn ihr jemals versucht habt, einem Raum voller Führungskräfte einen Confidence Score zu erklären, die einfach nur eine klare Ja-oder-Nein-Antwort wollen, könnte diese Episode eure Therapiesitzung sein. Also schnappt euch eure Lieblingskatana oder ein sehr detailliertes Risikoregister, und lasst uns loslegen.
Heute begrüßen wir Dagmara Sysuła, die als Delivery Managerin bei Office Samurai tätig ist. Sie ist vor vier Jahren zu uns gestoßen und hat sich zu der Person entwickelt, die im Grunde unsere gesamte Delivery verantwortet und mir so Zeit für Dinge wie Podcasts verschafft. Dagmara, willkommen im Podcast.
DS: Hallo, Andrzej. Vielen Dank für die Einladung.
AK: Wir werden über KI-Projekte sprechen. Sag mir, warum bist du diejenige, mit der ich über KI-Projekte spreche?
DS: Weil wir versuchen, KI-Projekte zu liefern, und ich denke, dass es heutzutage sehr wichtig ist zu wissen, wie man das macht – oder es zumindest auf irgendeine Weise zu versuchen – und sich bewusst zu sein, warum es schwierig sein kann oder warum es erfolgreich endet oder nicht und welcher Weg der beste ist, um KI-Projekte umzusetzen. Ich denke, dass KI – eigentlich ist der Podcast der Beweis dafür. Es ist derzeit ein sehr heißes Thema und jeder möchte diese Technologie anfassen.
Projektmethodik: die Notwendigkeit eines hybriden Ansatzes
DS: Irgendwie schon, aber wir wissen manchmal noch nicht, wie wir das richtig machen sollen. Wir versuchen, es auf die Weise zu tun, die wir bereits kennen, mit den Methoden, die wir kennen, und mit der Methodik, die wir kennen. Allerdings ist es nicht so einfach, wie wir zuvor gedacht haben.
AK: Worin unterscheidet sich das also, denn ich habe auch das Gefühl, dass diese Projekte zumindest zum jetzigen Zeitpunkt ziemlich anders sind als das, was wir bereits machen? Wie oder warum unterscheiden sie sich sehr stark von zum Beispiel einem klassischen RPA-Projekt?
DS: Sagen wir, dass wir im IT-Bereich im Allgemeinen meist zwei Arten haben, Projekte umzusetzen bzw. zu managen. Das ist zum einen der Wasserfall-Ansatz, bei dem alles strukturiert ist, man Meilensteine hat und vorhersehbar ist, was der nächste Schritt ist. RPA ist definitiv ein Teil des Wasserfalls. Warum? Weil es sich in der Regel um kurze Projekte handelt, maximal 300 Stunden, und oft sogar deutlich kürzer. Und man hat sehr strikte Schritte: Analyse, Entwicklung, Testen, Deployment und Wartung.
Im Agilen ist es anders, weil man in Sprints arbeitet, etwas entdeckt, überprüft, Retrospektiven macht und in solchen Zyklen vorgeht. Aber es ist dennoch in gewisser Weise vorhersehbar, weil man ein bestimmtes Projekt liefert. Bei KI muss man sich etwas stärker auf Experimente konzentrieren, deshalb ist Agil definitiv der beste Weg.
Allerdings muss man trotzdem irgendwie mit dem Budget umgehen, zum Beispiel mit den Stakeholdern und den Sponsoren. Deshalb muss man auch den Wasserfall im Blick behalten. Darum müssen wir das ein wenig mischen und eine neue Methodik finden. Wahrscheinlich nennen wir es vorerst zum Beispiel hybrid, weil wir experimentieren. Wir nutzen Experimente auf agile Weise, und hier ist der agile Kanban-Ansatz absolut perfekt, denn Kanban wird meist in Wartungsprojekten eingesetzt. Das Scoring erfolgt vor dem Deployment, und für KI ist das, denke ich, ein sehr wichtiger Moment, um sicherzugehen, dass das, was wir vorbereitet haben, bereit für die Implementierung ist.
Natürlich kennt man das auch als ein großes Wasserfallprojekt, nur in kleinen Stücken. Was ich aus der Perspektive von Office Samurai sagen würde: Wir haben vor ein paar Jahren Retrospektiven für alle Projekte eingeführt, die wir unseren Kunden liefern.
Die entscheidende Rolle von Retrospektiven in KI-Projekten
DS: Dein Projekt wird mit einer Retrospektive abgeschlossen, und was in der Retrospektive sehr, sehr wichtig ist – und diesen Teil der agilen Methodik mag ich sehr – ist, dass wir zusammensitzen: das Delivery-Team (denn wir haben Analyse, Analytics, Entwickler, Leader, Architekten, also alle, die dieses Projekt berührt haben). Wir haben einen Raum, um sehr ehrlich über alles zu sprechen, was passiert ist – über die guten Dinge, die schlechten Dinge, was wir bereits gelernt haben, was wir während dieses Projekts falsch gemacht haben und was – und das ist sehr, sehr wichtig, etwas, das ich wirklich liebe – die Maßnahmen. Was wir beim nächsten Projekt besser oder anders machen können oder was wir bereits gelernt haben und in Zukunft umsetzen können. Ich denke, dass es bei KI-Projekten absolut entscheidend ist, nach dem Ende des Projekts eine Art Retrospektive zu haben und einfach zu wissen, was wir gelernt haben, denn die meisten dieser KI-Projekte sind möglicherweise experimentell oder dienen einfach dazu, etwas Neues zu entdecken.
AK: Ich denke, die Retrospektive ist etwas, das – als du sie in unserer Organisation eingeführt hast – für manche Menschen am Anfang ein wenig schwierig war. Bei Projekten, bei denen es vielleicht etwas hektischer zuging oder etwas schiefgelaufen ist, ist es extrem wichtig, dass wir das machen, weil wir sonst nicht aus diesen Fehlern oder vielleicht Problemen lernen, die wir hatten. Wenn es um KI-Projekte geht, weil sie viel neuer und deutlich weniger vorhersehbar sind, machen diese Zusammenfassungen, diese Abschlüsse, sie so wichtig.
DS: Es ist auch wichtig, das Projekt in kleinere Teile aufzuteilen und diese Retrospektive nach dem ersten kleinen Zyklus oder dem zweiten durchzuführen. Das ist bei KI-Projekten manchmal schwierig, weil diese – wie du erwähnt hast – nicht vorhersehbar sind. Manchmal denken wir, dass wir eine Art Plan haben, aber er funktioniert nicht, oder er verändert sich, oder die Technologie verändert sich, und wir müssen die Art und Weise ändern, wie wir das Projekt liefern. Deshalb ist es auch wichtig, einen solchen Boxenstopp einzulegen und dem Sponsor eine Art Feedback zu geben. Der Checkpoint, die Retrospektive, ist perfekt für KI-Projekte.
AK: Besonders dann, wenn die Dinge nicht so funktionieren, wie wir es erwartet haben. Wir haben einige aktuelle Beispiele für Projekte, die wir vor ziemlich langer Zeit begonnen haben. So schmerzhaft es auch ist, manchmal müssen wir innehalten und uns fragen: Okay, vielleicht war es zu dem Zeitpunkt, als wir gestartet sind, die richtige Entscheidung, diese Technologie zu nutzen. Aber inzwischen haben wir eine andere. Vielleicht brauchen wir ein kleines Remake. Vielleicht müssen wir einen Schritt zurückgehen. Denn KI-Technologien – und nicht nur Gen AI – auch die KI-Technologien, die wir stark nutzen, wie UiPaths Document Understanding oder Communications Mining, entwickeln sich ebenfalls sehr schnell weiter. Ich denke, es ist vollkommen richtig, dass man nicht nur am Ende eine Retrospektive macht, sondern während des Projekts diese Stopps einlegt, um zu überlegen: Okay, machen wir gerade das Richtige?
DS: Ich denke, das ist sehr wichtig. Der Bedarf an einer Retrospektive kommt in erster Linie von unseren Entwicklern. Für mich ist das ein Teil der Kultur, die ich zu etablieren versucht habe, und das ist absolut fantastisch, weil sie dadurch einfach die Projektanforderungen verstehen und den Projektablauf begreifen. Es ist wirklich großartig, dass das aus dem Team selbst kommt.
Methoden zu kombinieren: die Notwendigkeit des Wasserfalls für Sponsoren
AK: Du hast Kanban erwähnt, das ein sehr grundlegendes Werkzeug ist. Du hast die Retros erwähnt. Was noch? Gibt es weitere Tools oder methodische Bausteine, von denen du denkst, dass sie KI-Projekten sehr helfen?
DS: Ich habe zuvor den Wasserfall erwähnt, und ich denke, dass wir ihn unbedingt einbeziehen müssen, weil wir irgendwie mit den Sponsoren kommunizieren müssen. Mit den Menschen, die KI-Projekte oder die Technologie einfach nicht verstehen, weil sie kompliziert ist. Man braucht ein sehr gutes technisches Verständnis, um zu wissen, warum das passiert.
Aber die Sponsoren haben das Bedürfnis, KI-Projekte in der Organisation zu haben. Das steht mit Sicherheit in den Zielvorgaben – fast überall – und sie haben ein Budget und eine Art von Meilensteinen. Sie müssen außerdem in irgendeinem Lenkungsausschuss an ihre Vorgesetzten, an ihre Direktoren berichten, wie das Projekt vorankommt. Deshalb brauchen wir hier auch ein Stück Wasserfall, um sicherzustellen, dass wir nicht das gesamte Budget verbraucht haben.
AK: Man kann es als lästig empfinden, das tun zu müssen, aber in der Regel haben Kunden keine unbegrenzten Budgets und keine unbegrenzte Zeit, um Dinge umzusetzen. Wir brauchen diesen Wasserfall-Pfad, um mit den Stakeholdern zu kommunizieren und gewissermaßen auch eine Selbstdiagnose zu machen. Wo stehen wir? Sind wir mit der Geschwindigkeit unterwegs, die wir wollten? Wollen wir pivotieren? Wollen wir die Technologie wechseln? Sind wir auf dem Weg, etwas zu erreichen?
KI-Projekte sind langfristige Wartung, keine kurzfristigen Produkte
DS: Was beim Thema Budgetierung ebenfalls wichtig ist, und das ist für Sponsoren vielleicht besonders relevant: KI-Projekte sind aus unserer Sicht nichts, bei dem man ein direktes Endprodukt erhält. Es ist ein langfristiger Wartungsprozess. Sobald man sich für ein KI-Projekt oder einfach ein KI-Tool bzw. eine Lösung entscheidet, muss man sich darüber im Klaren sein, dass sich die Technologie vielleicht schon in einem halben Jahr so stark verändern wird, dass wir etwas an diesem Projekt anpassen müssen.
Die Modelle lernen die ganze Zeit. Man muss sie irgendwie warten. Es ist nichts, bei dem man Geld auf den Tisch legt und nach drei, sechs oder sieben Monaten ein Produkt hat. Wir erkennen derzeit drei oder vier Hauptarten von KI-Projekten auf dem Markt. Die erste ist in der Regel ein POC oder einfach ein experimentelles Projekt. Wir wollen etwas ausprobieren.
Später haben wir die größten Projekte, das sind die Deployment-Projekte. Als drittes sehe ich heute den Kauf eines bereits bestehenden KI-Tools, zum Beispiel Copilot, und dessen Einführung in unsere Teams. Aber es ist immer wie bei jedem einzelnen Tool oder jeder Anwendung: Man kauft sie, aber man muss wissen, wie man sie benutzt. Wenn wir darüber nachdenken, Copilots oder andere Tools vom Markt zu implementieren, müssen wir uns bewusst sein, dass wir auch Wissen einkaufen müssen oder zumindest Schulungen, um den Menschen zu zeigen, wie sie diese Tools nutzen sollen.
AK: Implementierung bedeutet nicht nur, Lizenzen zu kaufen und sie auf den Computern der Mitarbeitenden zu installieren, richtig? Sie müssen wissen, wie man sie benutzt.
Der vierte Projekttyp: KI-Strategie
AK: Du hast über drei Arten von Projekten gesprochen. Was ist das vierte?
DS: Ich denke an die Strategie. Viele Unternehmen denken derzeit über eine KI-Strategie nach. Ich würde sagen, das ist die vierte Art, die ich aktuell sehe. Es ist sehr wichtig zu wissen, was wir implementieren wollen, welche Art von Tools und mit welchen Ressourcen wir arbeiten werden. Es ist extrem wichtig, ein Projekt nicht ohne eine übergreifende Strategie umzusetzen und dabei nicht auch die Kultur, die Denkweise und die Organisation zu verändern.
AK: Aber das ist wieder etwas, das wir aus den Fehlern lernen, die viele Unternehmen bei RPA gemacht haben. Man muss all diese Dinge gewissermaßen parallel machen. Es sollte parallel laufen, denn sobald man eine Strategie entwickelt, muss man auch eine gewisse Kenntnis darüber haben, was in unserer Organisation möglich ist. Es ist absolut wichtig, eine Strategie zu haben, aber man sollte nicht zuerst nur mit der Strategie beginnen.
DS: Ja. Genau.
AK: Oder man muss eine Menge Geld an irgendeine Beratung zahlen, damit sie eine für einen vorbereitet. Und übrigens werden sie wahrscheinlich die Hälfte davon mit Gen AI generieren. Dagmara, ich weiß, dass du eine Reihe von Wahrheiten oder Regeln für das Projektmanagement entwickelt hast. Sag mir, ich bin wirklich gespannt zu hören, was du denkst, was diese sein könnten.
Die 10 goldenen Regeln für das Management von KI-Projekten
DS: Die erste Regel ist definitiv das Management der Talente. Man muss wissen, welche Fähigkeiten und welche Ressourcen man hat. Zuallererst muss man ein Team aufbauen. Zweitens müssen diese Menschen auch geschult werden.
AK: Aber das hängt auch mit diesen Technologien zusammen. Es sind extrem komplexe Technologien, aber die Tools, mit denen man diese Technologien nutzen kann, sind nicht so kompliziert, richtig?
DS: Das stimmt. Man braucht oft einen sehr guten Analysten. Die Einstiegshürde ist nicht mehr, dass man wirklich sehr gut in Mathematik und Statistik und so weiter sein muss. Man kann auch ohne diese Art von Wissen ein sehr guter Power User sein. Deshalb sind Business-Analysten perfekt geeignet, um mit KI zu arbeiten.
DS: Wenn ich zur zweiten Regel übergehen möchte, dann geht es darum, eine Art AI Champions zu finden und sie in unserer Umgebung sichtbar zu machen.
Eine weitere Regel, die meiner Meinung nach besonders für Manager gilt, ist das Management der Erwartungen der Sponsoren. Man muss ihnen zeigen, dass dies kein sehr geradliniger, einfacher Weg ist. Wenn wir eine KI-Lösung haben wollen, müssen wir ein Risiko eingehen.
AK: Diese Projekte sind gewissermaßen Forschung und Entwicklung, weil man nicht sicher ist, ob es funktionieren wird – da diese Technologien so neu sind. Wir wissen es nicht wirklich. Wir können denken, dass etwas funktionieren wird, aber es kann Überraschungen geben.
DS: Die vierte Regel ist Lernen. Wir müssen viel Aufwand betreiben, um selbst zu lernen und unsere Teams zu schulen. Ich denke, das ist ein sehr wichtiger Teil, und es ist etwas, das wir in unserer Organisation gerade wirklich brauchen: einfach zu lernen.
AK: Zu lernen, dieses Wissen zu teilen und gewissermaßen zu beobachten, was vor sich geht. Bei der derzeit so schnellen technologischen Entwicklung kann das, was man heute weiß, morgen schon überholt sein.
DS: Wir müssen uns dessen bewusst sein und dieses Wissen haben.
AK: Wir müssen eine fundierte Entscheidung treffen.
DS: Ein weiterer Punkt ist, dass wir wirklich klare Daten haben müssen, bevor wir mit einem KI-Projekt beginnen. Wenn man ein Chaos in den Daten hat, unstrukturierte Daten, ist es viel schwieriger, das Modell richtig zu trainieren und später korrekte Antworten zu erhalten.
AK: Gen AI ist besser darin, mit unsauberen Daten umzugehen als zum Beispiel klassisches Machine Learning, aber es ist immer noch ein großes Problem, und wir müssen in der Lage sein, es zu managen. Wir werden niemals zu 100 % saubere Daten haben, aber wir müssen gewissermaßen danach streben.
DS: Es ist wirklich wichtig, die Modelle auch richtig zu warten. Das ist der nächste Punkt, die Wartung. Ein KI-Projekt endet nicht als ein einfaches Produkt am Schluss. Es wird immer gewartet werden müssen.
AK: Besonders bei Gen-AI-Technologien ist das Testen ziemlich schwierig, weil man nicht-deterministische Ergebnisse erhält. Man braucht eine Möglichkeit, sie gründlich zu testen, um sicherzustellen, dass sie sich im Laufe der Zeit nicht verschlechtern.
DS: Definitiv ist das Testen etwas, das KI-Projekte von anderen Projekten unterscheidet, die wir auf dem Markt haben, wie IT-Projekte, RPA-Projekte oder andere. Ich denke, bei all diesen KI-Projekten müssen wir sicherstellen, dass sie ethisch sind und dass wir in unserer Organisation transparent kommunizieren. Wir müssen sicherstellen, dass wir vermitteln, was das Tool uns bringen wird, wie wir damit arbeiten sollen, und wir sollten dies sehr klar an die Organisation kommunizieren, damit sich die Menschen sicher fühlen.
DS: Um auf diese Punkte zurückzukommen: Ich habe auch über Messgrößen und KPIs nachgedacht. Wir müssen immer sicherstellen, wie wir nachweisen können, dass etwas gut oder schlecht läuft, und wir müssen auch wissen, wie wir den Einfluss von KI in unserer Umgebung messen können.
AK: Man muss über die Kennzahlen nachdenken, die es ermöglichen, das zu tun.
DS: Ich denke, dass auch die Kommunikation und das Nachdenken über einen Kulturwandel sowie Offenheit in unserer Organisation sehr wichtig sind. Ebenso das Management der Erwartungen, denn diese sind manchmal sehr, sehr hoch.
AK: Die Erwartungen können extrem hoch sein. Menschen gehen auf Konferenzen und hören dort Berater, die ihnen im Grunde unrealistische Versprechen verkaufen. Man muss das Ganze bodenständig halten und keine Dinge versprechen, die man nicht in der Lage sein wird zu liefern, denn das könnte das Ende des KI-Programms und der KI-Strategie sein.
DS: Genau. Der letzte Punkt ist, offen für Veränderungen zu sein. Die Technologie verändert sich sehr, sehr, sehr schnell. Nach einem halben Jahr könnte man es in den Mülleimer werfen, weil die Technologie bereits von einem anderen Unternehmen entwickelt wurde und man sie einfach auf dem Markt kaufen kann – man muss sie nicht selbst bauen.
Schlussfolgerung
AK: Das waren Dagmaras 10 goldene Regeln für das Management von KI-Projekten. Ich denke, das wäre ein großartiger Artikel für den Wissensbereich unserer Website.
DS: Wir können dem folgen.
AK: Dagmara Sysuła, vielen Dank, dass du an dieser Podcast-Episode teilgenommen hast und deine Gedanken und Erfahrungen zu KI-Projekten mit uns geteilt hast.
DS: Ich mache mir Sorgen, dass wir in ein paar Monaten all diese Regeln auch in den Mülleimer werfen können, weil sich etwas ändern wird. Aber wir sind dafür offen und warten auf eine gute Zukunft.
AK: Und das ist unsere Auslieferung für diese Episode. Hoffentlich ist sie pünktlich angekommen, innerhalb des Budgets geblieben und hat unterwegs keine seltsamen neuen Features halluziniert. Vielen Dank, dass ihr diesen Eimer voller Informationen in eure Gehirne heruntergeladen habt. Ein riesiges Dankeschön an unsere Gästin Dagmara Sysuła, die kampferprobte Delivery Managerin, die uns durch das Chaos navigiert hat, ohne dass auch nur ein einziges Jira-Ticket verloren gegangen ist. Und natürlich an Anna Cubal, unsere eigene Meisterin der Auslieferung, die diese Show aus dem legendären Wodzu Beats Studio produziert, unserer ganz eigenen Entwicklungsumgebung. Bis zum nächsten Mal: Mögen eure Daten sauber sein und eure Stakeholder vernünftig. Mata ne.
