In den letzten Jahren habe ich schon viele Beiträge zum Hybriden Projektmanagement geschrieben. In der Zwischenzeit nehmen auch die Diskussionen um Normen, Standards und Vorgehensmodelle diese Entwicklung auf. Im Vorfeld des IPMA World Congress (17.-19.09.2025 in Berlin) ist zum Beispiel folgendes zu Trendthemen zu lesen:
“Die zunehmende Komplexität von Projekten und unsichere Rahmenbedingungen machen flexible Lösungen notwendig. Hybride Modelle erlauben schnelle Reaktionen auf Veränderungen, ohne die organisatorische Stabilität zu gefährden. Auch große Unternehmen wie IBM und Microsoft berichten von positiven Erfahrungen: Effizientere Projektabläufe und zufriedenere Teams nach Einführung hybrider Ansätze. Hybrides Projektmanagement entwickelt sich damit vom Trend zum neuen Standard. Es kombiniert Planungsdisziplin mit Agilität – und macht Projekte robuster gegenüber externen Einflüssen. Ein klarer Wettbewerbsvorteil” (Wieschowski 2025, in projektmanagementaktuell 3/2025).
Dass Hybrides Projektmanagement der neue Standard sein soll ist zwar gut und richtig, doch gibt es noch gar keinen Standard zum Hybriden Projektmanagement.
Eigene Darstellung – Earned Value Analyse – Beispiel für Story Points (Klein 2021:54-55) / Ausschnitt
Wenn es um das Projektcontrolling geht, stellt sich natürlich immer auch die Frage: Von welchem Vorgehensmodell gehen wir aus? Ist es ein eher Plangetriebenes Projektmanagement, so kommen die üblichen Kennzahlen infrage, die beispielsweise aus einer Earned Value Analyse (EVA) entnommen werden können.
Gehen wir von einem Agilen Projektmanagement aus, so wird oft behauptet, dass die klassischen Controlling-Ansätze hier nicht anwendbar sind . Es wird von Objective Key Results (OKR) oder anderen (neuen?) Ansätzen gesprochen. Siehe dazu auch Veränderung des Controllings in einer VUCA-Welt. Das ist alles durchaus einleuchtend, doch gibt es eine Ausnahme.
Gehen wir einmal von der oben angesprochenen Earned Value Analyse aus, so stellt sich die Frage, ob die EVA nicht auch im Agilen Projektmanagement eingesetzt werden kann. Und siehe da: Es gib durchaus Autoren, die diese Frage in ihren Veröffentlichungen bewusst bejahen und auch begründen.
Klein (2021) hat anhand eines Zahlen-Beispiels ausführlich dargestellt, wie die Earned Value Analyse im Scrum Framework genutzt werden kann. Ich gehe hier nicht auf die gesamte Berechnung ein, doch zeigt schon der Ausschnitt in der Abbildung, die Vorgehensweise für die Sprints 1-5.
Wenn es also möglich ist, die Earned Value Analyse (EVA) im Plangetriebenen Projektmanagement und im Agilen Projektmanagement (Scrum Framework) zu nutze, so kann die EVA auch im Hybriden Projektmanagement eine wertvolle Hilfe darstellen.
Die Earned Value Analyse (EVA) stellt sich also als integrierendes Element des Projektcontrollings in verschiedenen Vorgehensmodellen dar.
Paralleler Durchlauf der einzelnen Vorgehensweisen in der software (hellblau), der Elektronik (grün) und der Mechanik (dunkelblau) mit geforderten Synchronisationspunkten (Timinger/Sticherling 2016)
In der Mechatronik geht es um Mechanik und Elektronik. Hinzu kommen heute fast immer auch Softwareelemente. Jeder einzelne Bereich ist schon schwierig genug, doch ist es noch herausfordernder, alle drei Bereiche aufeinander abzustimmen.
In der Abbildung sind die drei Bereiche mit ihren Entwicklungsschritten zu erkennen (farbliche Unterscheidung). Hinzu kommen jetzt noch geforderte Synchronisationspunkte, an denen alles zu einem bestimmten Zeitpunkt aufeinander abgestimmt wird. Dazu gehört auch, dass es von einem Synchronisationspunkt aus nicht weiter, sondern noch einmal zurück geht.
In einem eher plangetriebenen Projektmanagement ist es nicht einfach, alles zu koordinieren, da alle drei Stränge im zeitlichen Ablauf sehr unterschiedlich sein können.
Möglicherweise ist es bei einen größeren Dynamik (Komplexität) im Innovationsprozess besser, alles auf ein agiles, bzw. hybrides Vorgehensmodell umzustellen: Feature 1 > Feature 2 > Feature 3 etc. Siehe dazu auch Waterfall-Agile: Unterschiedliches Erarbeiten von Features.
Zielgruppe für Wolpers, S. (2020): The Remote Agile Guide sind Scrum Master, Product Owner und Agile Coaches, die mit einem oder mehreren verteilten Team(s) zusammenarbeiten. Dabei wird der Download als “free” bezeichnet, obwohl man sich einschreiben muss – “Subscribe Now”.- und somit mit seinen Daten bezahlt. Ich weiß durchaus, dass diese Vorgehensweise üblich ist, dennoch mag ich es nicht.
Insgesamt bietet der Guide eine gute Basis, sich über die verteilte digitale Zusammenarbeit Gedanken zu machen, und konkrete Möglichkeit für die eigene Vorgehensweise abzuleiten. Der Guide, auf den ich mich beziehe, stammt aus dem Jahr 2020. Dazu möchte ich noch einige Anmerkungen machen:
Zunächst wird mir der technische Aspekt der Zusammenarbeit zu stark betont (MS Teams, Zoom, Trello, Jira, etc.). Die Neurowissenschaften haben dazu beispielsweise bei der Nutzung von Zoom in der Zwischenzeit wichtige Hinweise gegeben: „Zoom scheint im Vergleich zu persönlichen Gesprächen ein dürftiges soziales Kommunikationssystem zu sein.“ Sieh Persönliche Gespräche und Zoom im Vergleich: Das sagt die Neurowissenschaft dazu. Weiterhin erwähnt auch schon das Agile Manifest aus dem Jahr 2001, dass der persönliche Austausch bei komplexen Problemlösungsprozesse wichtig ist, da es dabei um die wichtige implizite Dimension des Wissens geht. Diese ist mit Technologie nur bedingt zu erschließen.
Weiterhin werden in dem Guide zu wenige Open Source Alternativen genannt, die die remote Arbeit in verteilten Teams unterstützen können. Gerade wenn es um die heute wichtige Digitale Souveränität geht, ist das wichtig. Siehe dazu beispielhaft Souveränitätsscore: Zoom und BigBlueButton im Vergleich.
Nicht zuletzt geht es heute auch darum, in verteilten Teams im agilen Prozess der Zusammenarbeit Künstliche Intelligenz zu nutzen. Aus meiner Sicht ist auch hier die Nutzung von Open Source AI zeitgemäß.
Diese Anmerkungen sind als Ergänzungen zu verstehen. Möglicherweise ergibt sich daraus ja noch ein weiterer, aktualisierter Guide.
Im Projektmanagement wird an vielen Stellen geschätzt. Beim Plangetriebenen Projektmanagement wird absolut geschätzt, beispielsweise in Tagen (Dauer) oder auch in Personentagen (Aufwand). Beim Agilen Projektmanagement geht es darum, relativ zu schätzen. Es geht immer um den Bezug auf etwas.
Anforderungen werden hier oft als User Story formuliert, dabei wird oft bei der Schätzung des Aufwands mit T-Shirt Größen gearbeitet. Dazu wird eine Referenz benötigt. Nehmen wir einmal an, die User Story mit der ID=9 wird mit einer T-Shirt Größe “S”, geschätzt, dann werden alle anderen User Stories relativ dazu geschätzt.
Manche fragen an dieser Stelle, warum man nicht gleich Zahlen, z.B. die Fibonacci-Werte, verwendet. Dazu habe ich folgende Erläuterung gefunden:
“Wir verzichten darauf, die Fibonacci-Werte von Beginn an zu nutzen, weil wir möchten, dass das Team sich komplett vom Denken in Zahlen löst. Zahlen werden unbewusst immer wieder miteinander oder mit Tagen oder Stunden verglichen. Wir möchten erreichen, dass sich das Team auf »größer, gleich, kleiner« konzentriert und die Stories nur relativ zueinander schätzt” (Röpstorff/Wiedmann 2016).
Dennoch wird es irgendwann dazu kommen, dass man sich von den T-Shirt Größen löst und Zahlen nutzen möchte. Dazu werden für User Stories Zahlen aus der angepassten Fibonacci-Reihe genutzt, und als Story Points bezeichnet. Dabei kann folgende Gegenüberstellung nützlich sein:
T-Shirt Größen
Story Points
XS
1
S
2
M
3
L
5
XL
8
XXL
13
Quelle: Röpstorff/Wiedmann 2016
User Stories mit Story Points größer als 13 sollten noch einmal analysiert werden, denn es könnte sein, dass der Aufwand für einen Sprint zu groß ist, und es sich somit um ein Epic handelt.
Wie die HELENA-Studie und die PMI-Studie gezeigt haben, nutzen immer mehr Unternehmen/Organisationen ein hybrides Vorgehen im Projektmanagement. Es stellt sich natürlich die Frage, wie es dazu kommen konnte. Eine Antwort dazu habe ich in einem Artikel gefunden:
“Jedes Unternehmen ist eine Art Ökosystem. In diesem Ökosystem findet ja nicht nur beispielsweise die Entwicklung von Hardware und Software statt. Da gibt es auch andere Bereiche wie Sales, Rechnungswesen oder Personalmanagement. Dort herrschen ganz klassische Geschäftsprozesse vor. Zu diesen klassischen Prozessen müssen Projekte eine Schnittstelle anbieten. Aus Sicht vieler Unternehmen liefern agile Methoden diese Schnittstellen nicht” (Kuhrmann, M. (2019): Reines agiles Vorgehen kein „Allheilmittel“, in projektmanagementaktuell 3/2019).
Daran schließt sich natürlich die Frage an, wie Unternehmen das geeignete Vorgehen für ein Projekt festlegen. Wird das hybride Vorgehensmodell nur ein Mal festgelegt, und/oder im Projektverlauf angepasst?
“Vielleicht wird die komplette Vorgehensweise nicht von Projekt zu Projekt festgelegt. Im Allgemeinen sammeln Unternehmen Erfahrungen mit ihrem Projektmanagement. Es kommt zu bestimmten Konsolidierungen im Methodenapparat, also zu Mustern, die für alle Projekte gelten. Doch innerhalb dieses konsolidierten Methodenapparats kann dann für jedes Projekt die Vorgehensweise neu zusammengestellt werden” (ebd.).
Aus der täglichen Arbeit mit und in Projekten ergeben sich also Rahmenbedingungen, die zu einer Konsolidierung bei der Methodenvielfalt führen, und damit ein Muster erkennen lassen. Dieses Muster wiederum zeigt auf, welche Vorgehensmodelle kombiniert werden sollten, um das Projekte – oder die Projekte – erfolgreich umsetzen zu können.
Es wird in Zukunft immer mehr darauf ankommen, Hybrides Projektmanagement in diesem Sinne zu professionalisieren.
Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen, Projektmanager/in (IHK) und Projektmanager/in Agil (IHK), die wir an verschiedenen Standorten anbieten. Weitere Informationen zu den Lehrgängen und zu Terminen finden Sie auf unserer Lernplattform.
Wenn es darum geht, Klassische Vorgehensmodelle (Plangetriebene Vorgehensmodelle) und Agile Vorgehensmodelle abzugrenzen, wird oftmals die Stacey-Matrix herangezogen. – obwohl es mit dem Cynefin-Ansatz, dem Vorschlag von Boehm & Turner usw. auch andere Möglichkeiten gibt.
In der Stacey-Matrix werden auf der Y-Achse Anforderungen an das Projekt von “weitreichend klar” bis “geringe Klarheit” positioniert. Hier geht es somit um das WAS. Auf der X-Achse geht es um Technik/Methode, die für das Projekt “im Griff” oder auch “unklar/unsicher” sein können. Hier geht es um das WIE (Siehe Abbildung).
Es ergeben sich daraus drei Bereiche: Simpel, Kompliziert und Komplex. Weiterhin können über die Diagonale die geeigneten Vorgehensmodelle abgeleitet werden. Simpel bedeutet hier, dass die Anforderung als Routinetätigkeit angesehen werden kann. KVP ist die Abkürzung für “Kontinuierlichen Verbesserungsprozess” oder auch Kaizen. Das bedeutet, um die Anforderungen zu erfüllen, muss der Routineprozess verbessert werden. Reicht das nicht mehr aus, so kommen wir in den Bereich des (Klassischen) Projektmanagements, zu dem es Normen und Standards gibt, die sich in vielen Branchen bewährt haben.
Werden die Anforderungen und auch Technik/Methode immer unklarer, kommen wir von dem komplizierten Bereich immer stärker in einen komplexen Bereich, in dem mehr Selbstorganisation gefordert ist, um das Projekt zum Erfolg zu führen. Mit Kanban, Scrum und Design Thinking sind hier nur drei von vielen Vorgehensmodellen genannt, die dem Agilen Projektmanagement zugerechnet werden.
Der Vorteil der Stacey-Matrix liegt darin, dass sie recht einfach umsetzbar ist und somit einen schnellen und guten Einstieg dafür bietet herauszufinden, welches Vorgehensmodell für ein Projekt geeignet erscheint.
Nachteile der Stacey-Matrix sind: (1) Es sind nur zwei Dimensionen zu bewerten – bei einem komplexen Projekt möglicherweise zu wenig, (2) Das Hybride Projektmanagement wird hier nur indirekt thematisiert. Man könnte den Bereich zwischen “Kompliziert” und “Komplex” dafür nehmen, was allerdings recht ungenau wäre.
Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen, Projektmanager/in (IHK) und Projektmanager/in Agil (IHK), die wir an verschiedenen Standorten anbieten. Weitere Informationen zu den Lehrgängen und zu Terminen finden Sie auf unserer Lernplattform.
Wenn es um das Klassische (Plangetriebene )Projektmanagement, und um das Agile Projektmanagement geht, werden oftmals einzelne Kriterien genannt, die beide Vorgehensmodelle unterscheiden. In der Diskussion ist es oftmals hilfreich, verschiedene Kriterien für das jeweilige Vorgehensmodell zu beantworten und darzustellen.
Die folgende Tabelle zeigt übersichtlich, wie sich die genannten Vorgehensmodelle bei einzelnen Kriterien unterscheiden. Wenn Sie wollen, können Sie die Antworten als Pole zwischen zwei Zahlenwerten, z.B. 1 – 10, sehen, und eine eigene kleine Exceldatei für die Analyse eines Projekts erstellen.
Quelle: Müller/Hüsselmann (2017), in projektmanagementaktuell 2/2017
Möglicherweise werden sie dann erkennen, dass ihr Projekt keine eindeutige Zuordnung Richtung einer “10” oder einer “1” erlaubt. Das wiederum deutet darauf hin, dass sich bei dem Projekt eher ein Hybrides Vorgehensmodell (Hybrides Projektmanagement) anbietet.
Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen Projektmanager/in (IHK) und Projektmanager/in AGIL (IHK). Informationen dazu, und zu aktuellen Terminen, finden Sie auf unserer Lernplattform.
Eigene Darstellung. Tolnai, E.; Auth, G. (2016:38) Evaluation von Software-Werkzeugen für agiles Projektmanagement. In: projektmanagementaktuell: 2.2016, S. 36-42
Die Merkmale des Agilen Projektmanagements können recht gut in einem Bezugsrahmen dargestellt werden (Siehe Abbildung). Neben den Kategorien Ziele, Prinzipien, Prozess und Projekt, geht es dabei auch um die Regelwerke und Informationsträger.
“Regelwerke beschreiben Details für Vorgehen in und Management von agilen Projekten, denen als gemeinsames Merkmal ein iterativer Prozess zugrunde liegt. Diese Regelwerke wollen mit wenigen und einfach verständlichen Regeln auskommen, weshalb sie auch als leichtgewichtig bezeichnet werden. Zu den bekanntesten Vertretern zählen Scrum, Kanban, die Crystal-Familie und Dynamic Systems Development Method (DSDM), die ihren Ursprung wiederum durchweg in der Softwareentwicklung haben. Die einzelnen Elemente des Bezugsrahmens orientieren sich aufgrund des hohen Verbreitungsgrades an Scrum, stellen aber eine Verallgemeinerung dar. Der Begriff Informationsträger geht auf Cockburn zurück und wird als Überbegriff von Darstellungsformen für Projektinformationen verwendet, die inhaltlich aktuell und für alle Projektmitarbeiter gut sichtbar sind und somit für Transparenz im Projekt sorgen” (Tolnai/Auth 2016).
Dieser Bezugsrahmen kann auch als Orientierung zur Auswahl von geeigneter Software genutzt werden.
Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen Projektmanager/in (IHK) und Projektmanager/in AGIL (IHK). Informationen dazu, und zu aktuellen Terminen, finden Sie auf unserer Lernplattform.
Gerade im agilen Umfeld geht es oft um den Begriff “Value”. Beim Agilen Projektmanagement, beispielsweise nach Scrum, werden die Anforderungen oft als User Stories aus der Perspektive fiktiver Charaktere (Persona) formuliert. Dabei kann es vorkommen, dass dabei nicht nur User, sondern auch weitere Stakeholder beachtet werden sollen. Das kann wiederum dazu führen, dass das Projekt mehr in Richtung des Wertes für interne Stakeholder “abdriftet”.
“Bei der agilen Herangehensweise an die Softwareentwicklung liegt das Hauptaugenmerk auf der Werthaltigkeit, welche die Lösung den Benutzern bieten soll („User Story“). Daher wird der Benutzer eines interaktiven Systems als primärer Stakeholder betrachtet. Dennoch besteht, vor allem in großen Organisationen, das Risiko, dass agile Teams oder Product Owner nicht mit den echten Nutzern in Kontakt sind. Die Personas werden hier möglicherweise von jemandem erdacht, der nur vorgibt, die Benutzer zu kennen! In einem solchen Kontext sind die Stakeholder der Organisation(Manager, Fachbereiche, Rechtsabteilungen, Marketing usw.) wesentlich präsenter und dominanter als der externe Endbenutzer. Seien Sie sich über diese Falle im Klaren: Bestehen Sie darauf, dass ein direkter Zugang zu Endbenutzern besteht, um eine angemessene Nutzerforschung durchführen und nach der Sprint-Lieferung direktes Feedback einholen zu können. Nur so können Sie Ihre Benutzer und deren Bedürfnisse wirklich kennenlernen” (Brand et al. 2024).
Solche Zusammenhänge thematisieren wir auch in den von uns entwickelten Blended Learning Lehrgängen Projektmanager/in (IHK) und Projektmanager/in AGIL (IHK). Informationen dazu, und zu aktuellen Terminen, finden Sie auf unserer Lernplattform.
Translate »
Diese Website benutzt Cookies. Wenn du die Website weiter nutzt, gehen wir von deinem Einverständnis aus.
