Die Zukunft bei der Anwendung von Projektmanagement-Vorgehensmodellen ist hybrid?

Die Zukunft bei der Anwendung von Projektmanagement-Vorgehensmodellen ist hybrid?
Die „GULP – Knowledge Base“ hat eine „Umfrage mit 223 Freelancern und Projektanbietern vornehmlich aus der IT und dem Engineering Project Management“ durchgeführt. Als Ergebnis lässt sich erkennen, dass künftig durch weitere Zunahme von Unsicherheit und Risiken in der Projektarbeit, agile Projektarbeit oder agile Teilprojekte zunehmen werden. Dies begründet sich durch „Angriffe“ der Wettbewerber aus dem dynamischen Marktumfeld (Wohland, 2012) und dem intensiveren Zwang zur vernetzten Kooperation (Hoffmann, Rollwagen, Schneider, 2010).

Abbildung 1: Phasenmodelle

Abbildung 1: Phasenmodelle

Bei genauerer Betrachtung wird agile Projektarbeit heute vorwiegend dort eingesetzt, wo sich der Projektgegenstand zu Projektbeginn noch nicht genau beschreiben lässt. Weiterhin wird auch agil gearbeitet, wo sich das systemische Umfeld so dynamisch entwickelt, dass eine ständige Anpassung an das Systemumfeld erforderlich ist.

Dies betrifft dann sehr häufig die Hardware, Software, Betriebssystemwelten, Technologiegenerationen und -sprünge und sich ständig erweiternde Funktionalitätsoptionen bei Endgeräten (z. B. Smartpads). Hier kann oft für den Zeitpunkt des Markteintritts bei Projektbeginn und über den Projektverlauf noch nicht genau der Projektgegenstand festgelegt werden. Fast immer können die Entwickler zu Projektbeginn der Programmierung z. B. einer App nicht genau wissen, welche Betriebssystemversion von Apple iOS, Android oder Windows zum Markteintritt und über den Produktlebenszyklus der App relevant sein werden. Gleiches gilt für die weltweit über den App-Lifecycle dann verfügbaren Smartpad-Endgeräte-Generationen. Weiterhin sollte sich der Projektgegenstand in mehrere gleichzeitig agil bearbeitbare Module zerlegen lassen, welche hinterher wieder in der Vernetzung den Gesamtprojektgegenstand ergeben werden.

Somit ist es für derartige Projektgegenstände erfolgreicher, sich durch agile und flexible Vorgehensmodelle und Modularisierung diesem dynamisch verändernden Umfeld anzupassen. Ja besser noch, sich mit dem Umfeld evolutionär bis zur Markteinführung zu entwickeln und auch über den Produktlebenszyklus hinweg sich der Hard- und Software weiter anzupassen.

Abbildung 2: Agiles Projektmanagement

Abbildung 2: Agiles Projektmanagement

Für viele Projektgegenstände, wird es jedoch auch künftig erfolgreicher sein, nach den oft als „klassisch“ bezeichneten Vorgehensmodellen (Schmehr, Patzak, Eysel, 2009) das Projekt zu strukturieren und abzuwickeln. Das gilt besonders für solche, die nicht einem solchen dynamischen Umfeld ausgesetzt sind. Hier kann zu Projektbeginn schon weitgehend erschöpfend der Projektgegenstand beschrieben werden. Und dann das Projektteam nach der „klassisch“ Vorgehensweise in einem annähernd linearkausalem Vorgehen das Projekt umsetzen.

So zum Beispiel werden Sie eine Tunnelbaustelle, bei der Sie zu Baubeginn eine klare Trassenführung und durch Baugrunderkundung einen relativ guten Erkenntnisstand über die zu erwartenden Baugrund- und Grundwasserverhältnisse besitzen, nicht als Gesamtprojekt agil abwickeln. Denn hier müssen Sie erst die Vortriebstechnologie festlegen, dann das Tunnelportal herstellen und dann Abschlag für Abschlag den Tunnel als Linienbaustelle ins Gebirge vorantreiben.
Es kann jedoch in Teilen des Projektes, wenn z. B. ein bisher nicht erkundetes und somit für das Projektteam bisher unbekanntes Baugrund- oder Grundwasserereignis erkennbar wird, dann die Problemlösung und punktuelle Umsetzung agil umzusetzen sein. Weiterhin könnte z. B. auch die Entwicklung der Tunnelleittechnik zur späteren Verkehrssteuerung, welche Hard- und Softwareanteile besitzt, agil abgewickelt werden.

Es gibt jedoch auch Projekte, wo nur Teile des Projektgegenstandes einer hohen Umfelddynamik ausgesetzt sind. So z. B. in der Automobilindustrie das Infotainmentsystem mit Smartpadanbindung und Local App-Lösungen. Hier wird dann der „relativ stabile“ Anteil des Projektgegenstandes (z. B. Blech und Kunststoffteile im Interieur und Exterieur und der Powertrain) nach den klassischen Projektmanagement-Vorgehensmodellen abgewickelt. Dies erfolgt weitestgehend Fahrzeugproduktentstehungsprozess des Automobilherstellers. Die jedoch äußerer Marktdynamik unterlegenen Anteile, wie Steuergeräte mit Hard- und Softwareständen und das Infotainmentsystem, werden agil entwickelt.

Abbildung 3: Hybrides Phasenmodell (Prinzipskizze)

Abbildung 3: Hybrides Phasenmodell (Prinzipskizze)

Hier prallen dann jedoch unterschiedliche Kulturen der Projektabwicklung zusammen. Dies bedeutet für das Gesamtprojektteam ein gewisses Gefahr und Konfliktpotenzial, welches dann vom Projektleiter ausbalanciert werden muss. Denn einige agil agierende Teilprojektteams würden ja in kleinen „autonom projektorganisierten Teams“ immer „sprintorientiert“ nur so viel an „Projektteilen“ annehmen, wie sie sich zutrauen umsetzen zu können. Die anderen Projektbeteiligten müssten jedoch matrixorganisiert in mehreren parallelen Projekten arbeiten. Weiterhin müssen sie versuchen, die fast immer sehr ehrgeizigen Kosten- und Terminziele eines anspruchsvollen und immer komplexer werdenden Projektgegenstandes umzusetzen. Dies bedeutet für die matrixorganisierten Projektmitarbeiter einen sehr großen Komplexitäts-, Termin- und Kostenstress aus vielen parallelen Projekten. Diese „Matrixkollegen“ sind gezwungen, sich nicht nur auf einen Sprint zu konzentrieren, sondern den gesamten Projektgegenstand vom Anfang bis zum Ende und über den Lebenszyklus im Blick zu haben. Dabei sind dann noch die Konsequenzen ihrer Projektarbeit zur Erreichung eines Gesamtprojektgegenstandes abzuwägen und mit den anderen Projektbeteiligten abzustimmen.

Dies wird zu einem Konflikt zwischen den agil und klassisch projektorganisierten Projektteamanteilen führen. Hier ist vom Projektleiter durch geeignete Interventionen und Teambildung Vertrauen aufzubauen, Missverständnisse abzubauen und Verletzungen zu heilen. Da die Unternehmens- und Projektteamkultur ca. 30% Einfluss auf den wirtschaftlichen Erfolg haben (Hauser, Schubert, Aicher, 2008), liegt hier fast der erfolgskritischste Teil der Projektmanagement-aAufgabe für den Projektleiter. Somit lassen sich im Multiprojektmanagement die künftig herausfordernde Kompetenz zur Leitung und Abwicklung von hybriden Projektteams (agile und matrixorganisierte) als weites Kompetenzelement im Projektmanagement schon am Horizont erkennen.

Abbildung 4: Konfliktbereich bei agil- und matrixorganisierten Hybridprojekten

Abbildung 4: Konfliktbereich bei agil- und matrixorganisierten Hybridprojekten

Stellt jetzt jedoch jemand die Frage: „Warum machen wir nicht alle Projekte agil?“ muss er erkennen, dass er dafür nicht immer die Ressourcen bekommen wird. Dies begründet sich in der demografisch begrenzten Anzahl von hoch spezialisierten und interdisziplinären Fachkräften und Experten. Deshalb werden hybride Projektteams künftig mehr und mehr auf dem Vormarsch sein (Pilgram, 2007).

Zusammenfassung – Management Summary

  • Es ist vom Projektgegenstand und dem Umgebungssystem des Projektgegenstandes über den Zeitraum der Produktentstehung und dem Lebenszyklus abhängig, ob rein agile Projektarbeit, eine Mischung aus agil und klassisch (hybrid) oder klassische Projektarbeit am erfolgversprechendsten sind (Schnalzer, Gahle, Bienzeisler, Theis, Winter, 2013)
  • Hat der Projektgegenstand Anteile, die sich geeigneter Weise in agil und klassisch abzuwickelnde Anteile trennen lassen, ist ein hybrides Vorgehensmodell erfolgversprechender.
  • Die Kompetenz, die Konfliktpotenziale zwischen klassisch und agil abgewickelten Projektanteilen zu erkennen wird zu einer Schlüsselkompetenz. Hier muss der Projektleiter durch Teambildung Vertrauen aufzubauen, Missverständnisse abzubauen und Verletzungen zu heilen. Hierfür ist eine gezielte Kompetenzentwicklung der Projektleiters zu empfehlen.


Literaturquellen


Ähnliche Beiträge im GPM BLOG:

Schlagwörter: , , , , ,

Kommentare

  1. avatar Wolfram Ott

    Lieber Raimo,

    Danke für Deine gelungene Zusammenfassung die ich voll unterstütze. Du hast das sehr gut ausdifferenziert.

    Gerne darf ich den Aspekt der Vertragsgrundlage ergänzen.
    Optimierungen in der Umsetzung zwischen AG + AN zur Verbesserung der Effektivität und Effizienz werden durch agile Anteile sicherlich konkret erreicht.
    Die Vertragsarten mit Ihren Chancen und Risiken bilden immer den Rahmen. Definiert Ziele, geäußerte Erwartungen und erhofften Nutzen bestimmen das Handeln.
    Dahinter würde ich gerne die Gliederung nach den Projektarten (Investition, Forschung, Entwicklung, Organisation) einbinden. Warum? Die Projektarten stellen unterschiedliche Erwartungen an das Projektergebnis.
    Um alle Interessensgruppen verschiedener Wirtschaftszweige noch besser erreichen zu können würde ich mir persönlich wünschen das Ganze unter dem Arbeits-Titel „Zusammenarbeitsmodelle in spezifischen Aufgabenstellungen“ zu beschreiben. Der Chancen-Risikobasierende Ansatz der ISO 9000:2015 fordert dies ebenso.
    ist das nicht der absolute Vorteil der ICB 3.0/4.0, die eine individuelle Herangehensweise unterstützt.
    Das sollten wir im Design der Projekte, Programme, bezogen auf das Vorgehen, zukünftig berücksichtigen.
    Bedeutet konkret, dass wir in dem Projektstart-Prozess auf alle Fälle immer mehr investieren sollten. Dafür müssen wir in den Köpfen der Verantwortlichen kämpfen.
    Gerne begleite ich Dich zu diesem Thema!

Leave a Reply

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert. *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>