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

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.

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.

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.