Veröffentlicht am

Personas sind für Personalization ungeeignet

Personas sind (nach IREB-Glossar) „fictional characters created to represent the different user types that might use a site, brand, or product in a similar way.“ Die Verwendung von Personas gerade im Agilen Projektmanagement zur Ableitung der Anforderungen und zur Formulierung und Bewertung von User Stories ist populär. Dabei hatte ich allerdings auch schon in einem früheren Blogbeitrag auf auf Tücken dieser Vorgehenseise hingewiesen: Die Falle bei den Anforderungen.

Darüber hinaus hatte auch Frank Piller die Verwendung von Personas für die Hybride Wettbewerbsstrategie Mass Customization als nicht geeignet angesehen, da „A “persona of one” is turning the persona idea to its opposite“. Siehe dazu ausführlicher: Ist die Verwendung von Persona das Gegenteil von Mass Customization?

Neben dem Agilen Projektmanagement und Mass Customization haben sich auch Autoren mit Personas in Bezug zum Megatrend Mass Personalization befasst. Auch hier sieht man die Verwendung von Personas kritisch:

„Seit einiger Zeit „menschelt“ es in den Marketingabteilungen verstärkt. Anstelle von unanschaulichen Excel-Files mit ihren Tabellen und Diagrammen werden bei Präsentationen so genannte Personas zum Leben erweckt. Auch User Personas genannt. Einfach ausgedrückt dienen sie dazu, einen Zielkunden darzustellen.

Was Personas sind, darüber gehen die Meinungen in der Fachwelt auseinander. Die einen sprechen von fiktiven, aber realitätsnahen Nutzern, die anderen von prototypischen Kunden ihres Angebots – oder von archetypischen Nutzern. Zwar unterschiedlich bezeichnet, dienen sie einem einheitlichen Zweck: Sie repräsentieren Bedürfnisse einer Zielgruppe und machen es möglich, (mehr oder weniger) fundierte Entscheidungen bei der Entwicklung nutzerfreundlicher Produkte zu treffen. Von Beginn an.

Mass Personalization kann nicht realisiert werden, ohne die individuellen Nutzerbedürfnisse zu berücksichtigen. Die schlechte Nachricht: Personas sind nicht zu 100 Prozent zielführend und helfen bei personalisierten Produkten nicht weiter. Sie bieten nur eine Typisierung der Nutzer für Entwicklungszwecke und keine Personalisierung für die Produktion. Stattdessen wird ein parametrisiertes Profil benötigt, das mit dem individualisierten Fertigungsplan gematcht werden kann“ (Briehm/Dangelmeyer, in Krieg/Groß/Bauernhansl (2024) (Hrsg.)).

Es ist nicht ganz leicht, die feinen Unterschiede zu erkennen und daraus die richtigen Schlussfolgerungen zu ziehen. Daher ist es wichtig, sich zu informieren, und das aus erster Hand.

Im September 2026 haben Sie dazu auf der 12. MCP 2026 zu Mass Customization und Personalization die Möglichkeit. Die internationale Konferenz findet diesmal in Balatonfüred, Ungarn statt. Sprechen Sie mich bei Fragen bitte direkt an. Als Initiator der Konferenzreihe kann ich Ihnen gerne weitere Informationen geben.

Veröffentlicht am

Projektmanager/in Agil (IHK): Zertifikatsworkshop am 01.12.2025 in Düsseldorf

Den von uns entwickelten Blended Learning Lehrgang Projektmanager/in (IHK) haben wir am 01.12.2025 mit einem Zertifikatsworkshop in Düsseldorf abgeschlossen. Die Teilnehmer haben dabei u.a. die verschiedenen Themen des Lehrgangs auf eine Fallstudie übertragen und ihre Ergebnisse vorgestellt.

Neben Lean/Kanban, Scrum, Scaling Agile, und Agiler Vertragsgestaltung haben wir uns in einem Modul des Lehrgangs speziell mit den Möglichkeiten des Hybriden Projektmanagements befasst. Wie die globale PMI-Studie aus 2024 gezeigt hat, wird das Hybride Projektmanagement immer wichtiger, da es im Vergleich zum Klassischen Projektmanagement und dem Agilen Projektmanagement (z.B. mit Scrum) weniger dogmatisch, sondern eher pragmatisch ist.

Eigene Darstellung; Quelle: PMI (2024): Annual Global Survey on Project Management 2020, 2021, 2022, 2023
Veröffentlicht am

Steckbrief zu KANBAN: Vorteile und Nachteile

Steckbrief KANBAN (Timinger 2021), eigene Darstellung

Alle Vorgehensmodelle im Projektmanagement haben Vorteile und Nachteile. In einem ersten Beitrag habe ich das beispielsweise schon einmal am Wasserfallmodell dargestellt. Siehe Steckbrief zum Wasserfallmodell: Vorteile und Nachteile.

Wie in der Abbildung zu erkennen ist, hat auch KANBAN Vorteile und Nachteile. Seit Anderson (2010): KANBAN in der IT ist klar, dass KANBAN geeignet ist, wissensbasierte Arbeit zu organisieren.

KANBAN ist weniger präskriptiv (vorschreibend) im Vergleich zum SCRUM Framework, und ist auf der individuellen Ebene, der Teamebene und auf der organisationalen Ebene einsetzbar.

Verwechselt wird KANBAN oft mit allen möglichen Boards, die allerdings keine KANBAN Boards sind, wenn z.B. die Prozessschritte nicht begrenzt sind (WIP: Work in Progress) und die Tickets nicht nach dem Pull-Prinzip abgearbeitet werden.

Es geht in Zukunft immer mehr darum, das geeignete Vorgehensmodell zum Vorhaben (Projekt) auszuwählen. Dieser Trend ist in der Zwischenzeit an dem großen Anteil des Hybriden Projektmanagements – also einer sinnvollen Kombination von mehreren Vorgehensmodellen – abzulesen. Siehe dazu PMI (2024) Global Survey: Hybrides Projektmanagement wird immer wichtiger.

Veröffentlicht am

Projektmanager/in Agil ab Ende Oktober in Düsseldorf

Der von uns entwickelte Blended Learning Lehrgang Projektmanager/in Agil (IHK) wird im Oktober wieder in Düsseldorf angeboten:

Projektmanager/in Agil (IHK) – Blended Learning Lehrgang
Flyer und IHK-Website 
27.10.-01.12.2025, IHK Düsseldorf
Ansprechpartnerin: Frau Wanke, Telefon: 0211/17243-35
E-Mail: petra.wanke@duesseldorf.ihk.de      

In dem Lehrgang geht es u.a um folgende Themen:

Unternehmen sollten wissen, wie sie die Projekte herausfiltern, die dann sinnvoll mit agilen Methoden durchgeführt werden können.

Es gibt nicht nur Scrum als agiles Rahmenwerk, auch Lean und Kanban gehören zu geeigneten Vorgehensmodellen. Bei Kanban gibt es – im Vergleich zu Scrum – nicht die Trennung der Projektmanager-Rolle in Product Owner und Scrum Master.

Scrum: Hier ist zwischen dem Scrum-Guide und ScrumAnd (z.B. Scrumban) bzw. ScrumBut zu unterscheiden. Nicht alle Unternehmen nutzen Scrum genau nach dem aktuellen Scrum-Guide.

Herauszufinden, was die agilen Anforderungen sind ist nicht Bestandteil des Scrum-Guides. Wir ergänzen diesen Punkt daher mit dem Requirementsboard.

Agile Vertragsgestaltung: Ein wichtiges Element, da die Leistung nicht, wie beim Klassischen(Plangetriebenen) Projektmanagement, genau beschrieben vorliegt (Magisches Dreieck).

Hybrides Projektmanagement: Hier gibt es viele Variationen, was einen Ordnungsrahmen erforderlich macht.

Scaling Agile: Der Scrum-Guide wurde für einzelne Projekte geschrieben, doch wie geht man mit vielen agilen Projekten um? Nexus und LeSS orientieren sich stark am Scrum-Guide. SAFe wiederum hat eine umfangreiche Struktur und nutzt verstärkt Lean und Kanban. Hier schließt sich der Kreis des Gesamtkonzepts.

Ein(e) Projektmanager/in Agil (IHK) ist somit für verschiedene Rollen in Organisationen geeignet.

Veröffentlicht am

Projektmanagement: Gegenüberstellung der Merkmale klassisch vs. agil

Klassisch-PlangetriebenAgil
AnforderungenWeitgehend bekannt
Änderungen unerwünscht		Teilweise unbekannt
Änderungen erwartet
Umfang (Scope)Lasten- und PflichtenheftBacklog
ZieleLeistung: grundsätzlich fix
Dauer: ausgerichtet an der Leistungserbringung
Kosten: ausgerichtet an der Leistungserbringung		Leistung: ausgerichtet an der Dauer und dem Machbaren
Dauer: grundsätzlich fix
Kosten: grundsätzlich fix (Personalkosten)
PlanungPhasen, Meilensteine, Arbeitspakete,
Liefergegenstände/-objekte
Up-Front, aber rollierend möglich		Releases, Epics, Features, User Stories,
Inkremente
grundsätzlich rollierend
Aufwand (Personal)Schätzung im Gegenstromverfahren
(Management, Experten)
in Personentagen
Up-front, dann ggf. nachsteuernd		Schätzung durch das Team
in Story Points

rollierend
Steuerungs-
instrumente		Fortschrittsmetriken, Meilensteintrendanalyse,
Earned Value Analyse
Status Meeting, Berichte		Acceptance of Done, Taskboard,
Burn-Down-/-Up-Chart

Sprint-Review, Daily Stand Up
Hüsselmann/Hergenröder (2024): Integrierte Earned Value Analyse, nach Fiedler (2020)

Das klassische, eher plangetriebene Vorgehen beim Projektmanagement ist seit vielen Jahren bekannt und etabliert. Es wundert daher nicht, dass es gerade etablierten Organisationen schwer fällt, die beim agilen Projektmanagement zu berücksichtigen Vorgehensweise zu integrieren..

Die in der Tabelle zusammengefasste Gegenüberstellung der Merkmale „Anforderungen“, „Umfang (Scope“, „Ziele“, „Planung“, „Aufwand (Scope)“ und „Steuerungsinstrumente“ gibt Ihnen noch einmal einen Gesamtüberblick dazu.

Dabei sollten Sie allerdings bedenken, dass es oft nicht um ein Entweder-oder, sondern um ein Sowohl-als-auch geht, was als Hybrides oder auch Adaptives Projektmanagement bezeichnet werden kann.

Siehe dazu auch DAS Projektmanagement-Kontinuum in der Übersicht.

Veröffentlicht am

Hybrides Projektmanagement: Vom Trend zum neuen Standard

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.

Veröffentlicht am

Kann die Earned Value Analyse (EVA) für Scrum genutzt werden?

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.

Veröffentlicht am

Plangetriebenes Projektmanagement: Synchronisationspunkte zwischen Software, Elektronik und Hardware

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.

Veröffentlicht am

Wolpers, S. (2020): The Remote Agile Guide

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.

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.