Veröffentlicht am

Relatives Schätzen: Von T-Shirt Größen zu Fibonacci-Werten

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ößenStory Points
XS1
S2
M3
L5
XL8
XXL13
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.

Siehe dazu auch Planning Poker beim relativen Schätzen nutzen – analog oder auch online.

Veröffentlicht am

Wie kommt es zum Trend “Hybrides Projektmanagement”?

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.

Siehe dazu auch

Hybrides Projektmanagement: “Emergent Practice” und Bifurkationspunkte

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.

Veröffentlicht am

Mit Hilfe der Stacey-Matrix klassische und agile Vorgehensmodelle im Projektmanagement abgrenzen

Vgl. Komus (2018) und eigene Ergänzungen

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.

Zur Verbesserung bietet es sich an ein Analysetool zu verwenden, das mehrere Dimensionen berücksichtigt und auch die Möglichkeit des Hybriden Projektmanagements enthält. Siehe dazu Projektmanagement: Einfaches Tool zur Analyse des angemessenen Vorgehensmodells – Planbasiert, Hybrid, Agil.

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.

Veröffentlicht am

Projektmanagement: Klassisch-Agil in der Übersicht

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.

Veröffentlicht am

Bezugsrahmen für Agiles Projektmanagement

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.

Veröffentlicht am

Agiles Projektmanagement: Die Falle bei den Anforderungen

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).

Siehe dazu auch

Agiles Projektmanagement: Anforderungen auf verschiedenen Granularitätsebenen

Agiles Projektmanagement: Was zeichnet ein gutes Product Backlog aus, und wie kann man es steuern?

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.

Veröffentlicht am

Welche Merkmale haben Projekte, die nach dem Wasserfall-Modell durchgeführt werden können?

Beispiel eines Wasserfall-Modells in OpenProject

Wie wir aus dem Projektmanagement-Kontinuum wissen, gibt es eine Vielzahl von Möglichkeiten, Projekte durchzuführen. Weiterhin hat die PMI-Studie aus dem Jahr 2024 gezeigt, dass die meisten Projekte immer noch eher plangetrieben durchgeführt werden. Dieses Vorgehen wird of mit dem Wasserfall-Modell assoziiert, wobei der Begriff häufig negativ besetzt ist. In dem Beitrag Einige Anmerkungen zum “Wasserfall-Modell” auf Basis des Originalartikels von Royce (1970) hatte ich schon einmal versucht dazustellen, dass auch das Wasserfall-Modell unter bestimmten Bedingungen seine Berechtigung hat. Die folgende Übersicht zeigt, welche Merkmale Projekte haben, die nach dem Wasserfall-Modell durchgeführt werden

“Die bekanntesten Merkmale dieser Art von Projekten sind:
– ein klar definiertes Geschäftsziel
– ein präzises Verständnis des zu entwickelnden Systems
– ein präzises Verständnis der Domäne
– ein präzises Verständnis der Technologie, die eingesetzt werden soll
– starke Anweisungen von einem einzigen Business Owner oder Lenkungsausschuss
– ein strikter Ansatz, der von Anfang an in einem formalen Plan mit Budgets und Zeitrahmen definiert und von einem starken Projektmanagement gesteuert wird
– aus unterschiedlichen Experten bestehende Teams, die an den einzelnen Phasen arbeiten
– Ergebnisse der einzelnen Phasen, die als Input für die nächste Phase dienen, wobei Informationen über formale Dokumentation weitergegeben werden
– Quality Gates zwischen den einzelnen Phasen, bei denen nach formalen Managemententscheidungen vorgegangen wird
– Nachdem ein Quality Gate erfolgreich durchlaufen wurde, werden die resultierenden Anforderungen in Form von Spezifikationen „eingefroren“ und wenn nachfolgend Änderungen erforderlich sind, werden diese nach einem formalen Änderungsverfahren ausgeführt” (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.

Veröffentlicht am

Hybrides Projektmanagement: “Emergent Practice” und Bifurkationspunkte

Projektmanagement spannt von den Polen Agiles Projektmanagement und Planbasiertes Projektmanagement ein Projektmanagement-Kontinuum der Möglichkeiten auf. Dabei gibt es Bereiche, in denen das Planbasierte Projektmanagement besser passen, und andere, in denen das Agile Projektmanagement eine bessere Option darstellt.

Diese Studie PMI (2024) Global Survey: Hybrides Projektmanagement wird immer wichtiger hat gezeigt, dass es in der Praxis immer mehr Hybrides Projektmanagement gibt, das weniger dogmatisch, sondern eher pragmatisch ist. In der Zwischenzeit gibt es auch Vorschläge, welcher Kombinationen bei einem Hybriden Projektmanagement Vorgehensmodell geeignet sind.

Darüber hinaus gibt es in der Literatur aber auch Hinweise, dass Hybrides Projektmanagement “einfach entsteht” – also emergent ist.

“Diebold et al. konnten zeigen, dass einige Organisationen, die agiles Projektmanagement implementieren, den kulturellen Wandel (vgl. dazu auch Zasa et al.) und / oder den damit verbundenen Schulungsbedarf unterschätzten. Dies führte zu einer „emergent practice“ des hybriden Projektmanagements.(…) Im Sinne der emergent practice gibt es also Elemente („Relikte“) klassischen Projektmanagements, mit denen Teams sich konfrontiert sehen, die ansonsten nach einem agilen Modell zusammenarbeiten” (Albrecht und Romero Müller 2024, in: projektmanagementaktuell 4/2024).

In komplexen Systemen mit seinen vielfältigen Verbindungen entsteht etwas, das nicht so ohne weiteres auf die einzelnen Komponenten, Elemente des Projektmanagement-Systems zurückzuführen ist. Solche Phasenübergänge (bitte nicht mit den Projektmanagementphasen verwechseln!) werden Bifurkationspunkte genannt. Möglicherweise genügt es, das Verhalten der wenigen instabilen Systemelemente zu erkennen, um das gesamte Projektmanagement-System zu steuern. Siehe dazu auch

Kernkompetenzen als Emergenzphänomene

Komplexität bzw. komplex – in Abgrenzung zu einfach und kompliziert

Alle reden über Komplexität, doch wer kennt schon Bifurkationspunkte?

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.

Veröffentlicht am

Projektmanagement bei der Continental AG – klassisch, agil, hybrid

Top view of multiracial young creative people in modern office. Group of young business people are working together with laptop, tablet, smart phone, notebook. Successful hipster team in coworking.

Die Continental AG mit Sitz in Hannover ist einer der großen Automobilzulieferer. Aufgrund seiner Historie kann man davon ausgehen, dass das Klassische Projektmanagement dominiert und in der Zwischenzeit von agilen Vorgehensmodellen teilweise ersetzt, oder ergänzt wurde. Genau das bestätigt auch Jean Marc Bonn, Project Management Officer bei der Continental AG in Hannover:

“Wir nutzen zumeist das klassische Wasserfallmodell und kombinieren es mit agilen Elementen. Die Continental hat einen eigenen Standard, der den Vorgehensweisen der GPM ähnelt. In der Entwicklung und im IT-Umfeld wird oft Scrum verwendet. (…) Klassisches Projektmanagement wird aufgrund der hohen Dynamik im Umfeld zunehmend mit agilen Elementen durchmischt und ergänzt” (Jean Marc Bonn im Interview mit Martina Peuser in projektmanagmentaktuell 05/2024).

Interessant dabei ist, dass man sich beim Klassischen Projektmanagement wohl am IPMA-Standard orientiert, der ja von der GPM vertreten wird. Als international tätiges Unternehmen hätte ich vermutet, dass auch PMI und/oder Prince2 eine wichtige Rolle spielen.

Darüber hinaus ist zu erkennen, dass das Unternehmen auch einen eigenen “Standard” entwickelt hat, der dann wohl besser zur Unternehmensstruktur passt. Insgesamt kann die Vorgehensweise bei der Continental AG als eigenes Hybrides Vorgehensmodell charakterisiert werden.

Immer mehr Organisationen erkennen, dass es in einem Projektmanagement-Kontinuum sehr viele Möglichkeiten gibt, das geeignete Projektmanagement-Vorgehensmodell auszuwählen und im Projektverlauf emergent anzupassen.

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.

Veröffentlicht am

Agile Softwareentwicklung ist nicht Agiles Projektmanagement

Dong et al. (2024), nach Nerur et al. (2005)

In der Diskussion um Projektmanagement ist in der Zwischenzeit der Pragmatismus eingekehrt. Viele Organisationen stellen fest, dass für ihre verschiedenen Vorhaben traditionelles Projektmanagement und agile Vorgehensmodelle sinnvoll miteinander kombiniert werden müssen. In dieser Diskussion wird allerdings oft die Agile Softwareentwicklung und Agiles Projektmanagement gleichgesetzt – dem ist allerdings nicht so.

In der Abbildung sind die Unterschiede und Gemeinsamkeiten des traditionellen Projektmanagements, Agile Software Development und Agiles Projektmanagement anhand wichtiger Kriterien gegenübergestellt.

Es wird deutlich, dass Agile Softwareentwicklung nicht Agiles Projektmanagement ist.

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.