Was Experten erwarten Braucht die digitale Transformation ein neues Projektmanagement und neue Projektmanager?

Braucht die digitale Transformation ein neues Projektmanagement und neue Projektmanager?

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.

Management Summary

Was Experten erwarten Braucht die digitale Transformation ein neues Projektmanagement und neue Projektmanager?

Braucht die digitale Transformation ein neues Projektmanagement und neue Projektmanager?

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.

Management Summary

Wir empfehlen zum Thema Karriere
2 Tage
05.12.2024
Deep Reading - Schneller, klüger und nachhaltiger lesen

In kürzester Zeit anspruchsvolle Fachtexte lesen und verstehen –  steigern Sie in nur zwei Tagen Ihre Lesegeschwindigkeit und Aufnahmefähigkeit! Mehr Infos

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.

Digitale Transformationsprozesse sind Programme!

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.

Programm-Phasen: Ideation – Design – Realization

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

Bild 1: Die Programm-Phasen eines digitalen Transformationsprozesses

Ideation-Phase

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.

Alle Kommentare (21)

Thorsten
Wilkens

Vielen Dank für diese Darstellung von DTD Projekten bzw. die Abbildung auf die Anforderungen an Projektmanager. Besonders gut finde ich die Beschreibung/Bewertung, dass Projektmanager zukünftig als Unternehmensberater agieren müssen. Ich glaube, an einer digitalen Transformation sehr vieler Bereiche bzw. Prozesse geht kein Weg vorbei. Nochmals vielen Dank!

 

Guest

Hervorragend! Gerade gestern habe ich an anderer Stelle einen Kommentar zur steigenden Bedeutung von Werten, Kultur und Strategie in der Digitalen Tranbsformation verfasst. Ihr Bild 4 zeigt wie richtig das ist. Insgesamt wird die Problematik sehr gut erfasst und aufbereitet. Es wird deutlich, dass die Digitalisierung / Digitale Transformation und die Begriffswelt der Agilität zusammengehören.

 

Regina
Fehling

Digitalisierung ist eines der aktuellen Buzz Wörter. Oft werden Initiativen hierzu gestartet ohne ein klares Bild, wie der Zielzustand aussehen soll. Hier bietet agiles Projektmanagement das perfekte Framework, um genau diese Prozesse zu begleiten. Es erfüllt den Wunsch, die Themen in einem Monitoring darzustellen und nachhaltig weiterzuverfolgen mit gleichzeitig gegenüber klassischem PM reduziertem Reporting. Diese Vorgehen ermöglicht eine deutliche Fokussierung auf die inhaltlichen Themen und befreit das Team von nicht wertschöpfendem Verwaltungsaufwand. Der Artikel ist ein wertvoller Beitrag zu diesem Umdenken und stellt den Prozess beginnend mit einer Ideation / Design Thinking Phase sehr gut dar. Bis zur Realisierung können Änderungen agil aufgenommen werden, so dass sichergestellt wird, dass die entwickelte IT-Lösung mindestens State of the Art und im Idealfall disruptiv ist.

 

Hartmut
Goetze

Danke sehr für diesen anregenden Artikel. . Ein Gedanke, der mir bei der Lektüre kam: Wirksame Projektleiter haben in allen Projekttypen immer schon vor allem durch hohe Sozialkompetenz ausgezeichnet, die die Teams dazu bringen, ihr Potential maximal einzubringen. Unabhängig vom Vorgehensmodell. Bei Wasserfall und Agilen Frameworks gleichermaßen. Auf Neudeutsch heißt diese Fähigkeit „Leadership“. . Nur in Fällen, wo das Ziel in fast allen Details präzise beschrieben und beschreibbar ist, wo die Mitarbeiter ohne kreative Leistung Arbeitspakete abarbeiten, hat auch ein kaltschnäuziger Command-and-Control-Projektleiter eine Chance.

 

Doris Paulina
Ballmann

Vielen Dank für den sehr informativen Artikel. Wir beschäftigen uns ebenfalls mit diesem Thema und haben an der Umsetzung von Robotics bereits feststellen müssen, dass sich der Projektansatz verändern muss. Ich nehme Ihre Hinweise gerne als Stütze für meinen weiteren Argumentationen im Haus. Vielen, vielen Dank!

 

Profile picture for user tomas.schiffbauer@intelli-it.de
Tomas
Schiffbauer

Vielen Dank für diesen Artikel! Ich stimme mit vielen Aussagen im Artikel überein. Ein, wie ich finde, extrem relevanter Aspekt wird allerdings so gut wie nicht dargestellt: Bei einem DTD Projekt oder Programm handelt es sich in erster Linie um ein Veränderungsprozess für die Organisation. Also ein Projekt zur Organisationsentwicklung! - Changemanagement Das ist genau die Vorannahmen, die viele Unternehmen vergessen und deshalb die Digitalisierung und die damit verbundenen Projekte nur auf die technologischen Themen auslegen. Für mich ist das zu kurz gesprungen. - Die Technik haben wir noch immer in den Griff bekommen. Die meisten gescheiterten Projekte sind an den Menschen gescheitert. Am Mindset, an der Kultur oder der Haltung. Es wird uns mit den Projekten zur Digitalisierung genauso ergehen, wenn wir nicht grundlegend die Kultur, Bereitschaft und damit das Mindset, die DNA, in den Unternehmen verändern. Das erreichen wir natürlich nur mit den Mitarbeitern und nicht per Dekret. Deshalb sehe ich dieses Vorhaben auch als Programm angelegt und ja, es ist ungewiss wie es ausgeht. Wir sollten unsere Unternehmen darauf vorbereiten, das die Veränderung der Normalzustand ist. Stichwort VUCA/VUKA. Wenn wir es schaffen diesen Schritt zu gehen, dann werden viele im Artikel beschrieben Aspekte und Herausforderungen zur Unternehems-DNA gehören. Damit steigen die Erfolgschancen von „Technik-Projekten“ in einer komplexer werdenden und kurzzyklischen Umwelt. In dieser Welt bestehen die internen und externen Kunden immer mehr auf eine Befriedigung ihrer Needs, Bedürfnisse und Begeisterungsanforderungen. Was übrigens ein wesentlicher Aspekt von Design Thinking ist.

 

Profile picture for user matthias@eberspaecher.name
Matthias
Eberspächer
Dr.

Sehr geehrte Damen und Herren, . vielen Dank für ihre zahlreichen zustimmenden Kommentare. . Zur angesprochenen Agilität: Selbstverständlich schreit der Prozess der digitalen Transformation geradezu nach dem Einsatz agiler Konzepte! Dieser Beitrag beschränkt sich allerdings auf die Designphase des Transformations-Prozesses. Diese Einschränkung war notwendig, um den Untersuchungsgegenstand "Projektmanagement" sauber (gegen Programm- & Projekt-Portfolio-Management) abzugrenzen. Auch in dieser Phase sind agile Vorgehensmodelle bereits sinnvoll und mehrwertig, der wirklich große Nutzen im Kontrast zum traditionellen Vorgehen stellt sich aber m.E. erst mit Beginn der Realisierung ein. Insofern bin ich im Artikel nicht weiter darauf eingegangen, welche agilen Konzepte bereits in der Design-Phase besonders erfolgversprechend sind. Dies könnte Gegenstand weiterer Untersuchungen sein. . Zum Changemanagement: Es ist absolut richtig, dass das größte Risiko in der fehlenden Akzeptanz der neu entwickelten Software und den damit veränderten Prozessen liegt. Insofern würde im Rahmen der Realization-Phase auch ein eigenes, die digitale Transformation begleitendes Change-Projekt gestartet - die meisten Teilnehmer der Studie haben das auch als Erfolgsfaktor genannt. Da dieses Change-Projekt erst im Anschluss an die Design-Phase gestartet würde, kommt dieser Aspekt in dem Beitrag etwas zu kurz.

 

Dazu möchte ich nochmals kurz Stellung beziehen ;-) Ich bin davon überzeugt, dass der umgekehrte Weg der langfristig erfolgreichere und auch nachhaltigere ist! Den Change erst in der Realisierungsphase eines (IT-)Projektes anzugehen halte ich für zu spät. Zumal er dann nur für dieses Projekt (Team & Umfeld) als flankierende Maßnahme erfolgen würde. Für mich ist das Change-Programm der Rahmen in dem die Organisation und ihre DNA auf die Zukunft ausgerichtet wird. Innerhalb dieses Rahmens sollten dann „Technologieprojekte“ Schritt für Schritt und als Leuchtturmprojekte umgesetzt werden. Dadurch wird die Transformation (Weiterentwicklung) der Organisation für alle Mitarbeiter und Kunden erlebbar, greifbaren optimaler Weise mitgestaltbar (Betroffene zu Beteiligten machen).

 

Hallo Herr Schiffbauer, ich bin mir nicht ganz sicher, aber ich glaube, wir reden aneinander vorbei: . Sie meinen, glaube ich, das Change-Programm in Bezug auf die Änderung der Organisation, die diese überhaupt erst in die Lage versetzt digitale Transformationsprojekte durchzuführen. Dazu gehören u.a. die Änderungen die ich am Schluss meines Artikels andeute wie z.B. der Bedeutungsverlust von Quality Gates und Meilensteinen. Das kann natürlich nicht erst mit der Realisierung beginnen! . Ich meine aber das Change-Projekt in Bezug auf die technischen und prozessualen Änderungen die das Ergebnis eines digitalen Transformationsprojekts sind (also z.B. die Versicherungs-App für die ein neuer Freigabe-Prozess etabliert werden muss). Dieses Change-Projekt kann nicht vor Abschluss der Design-Phase beginnen, da erst bei Abschluss der Design-Phase die notwendigen Änderung absehbar sind.

 

Hallo Herr Eberspächer, ja, genau, ich spreche von der Transformation der Organisation hin zu einer Organisation, in der Status und Hierarchie, Alter oder Betriebszugehörigkeit keine Rolle mehr spielen. Dafür der Fokus auf Teamaerfolg (High Performance Teams) mit heterogenen und interdisziplinären Teams liegt. beteiligungsorientierte Zusammenarbeit auf Augenhöhe mit maximal möglicher Kundeneinbindung. Ich denke hier haben wir jetzt ein gemeinsames Verständnis, dass diese Rahmenbedingen oder die kulturelle digitales Transformation zuerst angegangen werden muss. Damit es dann mit den digitalen Projketen klappt. Vielleicht möchten Sie diese Rahmenbedingung zu Beginn des Artikels ergänzen. Meine Erfahrung und auch unsere kurze Diskussion hier zeigt mir, das es an dieser Stelle immer wieder zu Missverständnissen kommt bzw. das Setzen dieser Rahmenbedingungen vergessen oder für nicht so wichtig gehalten wird. Daher wäre Ihr Artikel dazu eine gute Gelegenheit die Leser für diesen Aspekt und dessen Wichtigkeit zu sensibilisieren. Vielen Dank für den interessanten Austausch hier mit Ihnen.

 

Hallo Herr Schiffbauer, . schön, dass wir uns einig sind ;^) Jede Art von Organisationsänderung sollte durch Change-Management begleitet werden. Das _garantiert_ zwar nicht den Erfolg, erhöht aber die Wahrscheinlichkeit (so wie ja auch die Anwendung von PM-Methodiken den Erfolg eines Projektes nicht garantieren, aber die Wahrscheinlichkeit des Projekterfolgs erhöhen). Das gilt m.E. aber allgemein für alle Orga-Änderungen und ist keine besondere Eigenschaft der digitalen Transformation. Da sich der Artikel nicht mit der Einführung des digitalen Transformationsprozesses in Organisationen beschäftigt, sondern mit der Ausgestaltung eines einzelnen DT-Projektes, halte ich ihn in der jetzigen Form für vollständig. . Ich würde mich aber sehr freuen bald einen Beitrag von Ihnen zu lesen, in dem Sie über geeignete flankierende Change-Management-Maßnahmen bei der Etablierung des digitalen Transformationsprozesses in Unternehmen berichten! Ich bin mir sicher, das Projektmagazin würde einen solchen Artikel mit Begeisterung publizieren. . >Zwinkersmiley<

 

Danke für die Anregung. Die nehme ich sehr gerne auf und werde mal nachhören, wie das Interesse an einem solchen Artikel beim Projekrmagazin aussieht. Danke für den aktiven Austausch hier und ein schönes Wochenende.

 

Hallo Herr Schiffbauer, hallo Herr Eberspächer, allein die über alle Erwartungen hinausgehende, intensive Diskussion zeigt ja, dass hier noch ein enormer Bedarf an Information und Diskussion besteht. Klar, gerne greifen wir das Thema "Organisationsentwicklung und Digitale Transformation" auf. @Herr Schiffbauer: Wenn Sie wollen, nehmen Sie doch einfach mit uns Kontakt auf unter redaktion@projektmagazin.de. Wir freuen uns darauf, von Ihnen zu hören! Beste Grüße Georg Angermeier

 

Klaus
Fuchs

Die Digitalisierung verändert unsere Welt, schnell und unwiderruflich. Der digitale Wandel darauf erfordert eine grundsätzliche Erneuerung – eine Transformation. Die Digitalisierung ist vorrangig kein IT-Problem. Es geht um den Wandel an sich, in ganzer Breite. Wer diesen Wandel nicht vollzieht, wird im Wettbewerb nicht bestehen. Und selbstverständlich wirkt sich dieser Wandel auch auf die Art und Weise aus, wie wir den Wandel bewerkstelligen wollen. Wir selbst als Kunden und unsere Wünsche im ständigen Wandel liefern die Problemstellungen, die von einem Tag auf den anderen Strategie und Geschäftsmodelle infrage stellen können und für die wir über Nacht passende Antworten finden müssen: zum Beispiel, wenn plötzlich nicht mehr Produkte entscheidend sind, denn die Kunden fragen nach neuen Dienstleistungen. So wird schnell klar, dass so die Prozesslandschaft jetzt auf dem Kopf steht. Prozesse entwickeln sich also nicht mehr aus der Entwicklung heraus, sondern von den Kunden her. Und oft ist der Kunde sogar in die Problemlösung miteinbezogen. Dieser Trend verlangt neues Denken, neue Methoden und „gewandelte“ Menschen in den Projektteams von morgen. Der klassische Projektleiter, die hier auf einen klassischen Projektauftrag wartet, wird lange warten.

 

Guest

Vielen Dank für den informativen Artikel. Viele Punkte werde ich aufgreifen und für mich weiter durchdenken.

 

Detlef
Amberg

ein sehr interessanter Artikel; aber hier kommt ein nicht zu verachtender Einwand und zwar: 'kein Wunder, dass Projekte (wie Berliner Flughafen, Bundesmarine im Schiffbau, Bundesluftwaffe im Flugzeugbau, Thyssen-Krupp mit dem Stahlwerk in Brasilien und jetzt auch noch Lidl mit der weltweiten SAP-Einführung) scheitern, bzw. geplante Termine und Kosten exorbitant überschritten werden, wenn es weder einen festen Projektumfang (Scope) noch geplante Fertigstellungstermine und Budgets geben soll; wie soll das Unternehmen denn das Produkt 'time to market' bringen, wie soll der Controller seine Budgetplanung machen, wenn das Projekt darüber entscheiden soll, wann es fertig ist und wieviel es kosten soll!! Welches Unternehmen (außer dem ööfentlichen Dienst (wo Termine und Geld keine Rolle spielen) und niemand verantwortlich gemacht wird)) kann sich denn so etwas leisten?? Thyssen -Krupp hat sein Stahlwerk in Brasilien (fast) verschenkt; Lidl hat 500 Millionen € verloren; tolles Management; super Projekte, ich kann nur gratulieren

 

Detlef
Amberg

so ein Schwachsinn, stellen Sie sich vor , Sie sich vor, Sie wollen ein Haus bauen und müssen natürlich einen Fertigstellungstermin und mit ihrem verfügbaren Budget planen!!; wenn Sie aber über unendliche Ressourcen (wie der öffentliche Dienst, in diesem Beispiel die Hansestadt Hamburg beim Bau der Elbphilharmonie verfügen, die von einem geplanten Budget von 77 Millionen auf ein Fertigstellungsbudget von ca. 900 Millionen gestiegen ist) verfügen, dann können Sie diese Projektart selbstverständlich implementieren. Solange ein Unternehmen aber auf die Finanzen schauen muss (und nur solche kenne ich) wird sich kein Unternehmer darauf einlassen, dass ein Projekt bestimmt, wann es fertiggestellt ist und wieviel Budget es verbraucht hat. Im Gegenteil, der Projektauftrag liegt noch nicht auf dem Tisch, da wird schon vom potenziellen Projektleiter erwartet, dass er eine Aussage zum Fertigstellungstermin und Budget hat; meistens wird sogar das Budget vorgegeben!! Mir kommt dieser Vorschlag 'kein Scope, keine Termin-und keine Budgetvorgabe' vor , wie Projektmanagement im Schlaraffenland. Sollte so ein Projekt gestoppt werden, bin ich gerne bereit es zu übernehmen und nach vereinbartem Termin- und Budget on time und in Budget erfolgreich fertigzustellen.

 

Profile picture for user matthias@eberspaecher.name
Matthias
Eberspächer
Dr.

Antwort auf von Detlef Amberg

Hallo Herr Amberg, vielen Dank für Ihr umfangreiches Feedback. Inhaltlich gebe ich Ihnen absolut Recht, allerdings ist keines der von Ihnen genannten Projekte ein Design-Projekt eines digitalen Transformations-Prozesses - und nur für diese spezielle Art von Projekten gelten die Empfehlungen! Stellen Sie sich vor, sie würden eine Vielzahl von Projekten der Realization-Phase starten ohne zuvor die Wirksamkeit ausreichend abgesichert zu haben; nur, um das Design-Projekt in Time & Budget abgeschlossen zu haben. Dann haben Sie eventuell genau die von Ihnen angesprochene Geldvernichtung für eine nicht mehrwertige Umsetzung (selbst wenn alle Realisierungsprojekte in Time & Budget abgeschlossen werden).

 

Guest

Ein klasse Artikel! Speziell Bild 4 bringt es aus meiner Sicht auf den Punkt und zeigt die Veränderung der Kompetenzprofile, wie ich sie auch in der Praxis erlebe.

 

Dieter
Bertsch

„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?

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.