Agile Organisation | Page 5 of 78

17. Februar 202517. Februar 2025

Steckbrief zum Wasserfallmodell: Vorteile und Nachteile

In der Vergangenheit wurden hauptsächlich die Nachteile des klassischen, plangetriebenen Projektmanagements herausgestellt. Als Paradebeispiel (Negativ-Beispiel) wurde oft das Wasserfallmodell herangezogen, das nach der Meinung vieler sogenannter Experten nicht mehr zeitgemäß sei. Siehe dazu auch OpenProject: Anmerkungen zum Kritischen Weg und zu Meilensteinen und Einige Anmerkungen zum “Wasserfall-Modell” auf Basis des Originalartikels von Royce (1970.

Alles sollte (musste?) in Zukunft agil durchgeführt werden. Prominente Vorgehensmodelle waren und sind hier Scrum (Framework), Kanban, DevOps etc.

Wie bei allen neuen Ansätzen entwickelte sich daraus auch ein lohnenswertes Geschäftsmodell, von dem immer mehr Beteiligte profitieren wollten, und auch noch profitieren wollen. Nach vielen Jahren der praktischen Umsetzung stellte sich allerdings heraus, dass viele Organisationen agile Vorgehensmodelle nicht, oder nur in abgewandelter Form umsetzen, bzw. umsetzen können. Siehe dazu Hybrides Projektmanagement hat sich in vielen Unternehmen durchgesetzt (HELENA-Studie) und PMI (2024) Global Survey: Hybrides Projektmanagement wird immer wichtiger.

Es ist an der Zeit, sich die Vorteile und Nachteile von Vorgehensmodellen genauer anzusehen, um das jeweils geeignete Vorgehensmodell – bzw. deren Kombinationen – bestimmen zu können. Siehe dazu DAS Projektmanagement-Kontinuum in der Übersicht.

In der Abbildung sind die Vorteile und Nachteile für das Wasserfall-Modell dargestellt. Ja, das Modell ist ineffizient bei wenig planbaren Projektgegenständen und sich ändernden Anforderungen. Doch es gibt auch Vorteile, wie die klaren Strukturen, die manches vereinfachen. Schauen Sie sich die Übersicht an und bilden Sie sich ihre eigene Meinung dazu.

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.

14. Februar 202514. Februar 2025

Von den Komplexitätsdimensionen des Projektmanagements zum Kompetenzmanagement

Der Begriff Komplexität ist im Projektmanagement sehr wichtig. Projektmanagement-Standards wie IPMA, PMI oder auch Prince2 bieten beispielsweise an, die Komplexität eines Projektes, oder vieler Projekte, nach einem definierten Ablauf abzuarbeiten. Auch agile Vorgehensmodelle wie Scrum oder auch Kanban machen hier Vorschläge. Dabei wird Wert darauf gelegt, in kleinen Iterationen vorzugehen.

Im Rahmen der Stacey-Matrix wird weiterhin versucht, anhand der beiden Dimensionen Anforderungen (bekannt – unklar) und Vorgehen (bekannt-unklar) das geeignete Vorgehensmodell zu bestimmen. Im komplexen Bereich wird dann empfohlen, agile Vorgehensmodelle einzusetzen.

Es liegt auf der Hand, dass diese Einschätzung nicht alleine aufgrund zweier Dimensionen gemacht werden sollte, da es eine Vielzahl von Einflussfaktoren auf die Komplexität im Projektmanagement gibt. In der folgenden Tabelle sind einige davon aufgelistet.

Vielzahl	Vielfalt	Vieldeutigkeit	Veränderlichkeit
Größe Volumen Reichweite Häufigkeit Scale Dichte Laufzeit Multikonstella- tionen …	Diversität Heterogenität Interdiszi- plinarität Scope Heterogenity Multiplexität Antagonismen Konflikte Pluralismus Hybride …	Ambiguität Unschärfe Unsicherheit Konfusion Vagheit Intransparenz Spielräume Zweifel Wahlmöglich- keiten Paradoxien Überschnei- dungen …	Dynamik Geschwindigkeit Instabilität Diskontinuitäten Wachstum Überraschungen Volatilität Verbesserung Chaos ….

Komplexitätsdimensionen des Projektmanagements (Reiss 2018, in projektmanagementaktuell 3/2018)

In solch komplexen Systemen verändern sich die jeweiligen Parameter permanent, sodass eine eigene Dynamik entsteht. Es ist daher empfehlenswert, die Einschätzung darüber, ob es sich um ein kompliziertes oder komplexes Projekt handelt, mehrmals durchzuführen. Gerade am Anfang eines Projekts liegen noch nicht so viele Informationen über das Projekt vor (Cone of Uncertainty), sodass die erste Einschätzung fehlerbehaftet sein kann.

Grundsätzlich kann man davon ausgehen, dass Selbstorganisation die Antwort auf Komplexität ist. Daraus lässt sich ableiten, dass es nicht alleine erfolgversprechend ist, Standards einzusetzen, sondern dass auf allen Ebenen die Selbstorganisation zu entwickeln. Auf der individuellen Ebene, der Gruppenebene, der organisationalen Ebene und der Netzwerkebene.

Gehen wir nach Erpenbeck/Heyse von Kompetenz als Selbstorganisationsdisposition aus, so bedeutet das, in diesem Sinne Kompetenz auf der individuellen Ebene, der Gruppenebene, der organisationalen Ebene und der Netzwerkebene zu entwickeln (Kompetenzmanagement).

Siehe dazu auch Freund, R. (2011): Das Konzept der Multiplen Kompetenz auf den Analyseebenen Individuum, Gruppe, Organisation und Netzwerk.

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.

8. Februar 20258. Februar 2025

Ist die Verwendung von Persona das Gegenteil von Mass Customization?

Gerade im Agilen Projektmanagement werden Anforderungen häufig für Persona formuliert. Diese sind nach dem IREB (International Requirements Engineering Board) fiktive Charaktere, mit deren Hilfe Werte für die User geschaffen werden sollen. Dieses Vorgehen erinnert an eine Art Segmentierung aus dem traditionellen Marketing.

Mass Customization auf der anderen Seite ist eine hybride Wettbewerbsstrategie, die individuelle Produkte und Dienstleistungen für jeden Abnehmer – also massenhaft – anbietet, bei Preisen, die denen der massenhaft produzierten Standardprodukten ähneln. Dabei ist der Konfigurator ein wichtiges Element, das passende Produkt in einem Fixed Solution Space (Definierter Lösungsraum) zu erstellen. Die dahinterliegende Idee eines “Market of One” passt nicht so recht mit der Persona-Idee zusammen. Dazu habe ich folgendes gefunden:

“In many ways, a persona is the opposite of mass customization. It’s more traditional marketing thinking about how to deal with a larger number of segments. A “persona of one” is turning the persona idea to its opposite” Piller, Frank T. and Euchner, James, Mass Customization in the Age of AI (June 07, 2024). Research-Technology Management, volume 67, issue 4, 2024 [10.1080/08956308.2024.2350919], Available at SSRN: https://ssrn.com/abstract=4887846.

In Zeiten von Künstlicher Intelligenz wird es immer mehr Möglichkeiten geben, Produkte und Dienstleistungen massenhaft zu individualisieren und zu personalisieren. Ob die Verwendung von Persona in solchen eher agil durchzuführenden Projekten dann noch angemessen ist, scheint fraglich zu sein. Siehe dazu auch

Society 5.0 und Mass Customization

Freund, R. (2009): Kundenindividuelle Massenproduktion (Mass Customization). RKW Kompetenzzentrum, Faktenblatt 5/2009.

Wir sind dabei: 20 Jahre MCP-CE vom 24.-27.09.2024

5. Februar 20255. Februar 2025

Nutzen- und Kostenentstehung bei klassischen und agilen Vorgehensmodellen

Vergleich der Nutzenfeststellung und Kostenentstehung klassischer und agiler Methoden (*(Müller/Hüsselmann 2017, in projektmanagementaktuell 2/2017*

Klassische und agile Vorgehensmodelle im Projektmanagement unterscheiden sich bei verschiedenen Kriterien. In der Abbildung ist beispielsweise zu sehen, dass bei agilen Vorgehensmodellen, wie z.B. bei Scrum, der Projektnutzen stufenweise ansteigt. Bei Scrum ist das beispielsweise der Fall, da nach jedem Sprint ein Increment vorgestellt wird, das für den User einen Wert (Value) darstellt. Der nächste Sprint baut darauf auf, usw.

Bei klassischen, eher plangetriebenen Vorgehensmodellen steigt der Nutzen erst relativ spät, und eher “drastisch” an. Das geschieht oft in der Umsetzungsphase (Steuerungsphase). Dabei entstehen hier auch die meisten Kosten.

Siehe dazu auch Projektmanagement: Risikobewertung bei klassischen und agilen Vorgehensmodellen.

3. Februar 20254. Februar 2025

Künstliche Intelligenz: Wird Scrum durch den permanenten Fluss an Produkten zu Kanban?

In unsicheren, turbulenten Zeiten kommen plangetriebene Projekte an ihre Grenzen, da sich Anforderungen und Vorgehensweisen (Methoden/Techniken) oft ändern. Das bisher übliche eher langfristige planen über über mehrere Monate, Quartale und Jahre kommt an seine Grenzen.

Ein eher iteratives Vorgehen in eher kürzeren Zyklen bietet sich gerade bei Entwicklungsprojekten und hier besonders bei der Softwareentwicklung an. Das Agile Manifest und das Scrum-Framework sind entsprechende Antworten auf diese Entwicklungen. Im Vergleich zum plangetrieben Vorgehen, schlägt der Scrum-Guide vor, Produkte (Increments) maximal in einem Monat zu entwickeln. Die Praxis zeigt, dass Organisationen sogar zu 14-tägigen Zyklen tendieren.

In Zeiten von Künstlicher Intelligenz (KI) können allerdings gerade Software-Produkte immer schneller entwickelt und als Produkt (Increment) vorgestellt werden. das kann schon in wenigen Tagen, ja in wenigen Minuten erfolgen.

Was bedeutet das für das Scrum-Framework?

Gehen wir von dem Gedanken aus, dass Künstliche Intelligenz in immer schnelleren und kürzeren Zyklen Produkte generieren kann, wird der Scrum-Zyklus eher zu einem permanenten Fluss an Produkten – und somit eher zu einem Vorgehen, das wir aus Kanban kennen.

2. Februar 20252. Februar 2025

Projektmanagement: Risikobewertung bei klassischen und agilen Vorgehensmodellen

Vergleich der Projektrisikobewertung klassischer und agiler Methoden (*Müller/Hüsselmann (2017), in projektmanagementaktuell 2/2017*, in Anlehnung an Komus 2016)

In der Abbildung sehen Sie auf der Y-Achse das Projektrisiko abgebildet, das zu Beginn eines klassischen Projekts relativ hoch ist, und sich dann bei den verschiedenen Zeitpunkten der Risikobewertung reduzieren sollte. Es wird bei der Darstellung deutlich, dass das Projektrisiko zunächst langsam sinkt und dann rapide abnimmt, je mehr alle Projektbeteiligten über das Projekt Wissen. Siehe dazu auch Cone of Uncertainty.

Bei agilen Vorgehen haben wir über die Zeit eine stufenweise Abnahme des Projektrisikos von Beginn an. Durch die iterative Arbeitsweise, z.B. in Sprints, reduziert sich das Projektrisiko in “kleinen Häppchen”, an den verschiedenen Zeitpunkten – beispielsweise durch das Review am Ende eines jeden Sprints. Es wird auch hier deutlich, dass agile Vorgehensweisen Vorteile haben, wenn es um innovative Projekte geht, bei denen oft das Wissen über das Produkt und die Methoden unklar sind.

31. Januar 2025

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.

25. Januar 202525. Januar 2025

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.

23. Januar 2025

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?

21. Januar 202521. Januar 2025

Lokale KI-Anwendungen: Erster Test mit dem Modell Llama 3.2

Screenshot von unserer lokalen KI-Anwendung (LokalKI)

Wie Sie wissen, haben wir auf einem Server die Möglichkeit eingerichtet, KI-Modelle lokal auszuwählen und zu testen, bzw. zu nutzen – LokalKI oder LocalAI. Siehe dazu Free Open Source Software (FOSS): Eigene LocalAI-Instanz mit ersten drei Modellen eingerichtet.

Die verschiedenen Modelle können dazu vorab ausgewählt werden. Für diesen Test habe ich Llama 3.2 ausgewählt, was in der Abbildung zu erkennen ist. Der folgende einfache Prompt wurde im Textfeld (Unten in der Abbildung) von mir eingegeben:

Prompt (Blau hinterlegt): Du bist Projektmanager des Projekts Website. Erstelle eine Übersicht zu möglichen Stakeholder in Tabellenform. Ausgabe in einem Worddokument.

Das Ergebnis (Grün hinterlegt) kann sich durchaus sehen lassen. Die erste Übersicht zu möglichen Stakeholdern könnte genutzt und noch ein wenig angepasst werden.

Die Aufforderung, eine Tabelle in einer Worddatei zu erstellen wurde ignoriert, da das wohl in dieser Modell-Version nicht möglich ist. Das Ergebnis könnte ich natürlich selbst einfach in einer Worddatei kopieren.

Die Antwortzeit war relativ kurz was mich durchaus überrascht hat.

Insgesamt ist das Ergebnis natürlich noch nicht so, wie man das von ChatGPT usw. gewohnt ist, doch hier haben wir den Vorteil, dass alle Daten der KI-Anwendung auf unserem Server bleiben – auch wenn wir z.B. interne Dokumente hochladen.