
Thomas Pförtner
25.07.2018
- Anmelden oder Registieren, um Kommentare verfassen zu können
Genügen für die vielbeschworene Digitale Transformation die herkömmlichen Instrumente des Projektmanagements? Welche Anforderungen müssen Projektmanager hierfür erfüllen? Dr. Matthias Eberspächer befragte hierzu rund ein Dutzend Expertinnen und Experten. Er stellt überraschende Ergebnisse und daraus abgeleitete Thesen über die Zukunft des Projektmanagements zur Diskussion.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Genügen für die vielbeschworene Digitale Transformation die herkömmlichen Instrumente des Projektmanagements? Welche Anforderungen müssen Projektmanager hierfür erfüllen? Dr. Matthias Eberspächer befragte hierzu rund ein Dutzend Expertinnen und Experten. Er stellt überraschende Ergebnisse und daraus abgeleitete Thesen über die Zukunft des Projektmanagements zur Diskussion.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Die digitale Transformation ist in aller Munde. Es vergeht kaum ein Tag, an dem nicht ein Politiker oder Wirtschaftsvertreter die Digitale Transformation und deren Auswirkungen auf irgendeinen Bereich der Gesellschaft beschwört. Selbstfahrende Autos, Pflegeroboter, Kryptowährungen und viele andere Themen, die wir noch vor zehn Jahren in das Reich der Science-Fiction abgeschoben hätten, bestimmen die aktuelle gesellschaftliche Diskussion.
Uneinigkeit herrscht allerdings darüber, wie die digitale Transformation umzusetzen ist. Eines ist jedoch klar: Der Prozess der digitalen Transformation wird in den allermeisten Fällen in Form von Projekten durchgeführt. Dies führt zu den Fragen: Brauchen wir ein neues Projektmanagement? Wenn ja: Welches Projektmanagement ist für diese Art von Projekten sinnvoll und angemessen? Und vor allem: Brauchen wir eine neue Art von Projektleitern?
Dieser Artikel präsentiert das Ergebnis von Interviews und Gesprächen mit etwa einem Dutzend erfahrenen Beratern und Projektmanagern aus dem In- und Ausland, in denen ich der Frage nachgegangen bin, ob und wie sich das Projektmanagement von digitalen Transformationsprojekten von anderen Projekten unterscheidet oder unterscheiden sollte. Alle Gesprächspartner hatten bereits eigene Erfahrungen mit dem digitalen Transformationsprozess gesammelt. Der Artikel gibt somit den Stand einer Expertendiskussion wieder und erhebt nicht den Anspruch, validierte Forschungsergebnisse zu präsentieren. Ich möchte damit zur Diskussion beitragen und freue mich über Ihre Rückmeldungen.
Eine grundlegende Erkenntnis der Fachgespräche war, dass der Prozess der digitalen Transformation Programm-Charakter aufweist: So hat die digitale Transformation eines Geschäftsprozesses einen definierten Anfang und mit der Einführung des neuen, digital transformierten Geschäftsprozesses auch ein definiertes Ende. Wie wir sehen werden, umfasst die Transformation zahlreiche einzelne, asynchron gestartete Projekte, die alle ein gemeinsames Ziel verfolgen. Dieses Ziel ist zu Beginn des Prozesses der digitalen Transformation eher in Form von Visionen statt "SMART" formuliert. Jede einzelne digitale Transformation ist einmalig und wird arbeitsteilig in Teams durchgeführt.
Nach den Erfahrungen der Mehrheit der Gesprächspartner lässt sich der digitale Transformationsprozess, wie in Bild 1 gezeigt, in die drei Phasen "Ideation", "Design" und "Realization" gliedern. Häufig dient die Ideation-Phase dazu, unter Anwendung kreativer Methoden, wie z.B. Design Thinking, in Workshops Ideen für die digitale Transformation eines Produkts, Dienstes oder Geschäftsprozesses zu entwickeln.
Beispiel: Eine solche Idee könnte darin bestehen, dass ein Urlauber in den Bergen spontan beim Frühstück entscheidet, Bergsteigen oder Skifahren zu gehen und für diese Aktivität eine Tagesunfallversicherung über sein Smartphone abschließen möchte. Der Anwendungsfall geht natürlich über den Abschluss der Versicherung hinaus. Der Abschluss der Versicherung über das Smartphone ist ein sogenannter "Touch-Point" (also eine Interaktion zwischen Kunde und Dienstleister), der im Rahmen einer Design-Phase weiter ausgearbeitet werden muss. Der vollständige Anwendungsfall kann mehrere Touch-Points enthalten, wie z.B. die Meldung eines Unfalls, die Stornierung oder Verlängerung der Versicherung, die Buchung von Zusatzoptionen oder den Abschluss weiterer Versicherungen. Zu jedem dieser Touch-Points könnte ein eigenes Design-Projekt gestartet werden.
Bild 1: Die Programm-Phasen eines digitalen Transformationsprozesses
Die Ideation-Phase selbst besteht aus einem oder einer kleinen Reihe von Workshops, bei denen ein Moderator oder ein Moderatorenteam zusammen mit ausgewählten Mitarbeitern einer Organisation nach geeigneten Transformationen sucht. Die Ideation-Phase ist daher kein eigenes Projekt, sie dient lediglich der Festlegung des Umfangs für die sich anschließende Design-Phase. Die Ideation-Phase könnte als inhaltliche Auftragsklärung für das Programm verstanden werden.
Erster Monat kostenlos,
dann 24,95 € pro Monat
Know-how von über 1.000 Profis
Methoden für alle Aufgaben
Websessions mit Top-Expert:innen
25.07.2018
25.07.2018
25.07.2018
25.07.2018
25.07.2018
25.07.2018
25.07.2018
25.07.2018
26.07.2018
26.07.2018
27.07.2018
27.07.2018
25.07.2018
26.07.2018
29.07.2018
29.07.2018
30.07.2018
08.08.2018
19.02.2020
„DTD-Projekte sind komplexer, aber nicht komplizierter als die beiden anderen Projekttypen“
Hallo Herr Dr. Eberspächer,
diese Aussage in Ihrem Artikel erschließt sich mir nicht.
Wenn ich der einschlägigen Literatur folge, dann beschreibt der walisischen Gelehrten Dave Snowden in seinen, in der Welt der Agilen Methoden anerkannten, Framework „Cynefin“ (Wikipedia: Cynefin-Framework)
• Complicated/kompliziert: Systeme, in den es klare Beziehungen zwischen Ursache und Wirkung gibt, die jedoch (gegenüber einfachen Systemen) die Anwendung von Fachwissen erfordern, um diese zu analysieren/verstehen.
• Complex/komplex: Systeme, in denen die Beziehung zwischen Ursache und Wirkung nicht im Voraus vorhergesagt werden sondern nur im Nachhinein wahrgenommen werden kann.
Somit ist Ihre oben zitierte Aussage in sich widersprüchlich.
So kann ich auch der daraufhin geschlussfolgerten Aussage nicht folgen, dass „klassische“, plangetriebene PM-Methoden, die sie aufgeführt haben, ausreichend seien, um diese komplexen Projekte zu steuern. Auch wenn Sie in Rahmen der Kommentare klarstellen, das sich Ihr Artikel nur auf die Designphase des Transformations-Prozesses bezieht: Gerade in dieser Phase habe ich bei Projekten („einmaliges Vorhaben“) nicht nur im Rahmen der Digitalisierung mit komplexen Umgebungen zu tun, also Systemen, in denen Ursache-Wirkung-Beziehungen nicht eindeutig sind (also eben nicht „kompliziert“!).
Und wenn ich den Ausführungen von Prof. Dr. Peter Kruse in seinem Video "Wie reagieren Menschen auf wachsende Komplexität …" (siehe YouTube) folge, den "zerstören Sie ein komplexes System, wenn sie es wie ein kompliziertes System behandeln". Denn: Komplizierte Systeme können sie beherrschbar machen, indem sie es in kleinere Teile zerlegen. Komplexe Systeme aber eben nicht!
Oder welche Definition von Kompliziertheit bzw. Komplexität legen Sie Ihrer Aussage zugrunde?
04.03.2020
Hallo Herr Bertsch,
vielen Dank für Ihren Kommentar! Ich musste mich erst nochmal in das Thema hineindenken, deshalb meine verspätete Antwort.
Zunächst bezieht sich meine Analyse ausschließlich auf das Projektmanagement, nicht auf die Inhalte des Projekts. In dem zitierten Satz meines Artikels habe ich wohl kompliziert und komplex genau falsch herum verwendet. Um sicher zu gehen habe ich eine Weile über ein geeignetes Beispiel nachgedacht. Als Physiker ist mir leider nur ein physikalischer Vergleich eingefallen, ich hoffe, es ist trotzdem verständlich.
Die Bewegung eines Pendels wird durch den harmonischen Oszillator beschrieben. Seine Lösung ist die Sinusfunktion. Wenn ich 100 Pendel koppele, z.B. indem ich sie mit einem Faden verbinde, benötige ich zur Beschreibung ihrer Bewegung 100 miteinander gekoppelte Gleichungen. Jede einzelne wird wieder durch die Sinusfunktion gelöst, um die genaue Phasenverschiebung zu berechnen muss ich aber die 100 gekoppelten Gleichungen lösen. Das ist sehr aufwändig, dafür brauche ich aber keine neue Mathematik.
Die Bewegung dreier Massepunkte im Vakuum nennt man Dreikörperproblem. Die Bewegungsgleichung lässt sich leicht aufstellen, aber sie hat keine analytische Lösung. Um sie zu lösen bräuchte ich eine neue Mathematik.
Meines Erachtens ist das Management von DTD-Projekten vergleichbar mit gekoppelten Pendeln: Alles hängt mit allem zusammen und beeinflusst sich gegenseitig, jede kleinste Störung kann zum Ausschlagen des gesamten Systems führen. Die Ziele können sich täglich ändern, ganze Klassen von Risiken können neu hinzukommen oder wegfallen, das gleiche gilt für ganze Gruppen von Stakeholdern. Das führt u.a. dazu, dass ich mir langfristiges planen sparen kann. Stakeholder und Risikomanagement aber nicht.
Aus dem verfügbaren Kanon von PM-Methoden - und auch agilen Ansätzen - gibt es aber ausreichend Methoden und Hilfsmittel um mit diesen Herausforderungen umzugehen. Natürlich kann ich zur Planung und Steuerung auch ein Backlog verwenden, ein getaktetes Vorgehen wählen und Retrospektiven durchführen. Etwas völlig Neues brauche ich aber zur Steuerung dieser Projekte nicht.
Thorsten Wilkens
25.07.2018