Hier erfahren Sie:

• Wie Sie Risiken frühzeitig erkennen, bewerten und aktiv steuern statt nur zu reagieren.
• Risikomanagement ist ein kontinuierlicher Prozess – nicht einmalig, sondern laufend.
• Eine offene Risikokultur im Unternehmen erhöht die Erfolgsquote von Projekten.

Diese Kapitel mit vielen wichtigen Praxis-Tipps zum Risikomanagement warten auf Sie:

• Risikomanagement Definition
• Was sind beispielhafte Risiken in Projekten?
• Risikomanagement Beispiel
• Was sind die Risikohaltungen für Projekte?
• Risikomanagement Beispiel, Risikoanalyse und wichtige Aufgaben
• Risikomaßnahmen zur Risikobewältigung in Projekten
• Zusammenfassung – Risikomanagement im Projektmanagement

Zuerst aber starten wir mit der Definition von Risikomanagement und der Betrachtung, warum Risikomanagement im Projektmanagement überhaupt wichtig ist.

Viel Spaß beim Lesen.

Risikomanagement Definition

Risikomanagement ist eine Führungsaufgabe, im Rahmen derer die Risiken einer Organisation identifiziert, analysiert und später bewertet werden. Hierzu sind übergeordnete Ziele, Strategien und Politik der Organisation für das Risikomanagement festzulegen. Im Einzelnen betrifft dies die Festlegung von Kriterien, nach denen die Risiken eingestuft und bewertet werden, die Methoden der Risikoermittlung, die Verantwortlichkeiten bei Risikoentscheidungen, die Bereitstellung von Ressourcen zur Risikoabwehr, die interne und externe Kommunikation über die identifizierten Risiken sowie die Qualifikation des Personals für das Risikomanagement. (Quelle: Wikipedia)

Der weltweite Berufsverband Project Management Institute (PMI) definiert „Risiko“ als Ereignis mit unsicherem Eintritt. Neben Bedrohungen bezieht dies folglich auch Chancen mit ein.

Das Risikomanagement im Projektmanagement soll die Chancen für das Erreichen der Projektziele erhöhen. Gleichzeitig sollen die Risiken für das Scheitern eines Projekts minimiert werden. Professionelles Risikomanagement ist ein iterativer Vorgang. Dieser erfordert die ständige Überprüfung der Realitäten, Neubewertung und Anpassung von Maßnahmen und Plänen.

Was sind beispielhafte Risiken in Projekten?

Folgende Risiken im Projektumfeld sind etwa zu managen:

• Wirtschaftliche Verluste
• Rufschäden des Unternehmens
• Gefahren für Leib und Leben von Nutzern eines Produkts
• Zeitplanverschiebungen
• Technische Probleme
• Definition Projektumfang
• Ressourcenknappheit
• Qualitätsprobleme etc.

Allerdings kann im Projektalltag ganz schnell der umgekehrte Effekt eintreten: Mögliche folgenreiche Risiken bleiben unerkannt, werden vergessen, ignoriert. Lieber nicht darüber nachdenken, was alles passieren kann.

Kennen Sie das?

Die Praxis zeigt uns, dass das Ausblenden von Risiken im Projektumfeld gefährlich ist. Das gilt auch, wenn Risikomanagement im Projektmanagement nicht verpflichtend durch Ihre Organisation vorgegeben ist. Gefährlich kann es etwa dann werden, wenn in einem Projekt Leib und Leben, monetäre Faktoren oder der Firmenruf auf dem Spiel stehen.

Der durchdachte Aufbau von Risikomanagement im Projektmanagement hilft Ihnen, Ihre Projekte zum Erfolg zu führen.

Gute Projektmanager versuchen, Risiken zu identifizieren und den Umgang mit ihnen zu planen.

Zu welchem Ausmaß Projektmanager Maßnahmen konkret umsetzen und für welche sie sich entscheiden, hängt unter anderem von der Branche und von der eigenen Unternehmenskultur ab.

Übrigens: Die mit einem Projekt verbundene Unsicherheit kann ebenfalls ein Risikofaktor sein.

Risikomanagement Beispiel

Oftmals lauern unerwünschte Langzeiteffekte auch bei vermeintlich überschaubaren Projektrisiken im Verborgenen. Hier zwei kurze Risikomanagement Beispiele:

• Beispiel 1: Eigentlich war das Projekt zur Neuentwicklung von Kundenzufriedenheitsumfragen keine große Sache. Aber später stellte sich heraus, dass wichtige Fragen vergessen wurden und jetzt Daten zur Auswertung fehlen…
• Beispiel 2: Das Online-Formular auf der Website erzeugt Fehler und mehr Frust als Freude bei den Kundinnen und Kunden. Daher wenden sich diese vermehrt ab…

Durch Risikomanagement und eine aufmerksamere Haltung hätten solche Risiken im Voraus vielleicht vermieden werden können.

Deshalb gibt es Mittel und Methoden für effektives Risikomanagement. Mit deren Einsatz kann in manchen Fällen der Projekterfolg stehen oder fallen.

Was sind die Risikohaltungen für Projekte?

Sie können sich selbst fragen: Bin ich als Projektmanager eher:

• risikoscheu (Risiken vermeidend)
• risikotolerant (nicht besonders viel über Risiken nachdenkend)
• risikoaffin (Risiken bewusst eingehend)?

Studien haben gezeigt, dass viele Projektmanager grundsätzlich eher risikoscheu sind – außer sie müssen ihr Projekt gerade durch eine Krise navigieren. Zeit- und Erfolgsdruck tun oft ihr Übriges dazu.

Prinzipiell spricht auch nichts dagegen, vorsichtig zu agieren. Aber die großen Chancen dürfen dadurch nicht einfach ausgelassen werden.

Besser ist es, die Risiken möglichst genau zu analysieren, bevor eine Entscheidung über den Umgang mit diesen fällt.

Beispiel: „Rollen wir die neue Software nur deshalb nicht jetzt unternehmensweit aus, weil wir uns über die Auswirkungen im Unklaren sind? Oder haben wir die Risiken dabei genau untersucht und einen entsprechenden Zeitplan erstellt – sprich, wissen wir, was wir tun?“

Unser Tipp: Machen Sie sich über Ihre eigene Risikohaltung und die Ihres Unternehmens bewusst. Das sollten Sie tun, bevor Sie Ihr Risikomanagement im Projektmanagement planen. Und kommunizieren Sie eventuelle Abweichungen zum Standardvorgehen aktiv und mit fundierter Begründung für die jeweilige Projektsituation.

Risikomanagement in verschiedenen Branchen

Natürlich spielt beim Risikomanagement im Projektmanagement auch die Branche eine große Rolle. Stark regulierte und oft hoch riskante Umgebungen, z.B. die Finanzbranche, werden immer etwas vorsichtiger sein. Sie müssen auch von ihren Projektmanagern bestimmte Vorgehensweisen verlangen.

Branchen, in denen bei Projekten und Produkten das Leben der Anwendenden auf dem Spiel stehen könnte, z.B. die Luftfahrt-, Automobil- oder auch die Bauindustrie, gehen oft alleine schon deshalb mit einem kalkulierten Risikomanagement einher. Hier ist die Verantwortung sehr hoch.

Auch Projekte mit großer Gefahr einer Rufschädigung für das eigene Unternehmen werden vorsichtiger durchgeführt als solche, bei denen der gute Ruf nicht unbedingt auf dem Spiel steht.

Risikomanagement Beispiel, Risikoanalyse und wichtige Aufgaben

Wenn Projektmanager professionell mit Risiken umgehen wollen, dann müssen sie zunächst einmal für einen vollen Werkzeugkasten sorgen. Einige der Techniken lernen Sie im Folgenden kennen.

Aufgabe 1: Risikoerkennung

Zur Identifikation von Risiken brauchen Sie Techniken, die kreative Denkprozesse anregen. Sie können:

• Projektdokumente prüfen
• Meetings mit Stakeholdern und Experten abhalten
• Brainstorming-Sitzungen einberufen
• Checklisten erstellen.

Wenn das nicht ausreicht und der Verdacht besteht, einige wichtige Risiken könnten noch unerkannt sein, hilft vielleicht die Delphi-Methode.

Bei der Delphi-Methode befragt die oder der Projektmanager eine Gruppe von Experten unabhängig voneinander und anonym. Sollten sich die Antworten stark voneinander unterscheiden, werden sie allen mitgeteilt. Dies soll eine Diskussion ermöglichen. Das Vorgehen wird solange wiederholt, bis die Aussagen nicht mehr so sehr auseinandergehen.

Der Nutzen der Delphi-Methode: Hiermit können Sie sicherstellen, dass jeder offen seine Meinung äußert, niemand zu sehr beeinflusst wird und sich auch keiner zurückhält, weil etwa andere einen dominanten Eindruck machen.

Nominal Group Technique: Ähnliche Gründe gibt es, die Nominal Group Technique zu verwenden: Das funktioniert wie Brainstorming. Aber, anstatt dass jeder seine Ideen laut herausruft, schreibt er oder sie diese auf Zettel, welche dann eingesammelt werden. So können Sie dafür sorgen, dass auch leisere Stimmen in ihrem Team Gehör finden.

SWOT-Analyse: Wenn Sie in einem Projekt mit hohen Unsicherheiten arbeiten und als Team Neuland betreten, lohnt sich vielleicht eine Analyse der Stärken, Schwächen, Chancen und Bedrohungen (SWOT-Analyse). Anhand der vier Dimensionen überlegen Sie, worin Sie als Unternehmen oder als Projektteam gut sind und wo Sie noch Verbesserungspotential sehen. Daraus leiten Sie Risiken für Ihr Projekt ab.

„Pre-Mortem“ Ansatz: In agilen Projekten hat sich eine weitere interessante Übung bewährt: Beim „Pre-Mortem“ stellen sich Teams vor, ihr Projekt wäre bereits gescheitert und stellen sich die Frage, was passiert sein könnte und warum.

Im Gegensatz zum Post-Mortem, also der Projektobduktion nach dem Scheitern, tun sie dies bereits zu Projektbeginn. Daraus leiten sie dann Handlungsempfehlungen ab. Das soll den Misserfolg des Projektes möglichst verhindern.

Hirnforscher konnten nachweisen, dass der Perspektivenwechsel (wir stellen uns vor, wir wären bereits in der Zukunft und schauen zurück) dafür sorgt, dass die Beteiligten die Szenarien viel konkreter und kreativer durchspielen als bei reinem vorausschauendem Brainstorming.

Unser Tipp: Welche Methode Sie im Einzelfall auch verwenden: Am Ende sollten Sie ein Risikoregister, also eine Liste der erkannten Risiken in Ihrem Projekt, vor sich haben.

Rechnen Sie aber damit, dass es zu jedem Zeitpunkt immer noch unerkannte Risiken geben kann. Alles können Sie nicht vorhersehen. Nutzen Sie das Risikoregister-Dokument z.B. zur Kommunikation mit Stakeholdern. Oder nutzen Sie es, um die Gefahr zu verringern, Projektrisiken aus den Augen zu verlieren.

Vergessen Sie nicht, das Risikodokument in regelmäßigen Abständen zu überprüfen und zu aktualisieren. Auch Strategien für jedes dieser Risiken sollten darin festgehalten werden.

Unser Tipp: Damit Sie nicht redundante Maßnahmen planen, lohnt sich im Risikomanagement eine Analyse der Grundursachen. Vielleicht finden Sie für einige Risiken eine gemeinsame Ursache. Indem Sie deren Bewältigung angehen, können Sie einige Risiken auf einmal behandeln.

Aufgabe 2: Risikoanalyse im Projekt und deren Visualisierung

Ein nächster möglicher Schritt beim Risikomanagement ist die qualitative Risikoanalyse im Projektmanagement.

Wann macht man eine Risikoanalyse im Projektmanagement?

Die Risikoanalyse identifiziert Risiken und Chancen innerhalb eines Projekts. Dann bewertet und priorisiert sie diese. Die Analyse findet nach der Risikoerkennung statt und ist ein iterativer Prozess, der im gesamten Projektverlauf wiederholt wird. Eine effektive Risikoanalyse stellt alle Risiken, die den Erfolg eines Projekts bedrohen, für alle Projektbeteiligten transparent dar und erleichtert es damit, ein Projekt in risikoärmere Bahnen zu lenken.

Bei der Risikoanalyse im Projekt werten und gewichten Sie also die erkannten Risiken. So bestimmen Sie dann jeweils die Dringlichkeit, mögliche Auswirkungen und Priorität.

Die aus Ihrer Sicht größten Gefahren für Ihr Projekt können Sie weiter analysieren.

Dafür gibt es einige detailliertere Diagrammtechniken wie:

• Das Tornado-Diagramm für die Visualisierung der geschätzten Auswirkungen
• Die Monte-Carlo-Simulation für das Durchspielen von Szenarien mit einem Zufallsgenerator
• Entscheidungsbäume für die Eingrenzung möglicher Maßnahmen

• Mit einer Risiko-Matrix visualisieren Sie die aktiven Risiken in einer farbigen Matrix von Auswirkung über Wahrscheinlichkeit. Die Risikotabelle vereinfacht Ihnen die Kommunikation innerhalb des Projektteams. Dieses Werkzeug kann Ihnen auch gut helfen, um den Projektsponsoren oder dem Lenkungsausschuss die Risikosituation im Projekt anschaulich darzustellen. Die grafische Anzeige der Risiko-Matrix unterstützt die Projektmanager dabei, Prioritäten zu setzen und Antwortstrategien auf die Risiken zu entwickeln, wie sie weiter unten beschrieben werden.

Monetäre Risikoanalyse für Rücklagenbildung

Besonders wichtig bei Risiken ist es, mögliche finanzielle Verluste im Blick zu behalten und gegebenenfalls abzufedern. Generell gibt es dafür die Möglichkeit, den monetären Erwartungswert von Risiken nach der folgenden Formel zu errechnen. Dafür gibt es die monetäre Risikoanalyse im Projektmanagement:

Monetären Erwartungswert = Wahrscheinlichkeit eines Risikos (%) * erwartete finanzielle Auswirkung.

Daraus können Sie mögliche Risikozuschläge ableiten, also für erkannte und analysierte Risiken eingerichtete Rücklagen.

Im Gegensatz dazu werden Reserven durch das Management allgemeiner für all das in der Hinterhand gehalten, was eintreten könnte und noch nicht erkannt wurde.

Unser Tipp: Je früher Sie durch die Risikoanalyse als Teil des Risikomanagements einem Risiko im Projekt begegnen, desto kostengünstiger und wirksamer ist meist die Lösung. Kümmern Sie sich also schon zu Beginn um die Risikofragen, wenn ein Projekt eine hohe Wichtigkeit für Ihr Unternehmen hat.

Aufgabe 3: Planung von Risikomaßnahmen bei Risikoakzeptanz

Rücklagen- und Reservenbildung sind Formen der aktiven Risikoakzeptanz. Der Eintritt des Risikos wird in Kauf genommen, aber nicht, ohne dafür vorzusorgen. Sollte das Risiko nicht eintreffen, werden die Rücklagen wieder freigegeben.

Risikomaßnahmen zur Risikobewältigung in Projekten

Welche Art von Maßnahme sich beim Risikomanagement im Projektmanagement für welches Projektrisiko eignet, ergibt sich aus der Analyse und den konkreten Möglichkeiten in einer Situation.

Häufige Typen von Risikomaßnahmen sind:

• Vermeidung / Verhinderung (Gefahr beseitigen oder umgehen)
• Abmilderung (Eintrittswahrscheinlichkeit oder das Schadensausmaß verringern)
• Übertragung (Verantwortung an eine dritte Partei, wie eine Versicherung, übertragen)
• Aktive Akzeptanz (Risikozuschläge und Reserven einrichten)
• Passive Akzeptanz (nichts tun)
• Eskalation (Management um Hilfe bitten)

Passive Akzeptanz (reine Inkaufnahme ohne Handlung) kann für Sie bei manchen Risiken eine adäquate Reaktion sein. Bei anderen benötigen Sie vielleicht die Bereitstellung von Reserven, den Abschluss einer Versicherung, die Einbindung Ihrer Führungsetage oder weitere Maßnahmen.

Wichtig ist, dass Sie die Entscheidung über den Umgang mit Risiken auf einer durchdachten Basis fällen. Dafür müssen Sie die Risiken vorab erkennen, analysieren und beurteilen – also Risikomanagement leben!

Und, fast noch wichtiger: Es reicht nicht, wenn Sie sich mit Risiken nur einmal zu Beginn des Projekts beschäftigen. Professionelles Risikomanagement ist ein iterativer Vorgang, der ständige Überprüfung der Realitäten, Neubewertung und Anpassung von Maßnahmen und Plänen erfordert.

Unser Tipp: Machen Sie sich regelmäßig Gedanken über die möglichen Risiken in Ihren Projekten. Nur am Anfang reicht nicht! Für Risiken mit hohen Auswirkungen und hoher Eintrittswahrscheinlichkeit sollten Sie immer konkrete Maßnahmen geplant haben und diese offen kommunizieren. Und prüfen Sie auch regelmäßig, ob die Maßnahmen noch passen.

Zusammenfassung – Risikomanagement im Projektmanagement

In diesem Artikel haben Sie erfahren, warum aktives Risikomanagement im Projekt von Nutzen ist und welche Gefahren es zu vermeiden hilft. Gefährlich kann es etwa dann werden, wenn in einem Projekt Leib und Leben, monetäre Faktoren oder der Firmenruf auf dem Spiel stehen.

Außerdem haben Sie einige Methoden zur Risikoidentifikation und Bewertung von Risiken kennengelernt, einschließlich agiler Techniken.

Professionelles Risikomanagement im Projektmanagement ist machbar, wenn Sie ein paar Tricks und Kniffe kennen. Und es lohnt sich: Wenn Sie ganz unabhängig von Branche und Risikofreudigkeit Ihre Risiken aktiv erkennen, analysieren und kommunizieren, dann können Sie in vielen Fällen mehr Projekterfolg für sich verbuchen.

Trauen Sie sich heran an dieses Thema! Es wird sich sofort für Sie auszahlen, wenn ein theoretisches Risiko plötzlich zur Realität wird.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps zu Projektmanagement-Grundlagen erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig beim TPG Projektmanagement Seminar.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin.

Der Beitrag Risikomanagement im Projektmanagement – praktische Tipps, wie Sie es richtig durchführen erschien zuerst auf TPG Projektmanagement Blog für Profis.

Dieser Artikel ist Bestandteil unserer Blog-Reihe „Jira für Rollen im Projektmanagement“. Auf dieser Seite erfahren Sie drei Möglichkeiten für Confluence und Jira als PMO-Tool. Lernen Sie, wie Sie Jira für eine bessere High-Level-Übersicht des Projektportfolios sowie für Ihre Fortschrittsmessung nutzen können und worauf Sie dabei achten sollten. Das sind die Themen, die auf Sie warten:

• Welche PMO-Aufgaben können Jira und Confluence unterstützen?
• Tipp 1: Jira im Projektmanagement: Möglichkeiten und Grenzen beim Projektüberblick
• Tipp 2: Jira Dashboards und Roadmaps für bessere Übersicht
• Tipp 3: Einfacher arbeiten durch Integration von Jira mit Microsoft Project
• Eine Alternative: PPM auf Microsoft 365 und der Power Platform
• Fazit – Jira im Projektmanagement für PMOs nutzbar, mit Grenzen

Legen wir los mit zwei kurzen Definitionen.

Was ist Jira?

Atlassian Jira ist ein webbasiertes Tool für Aufgabenmanagement, Projektmanagement und Fehlerverwaltung. Es kommt hauptsächlich bei Teams in der Produkt- und Softwareentwicklung zum Einsatz. Agil arbeitende Teams werden unterstützt mittels verschiedener Projekt- und Boardtypen (z.B. Kanban, Scrum, Projektmanagement u.v.m.).

Was ist Confluence?

Atlassian Confluence ist eine webbasierte Wiki-Software, die die interne Zusammenarbeit in Projektteams und im Unternehmen unterstützt. Das Tool lässt sich hervorragend mit Jira integrieren und bietet in dieser Kombination beste Voraussetzungen für agil arbeitende Teams.

Welche PMO-Aufgaben können Jira und Confluence unterstützen?

Jira ist vor allem für Aufgabenmanagement gedacht und bildet dabei die Realitäten verschiedener Teams durch diverse Projekt- und Boardtypen gut ab. Es ist aber kein vollumfängliches Tool für Projektmanagement oder Portfoliomanagement wie Microsoft PPM. Dies gilt auch dann, wenn Sie Jira mit Confluence für die Dokumentation kombinieren. Außerdem bietet Jira ServiceDesk (eine weitere App aus der Atlassian Suite) mehr Funktionalitäten für Support-Teams.

Die Umfrage von TPG The Project Group zu PMO-Tools zeigte als Ergebnis: Die meisten Antwortenden aus dem PMO-Umfeld verwenden Jira vor allem für:

• Issue-Management und
• Change Requests

Weniger zum Einsatz kommt Jira im Projektmanagement für Statusberichte und Kapazitätsplanung – und gar nicht für Kostenplanung oder Stakeholderanalyse. Dabei sind diejenigen, die Jira für die genannten Zwecke verwenden, im Schnitt sehr zufrieden mit dem Tool.

Die Umfrage hat weiterhin ergeben: Am besten arbeiten PMOs mit einer Kombination geeigneter und miteinander synchronisierter Tools für die jeweiligen PMO-Aufgabenbereiche.

Aus der PMO-Umfrage haben wir für diesen Artikel wichtige Arbeitsbereiche des PMO ausgewählt. Nun soll die Frage beantwortet werden, wie diese Bereiche mithilfe der Atlassian Toolsuite gut abgebildet werden können:

• Projektliste
• Multi-Projektberichte
• Ideenpipeline
• Projektanträge und -aufträge
• Change Requests
• Issue-Management
• Projektstatusberichte
• Ist-Stunden-Erfassung und Ressourcenplanung im Projekt und im Team

Hinweis: Die folgenden Tipps betrachten der Einheitlichkeit halber Jira / Confluence Cloud mit Spracheinstellung auf Englisch. Falls Sie in Ihrem Unternehmen eine On-Premise- / Data-Center-Version und / oder eine deutsche Spracheinstellung nutzen, kann es sein, dass der Funktionsumfang oder die Terminologie abweichen.

Bitte beachten Sie auch: Die folgenden Tipps benötigen etwas Vorwissen in Jira. Wenn Sie noch nicht mit Jira gearbeitet haben, ist das Verständnis dieser Tipps nicht immer ganz einfach.

---

Tipp 1: Jira im Projektmanagement – Möglichkeiten und Grenzen beim Projektüberblick

Gehen wir nun die oben genannten PMO-Aufgabenbereiche mit dem Ziel eines möglichst guten Projektüberblicks durch:

Projektliste

In Jira sehen Sie unter „Projects“ / „View All Projects” eine Liste aller Projekte in Ihrer Jira-Instanz, auf die Sie Zugriff haben. Diese Liste können Sie in Ihren Profileinstellungen auch als Standard-Startansicht nach dem Einloggen in Jira festlegen.

Multi-Projektberichte

Sie können die Arbeit verschiedener Teams in Jira-Dashboards tracken – mehr dazu in Tipp 2.

Ideenpipeline

Für Ideensammlungen lohnt es sich, ein eigenes, unternehmensverwaltetes Projekt in Jira anzulegen (oder durch Ihre Jira-Administratoren anlegen zu lassen, wenn nur diese über Berechtigungen zur Projekterstellung verfügen), etwa vom Typ Software Kanban. Kanban deshalb, da Sie dort die Spaltenbenennungen des Boards umkonfigurieren können:

Projektanträge und -aufträge

Neue Projektanträge können Sie, ähnlich wie durch eine Ideenpipeline, als Issues in ein dafür angelegtes Jira-Sammelprojekt eintragen. Praktischerweise lässt sich dies über den Issue-Workflow und die Spaltenanordnung auch mit einem Genehmigungsprozess versehen. Alternativ kann für jede Projektidee gleich ein eigenes Jira-Projekt erstellt werden.

Schritt-für-Schritt-Anleitung: Projektantrags-Pipeline in Jira

1. Legen Sie ein Sammelprojekt für Projektanträge an

• Erstellen Sie ein neues Kanban-Projekt, zum Beispiel mit dem Namen „Projektanträge“.
• Wählen Sie wieder das Kanban-Template aus, da es eine flexible Spaltenstruktur bietet.
• Konfigurieren Sie die Spalten nach Ihrem Bedarf, z.B.:
  • Antrag eingereicht
  • In Prüfung
  • Genehmigt
  • Abgelehnt

2. Richten Sie einen einfachen Genehmigungsprozess ein (optional)

• Gehen Sie in Ihrem Jira-Projekt auf „Projekteinstellungen“ > „Workflows“.
• Bearbeiten Sie den Workflow:
  • Fügen Sie zusätzliche Status wie „In Prüfung“ oder „Warten auf Entscheidung“ ein.
  • Legen Sie Übergänge fest, z.B. von „eingereicht“ zu „genehmigt“ oder „abgelehnt“.
  • Wenn Sie möchten, können Sie Bedingungen, Validatoren oder Genehmigungsschritte hinzufügen – dies erfordert unter Umständen Unterstützung durch Ihre Jira-Administratoren.

3. Verknüpfen Sie Ideen mit Projektanträgen

• Öffnen Sie ein Jira-Issue in Ihrer Ideenpipeline, das nun zu einem Projektantrag werden soll.
• Klicken Sie im Menü auf „Verknüpfte Vorgänge“ (oder „Link hinzufügen“).
• Wählen Sie die Option „ist Grundlage für“ oder eine ähnliche Beziehung und verlinken Sie den entsprechenden Projektantrag.
• So behalten Sie die Verbindung zwischen ursprünglicher Idee und offiziellem Antrag transparent und nachvollziehbar.

4. Nutzen Sie Felder und Labels für mehr Struktur

• Sie können benutzerdefinierte Felder hinzufügen, z.B.:
  • Geplantes Startdatum
  • Projektbudget
  • Antragsteller:in
• Nutzen Sie Labels oder Komponenten, um Anträge thematisch zu gruppieren (z.B. „IT“, „Marketing“ oder „Innovation“).

Mit diesem Setup können Sie einen einfachen, aber wirkungsvollen Genehmigungsprozess in Jira etablieren – ohne zusätzliche Tools. Wenn Sie ausführlichere Texte oder Entscheidungsvorlagen benötigen, empfiehlt es sich, Confluence-Seiten anzulegen und zu verlinken.

So gehen Sie dabei vor: Erstellen Sie einen eigenen Confluence-Space für Ihr Projekt und darin eine Seite nach einer der verfügbaren Vorlagen. Dann können Sie in Jira diese Seite oder auch den gesamten Space verlinken.

Nutzen Sie die „Project Kickoff“-Vorlage in Confluence. Alternativen sind die Templates “Project poster“, „Master project documentation“, „Project plan“ und einige weitere, die dieser ähnlich sind.

Wenn Confluence an Jira angebunden ist, können Sie in einem Issue über das Drop-Down-Symbol neben „Link Issue“ auf „Link Confluence Page“ gelangen (siehe folgenden Screenshot) …

… und dann wird die Seite im Issue als Verlinkung aufgeführt.

Change Requests

Als Issue-Management-System ist Jira gut für die Verwaltung und Abarbeitung einer Change-Request-Liste geeignet. Hierfür können ein eigener Workflow und eigene Issue-Typen durch Jira-Administratoren (bei unternehmensverwalteten Projekten) oder durch Projektadministratoren (bei teamverwalteten Projekten) erstellt werden.

Wenn Sie Jira Service Desk angebunden haben, finden Sie dort bereits einen eigenen Change-Workflow: Change management | Jira Service Management Cloud | Atlassian Documentation.

In vielen Fällen können Sie Änderungen aber auch einfach mithilfe von Storys auf einem Kanban-Board betrachten und verfolgen. Dann lassen sie sich nach Genehmigung schnell in die Umsetzung bringen.

Ein Kanban-Board lässt sich von Projektadministratoren so konfigurieren, dass es nur gewünschte Inhalte anzeigt – wie zum Beispiel alle Change Requests.

Grundsätzlich bietet Jira die Möglichkeit, bei einem „Resolved“- oder „Closed“-Zustand mit einem „Fixed“ oder „Won’t Do“ im Resolution-Feld die getroffene Entscheidung für oder gegen die Umsetzung eines Änderungswunsches transparent zu machen. Voraussetzung dafür ist, dass das „Resolution“-Feld im Projekt von der Jira-Administration als bearbeitbar konfiguriert wurde.

Issue-Management

Issue-Management ist die Kernaufgabe von Jira als Software-Tool. Es bietet hierfür sehr viele Möglichkeiten zur Konfiguration und auch Vorlagen. Mittlerweile können Teams ihre Projekte in Jira Cloud sogar auch weitergehend selbst konfigurieren.

Unser Tipp: Sehen Sie hier die Unterschiede zwischen unternehmens- und teamverwalteten Projekten.

Projektstatusberichte

Eine Projektübersicht lässt sich gut mit Jira-Dashboards erstellen. Für ausführlichere Statusdokumentation finden sich in Confluence Vorlagen:

Unser Seminar-Tipp: Sie suchen mehr Jira-Tipps für Einsteiger:innen, Fortgeschrittene oder für Projekteinrichtende? Dann lernen Sie mehr und stellen Sie Ihre Fragen in den drei Online-Modulen der Atlassian Jira Schulungen von TPG.

Ist-Stundenerfassung und Ressourcenplanung im Projekt und im Team

Für die Erfassung von Ist-Zeiten und die Ressourcenplanung mit Jira bietet das Tool einige Möglichkeiten, die nicht sehr bekannt sind. Dazu gehören Zeiterfassungsfunktionen in Issues sowie Auswertungen.

Das „Time tracking“-Feld in Jira-Issues dient zur Erfassung von Plan- und Ist-Bearbeitungszeiten. Wenn diese regelmäßig und gut gepflegt sind, lassen sich Berichte über Zeiterfassungen und Arbeitslast erstellen (siehe folgende Screenshots).

Wenn Ihnen diese Funktionen nicht ausreichen, können Sie mit „Tempo Planner“ (lizenzpflichtig) für Jira eine der meistverbreiteten Apps des Atlassian Marketplace nutzen. Damit erhalten Sie noch deutlich mehr Funktionalitäten für Ihre Ressourcenplanung.

Was Jira mit Bordmitteln nicht kann, ist die projektübergreifende Ressourcen-Einplanung für eine Harmonisierung der Ressourcensituation in Projekten und Linie. Mit der App „Tempo Capacity Planner“, ebenfalls aus der Tempo-Suite, ist dies möglich.

Beispiele wie das folgende finden Sie unter Tempo Capacity Planner | Atlassian Marketplace.

Eine weitere Möglichkeit ist die Integration von Jira mit Microsoft Project (mehr dazu in Tipp 3).

Unser Tool-Tipp: Wollen Sie Ihre PMO-Ressourcen übersichtlich und gut verwalten oder die Ressourcenabstimmung zwischen Projekt und Linie optimal unterstützen? Dann sehen Sie sich die TPG CoReSuite TeamManager App als Tool zur Ressourcenplanung an.

Tipp 2: Jira-Dashboards und Roadmaps für bessere Übersicht

In Jira-Projekten können Sie Reports erstellen. Außerdem bietet Jira die Möglichkeit, unter Dashboards auch projektübergreifend eigene Statistiken und Übersichten zu kreieren.

Reports in Jira lassen sich nur für ein bestimmtes Projekt erzeugen. Über die Projektseitenleiste gelangen Sie mit dem Punkt „Reports“ zu einer Vielzahl an Berichten. Solange die Daten in Ihren Projekten vorhanden und gut gepflegt sind, können diese bereits sehr aussagekräftig sein.

Noch mehr Möglichkeiten bieten Jira-Dashboards: Mit ihnen können Sie für Ihr Projektmanagement in Jira ähnliche Daten aus einem oder mehreren Jira-Projekten aggregieren und stets aktuell in einer von Ihnen gewählten Auswahl und Anordnung darstellen. Dabei haben Sie mehr Einstellungsmöglichkeiten als mit reinen Projekt-Reports. Dashboards können Sie außerdem mit anderen Usern teilen.

Passender Lesetipp: PMO-Reporting: Berichte für Projekt-, Portfolio- und Ressourcenmanagement

Jira-Dashboards bestehen aus sogenannten „Gadgets“, die Daten in bestimmter Form darstellen (ähnlich wie in Reports), aber konfigurierbar sind. Die folgenden Dashboard-Gadgets können Ihnen dabei besonders hilfreich sein:

• Projects: Eine einfache Liste aller Projekte in Jira, auf die User Zugriff haben, die das Dashboard betrachten. Ein Klick auf den Projektnamen bringt sie direkt in das Projekt in Jira.
• Created vs. Resolved: Zeigt in einer Übersicht, wie viele Issues in einem gewählten Projekt neu eröffnet wurden und wie viele fertiggestellt wurden. Auch dieses Gadget lässt sich über einen entsprechenden Filter, der mehrere Projekte umfasst, für mehr als ein Projekt einrichten. Das folgende Beispiel zeigt simulierte Daten aus der TPG-Trainingsinstanz. In aktiv und länger genutzten Produktivprojekten können Sie die Ergebnisse noch deutlich granularer darstellen. Sie können besonders dann hilfreich sein, wenn es um die Nachvollziehbarkeit der Effektivität von Fehlerbehebung in einem Produkt geht:

• Wenn Sie in einem PMO für agile Teams arbeiten, dann könnte das „Sprint Health“-Gadget interessant für Sie sein. Zwar kümmern sich selbstverwaltende Scrum-Teams selbst um die „Gesundheit“ ihrer Sprints, aber das PMO kann damit auf lange Sicht Entwicklungen nachverfolgen und den Teams bei Bedarf Unterstützung anbieten.

• Jira Road Map: Dieses Gadget zeigt Ihnen an, welche Versionen der Software-Projekte (im Gadget ausgewählte oder „alle Projekte“) geplant sind und wie die Arbeit an diesen Versionen voranschreitet.

Das „Jira Road Map“-Gadget gehört zur Roadmap-Funktionalität in Jira. Diese ist in der Standard-Jira-Lizenz ein einfaches, manuell anpassbares Schwimmbahnen-Diagramm für die Zeitplanung mithilfe von Epics und den darin enthaltenen Issues. Der folgende Screenshot zeigt eine einfache Epic- und Issue-Planung in Basic Roadmaps mit teilweise manuell anpassbaren Zeitplanungen.

Richtig interessant für PMOs wird Jira Road Map mit der Advanced Road Map, die in Premium- und Enterprise-Lizenzen enthalten ist. Diese kann unter anderem auch Abhängigkeiten zwischen Issues feingranular darstellen und somit einen guten Überblick über den Stand der Arbeit in einem oder mehreren Projekten liefern.

Beim Projektmanagement mit Jira können sich PMOs also grundsätzlich einen Überblick über den Arbeitsstatus in Projekten verschaffen. Allerdings gibt es hier auch Grenzen, wie bereits anfangs erwähnt:

Bitte beachten: Komplettübersichten mit allen für das übergeordnete Projekt- und Portfoliomanagement relevanten Daten bietet Jira auch mithilfe von Dashboards oder Roadmap kaum. Das bedeutet, Jira kann ein ausschließlich für das Projekt- und Portfoliomanagement optimiertes PPM-Tool nicht ersetzen.

Apps aus dem Atlassian Marketplace für diesen Zweck (z.B. die erwähnte Tempo-Suite, aber auch Big Picture oder Structure) bereichern Jira hier zwar um einige wichtige Aspekte. Selbst dann können die Lösungen aber mit vollumfänglicher Projektmanagement-Software nicht mithalten.

Um zu einer solch „paradiesischen“ Situation für PMOs zu kommen, hilft Ihnen eine integrierte Umgebung für Multi-Projektmanagement, wie Sie sie im Tipp 3 jetzt kennenlernen.

Im folgenden eBook wird „The PPM Paradise“ dargestellt, eine optimale PPM-Umgebung für das moderne Unternehmensumfeld – unabhängig von der gewählten Technologie. Im eBook finden Sie den Nutzen und viele gute Argumente, die Sie als PMO oder Tool-verantwortliche Stelle Ihren Entscheidern gegenüber verwenden können. Jetzt gleich herunterladen.

eBook Download (PDF): „The PPRM Paradise“ - so geht modernes Projekt-, Portfolio & Ressourcenmanagement wirklich problemlos (ein Konzept)

Das sollte eine optimale, moderne und anpassbare Lösung für Projekt-, Portfolio- und Ressourcenmanagement (PPRM) können – Tipps, Nutzen und wichtige Argumente für Ihre Entscheider.

Tipp 3: Einfacher arbeiten durch Integration von Jira mit Microsoft Project

Mit der Integration Middleware TPG PSLink können Sie Microsoft Project und Atlassian Jira für Projektmanagement miteinander verbinden. So lassen sich Daten zwischen beiden Anwendungen synchronisieren. Dies bietet sich besonders auf der Ebene von Phasen / Versionen sowie Arbeitspaketen / Epics an:

Zurück in MS Project lassen sich Arbeitsstatus der Issues, Schätzungen etwa in Story Points und die Ist-Werte übertragen (mehr dazu in unserem Blogartikel „Integration MS Project mit Jira oder TFS / DevOps (3 Anwendungsfälle)“):

Sobald diese Daten zwischen den beiden Tools synchronisiert wurden, können Sie die Möglichkeiten von Microsoft Project zur Berichterstattung bequem auf Basis aktueller operativer Daten nutzen. Die Teammitglieder des Projekts müssen bei dieser integrierten Lösung keine zwei Tools parallel pflegen. Das erhöht die Akzeptanz und Datenqualität.

Hinweis: Alles Wichtige zum Project Online Ende 2026 mit Migrationsoptionen

Eine Alternative: PPM auf Microsoft 365 und der Power Platform

Microsoft bietet mit dem Planner mittlerweile auch eine immer leistungsfähigere Software für Aufgaben und Projektmanagement auf Basis von M365 / Power Platform an. Der Planner umfasst neben Aufgabenmanagement mittlerweile auch die Funktionalität des früheren Project for the Web (die Umstellung erfolgt im August 2025).

Zudem lässt sich Planner mit der richtigen Software für leistungsfähiges Multiprojektmanagement sehr gut erweitern.

Wenn Sie ohnehin Microsoft 365 im Unternehmen haben, dann wäre das Software-Produkt TPG ProjectPowerPack vielleicht eine gute PPM-Alternative zu Jira – mit mehr Unterstützung im Projekt-, Portfolio- und Ressourcenmanagement. Es nutzt den Planner (ehem. Project for the Web) und erweitert dessen Funktionen um bewährte Best-Practice-Methoden. Jira lässt sich zudem integrieren und kann so Daten mit der Microsoft-Welt austauschen.

Ihre Vorteile mit TPG ProjectPowerPack:

• Zentrale, konsolidierte Datenhaltung für alle Projekte
• Workflows für Projektlebenszyklus, Risiken, Probleme etc.
• Funktionen für PMOs, Projektmanager und Führungskräfte
• Leistungsstarkes Reporting mit Power BI – out of the box
• Schnell einführbar durch vorkonfigurierte Best-Practice-Prozesse (TPG QuickStart)
• Einfach erweiterbar durch Konfiguration und Low-Code-Anpassung in der Power Platform

Fazit – Jira im Projektmanagement für PMOs nutzbar, mit Grenzen

In diesem Artikel haben Sie gelernt, wie Sie Jira im Projektmanagement bei den verschiedenen PMO-Aufgaben mal mehr und mal weniger unterstützen kann. Als beliebtes Tool für Aufgabenmanagement hat Jira im PMO-Umfeld aber, trotz der vielen erhältlichen Apps, seine Grenzen.

Besonders wenn es um die Darstellung von Projektübersichten und -portfolios geht, kann Jira nicht mit den genau für solche Zwecke gedachten PPM-Tools mithalten. Ideal ist allerdings die Kombination aus PPM- und Aufgabenmanagement-Tools durch eine Integration. Damit lassen sich die Daten zwischen beiden Welten austauschen und sind immer synchron bzw. aktuell. Auch arbeiten die Projektmanager und Teammitglieder mit den für sie gewohnten Tools. Das erhöht die Akzeptanz und Qualität der Daten – wichtig für fundierte und schnelle Entscheidungen im Projektverlauf.

Die Blog-Reihe „Jira für Rollen im Projektmanagement“

Dieser Artikel zu Jira und Confluence ist Teil einer Reihe, in der wir die Möglichkeiten der Tools für verschiedene Rollen beschreiben. Hier die Übersicht:

• Teil 1: Jira für das PMO (dieser Artikel)
• Teil 2: Jira für Scrum Master
• Teil 3: Jira für Product Owner
• Teil 4: Jira für Developer
• Teil 5: Jira Tipps zu Filtern, Dashboard und Berichten

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei der TPG Jira Schulung (für Einsteiger, Fortgeschrittene und Experts).

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

FALSE

---

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.

Der Beitrag Jira als PMO-Tool – 3 Tipps, wie Jira im Projektmanagement das PMO unterstützen kann erschien zuerst auf TPG Projektmanagement Blog für Profis.

In diesem Artikel stellen wir Ihnen die agile PMI-ACP® Zertifizierung vor, den „Agile Certified Practitioner“ des amerikanischen Project Management Instituts (PMI®). Dies ist eine Projektmanagement-Zertifizierung, die mittlerweile sehr an Beliebtheit gewonnen hat. Folgende Kapitel warten auf Sie:

• Für wen eignet sich die PMI-ACP Zertifizierung?
• Wie läuft die PMI-ACP Prüfung ab?
• PMI-ACP Vorbereitung auf die Prüfung
• Kosten der PMI-ACP Zertifizierung
• Unterschiede zu anderen agilen Projektmanagement-Zertifikaten
• PMI-ACP Prüfung: Welche Inhalte Sie kennen sollten
• Zusammenfassung – PMI-ACP Zertifizierung

Legen wir los!

Für wen eignet sich die PMI-ACP Zertifizierung?

Das PMI besteht seit 1969. Seit 1995 gibt es sein Flaggschiff-Zertifikat zum Project Management Professional – PMP® für erfahrene Projektleiter:innen, das weiterhin stark gefragt ist.

Gibt es auch eine „PMP agile“ Zertifizierung?

Nicht direkt, aber fast.

Das PMI hat einige Zertifizierungen für spezielle Bereiche. Hierzu gehört seit 2012 auch das jüngste Zertifikat zum „PMI Agile Certified Practitioner“ (PMI-ACP).

Und dieses boomt:

17.000 Zertifikatsinhaber waren es bereits 2017, also nach fünf Jahren (zum Vergleich: ca. 800.000 PMP-Zertifizierte zum gleichen Zeitpunkt).

Das PMI-ACP Zertifikat möchte all jenen einen möglichen Qualifikationsnachweis bieten, die bereits praktische Erfahrung vorweisen können:

• 8 Monate agile Projektarbeit innerhalb der letzten drei Jahre und
• 12 Monate allgemeine Projekterfahrung innerhalb der letzten fünf Jahre

Letztere entfällt übrigens für PMP-Zertifizierte, was den PMI-ACP zu einer interessanten Zusatzqualifikation für diese Personengruppe macht.

Merke: Das PMI-ACP Zertifikat bietet einen Qualifikationsnachweis für Projektleiter:innen, die bereits agil gearbeitet haben.

Als agile:r Praktiker:in können Sie in der Prüfung nachweisen, dass Sie:

• neben Scrum auch andere Methodenwerke, Ansätze und Ideen sowie deren Stärken und Schwächen und diverse Kombinationsmöglichkeiten kennen,
• mit agilen Prinzipien wie Selbstorganisation und Interdisziplinarität vertraut sind und
• situativ richtig auf beschriebene Problemstellungen reagieren können.

Bei der Prüfungsbewerbung müssen Sie außerdem 21 Kontaktstunden absolviertes Training in agilen Themen angeben. Diese Stunden können Sie erreichen entweder durch

• ein spezielles PMI-ACP-Training zur Prüfungsvorbereitung und / oder
• ein anderes agiles Projektmanagement Seminar

Im häufigsten Fall glaubt Ihnen das PMI Ihre Angaben ohne weitere Überprüfung. Wie bei allen seinen Prüfungen behält es sich allerdings vor, einen gewissen Anteil eingegangener Bewerbungen per Zufallsprinzip einem Audit zu unterziehen. Bei diesem Audit muss der oder die Betroffene die gemachten Angaben schriftlich bestätigen und nachweisen.

Wie läuft die PMI-ACP Prüfung ab?

Ablegen lässt sich der Test bei Prüfungszulassung entweder in einem Computer-Testzentrum des PMI-Partners Pearson Vue oder alternativ auch online – dann aber mit einer Überwachung durch einen so genannten „Proctor“ im Auftrag vom PMI per Webcam und einigen Dingen, die es dabei zu beachten gilt (bitte lesen Sie in jedem Fall das PMI-ACP Handbook genau durch). In beiden Fällen müssen die Prüflinge ihre Termine selbst vereinbaren, sobald sie durch das PMI zum Test zugelassen wurden.

Von diesen Zentren gibt es in Deutschland einige, so dass auch eines in Ihrer Nähe dabei sein sollte. Ansonsten lohnt sich für Bewohner von Grenzregionen eventuell auch ein Blick ins benachbarte Ausland.

In diesen Testzentren dürfen keine persönlichen Gegenstände in die Prüfungsräume mitgenommen werden, auch keine Getränke oder Essen. Lediglich einen Ausweis mit Foto brauchen Sie zum Nachweis, dass Sie tatsächlich der Prüfling selbst sind.

Sie haben die Möglichkeit, alles Persönliche in Schließfächern unterzubringen. Stellen Sie sich darauf ein, dass Sie auf unerlaubte Hilfsmittel durchsucht werden.

Die Prüfung dauert drei Stunden, in denen 120 Multiple-Choice-Fragen beantwortet werden müssen.

Die PMI-ACP Prüfung auf einen Blick

• Wo findet die Prüfung statt: Computer-Testzentrum des PMI-Partners Pearson Vue oder Online Proctored
• Wie melde ich mich an: Nach Zulassung erhalten Sie vom PMI per E-Mail Anweisungen mit Ihrem Berechtigungscode, den Sie benötigen, um Ihren Prüfungstermin in einem Prüfungszentrum oder online zu vereinbaren
• Was brauche ich vor Ort: Ausweis mit Lichtbild
• Was darf vor Ort nicht mit: persönliche Gegenstände, Getränke, Essen (Schließfächer vor Ort)
• Wie lange dauert die Prüfung: drei Stunden (120 Multiple-Choice-Fragen)

 

PMI-ACP Vorbereitung auf die Prüfung

Für die Vorbereitung zur PMI-ACP Prüfung sollten Sie in etwa drei bis vier Wochen einplanen. Zuvor sollten Sie an einem PMI-ACP Training teilnehmen, das als Voraussetzung auch die 21 Kontaktstunden gewährleistet und Ihnen wichtigen Lernstoff und Hinweise für die Prüfung gibt.

So könnte etwa der Ablauf Ihrer Prüfungsvorbereitung aussehen (Empfehlung):

Kosten der PMI-ACP Zertifizierung

In der folgenden Übersicht finden Sie die mit der Prüfung verbundenen Gebühren (Stand 1/2024):

Unterschiede zu anderen agilen Projektmanagement-Zertifikaten

Im Folgenden finden Sie eine kurze Übersicht beliebter agiler Zertifizierungen für den Vergleich.

Scrum Master Zertifikate

Zertifizierungen wie die folgenden drei zum

• „Certified Scrum Master“ der Scrum Alliance
• „Professional Scrum Master I“ der Scrum.org
• „Scrum Master Certified“ der ScrumStudy

richten sich primär an Personen, die das am weitesten verbreitete agile Methodenwerk „Scrum“ in der Rolle des Scrum Master möglichst richtig umsetzen wollen. Richtig heißt hier, entsprechend den Prinzipien aus dem Scrum Guide (Download aller Sprachversionen hier) und vor allem gemäß den Gedanken der beiden Begründer des Frameworks (Ken Schwaber und Jeff Sutherland).

Lesetipp: Projektmanagement-Zertifizierungen und -Gehalt – Vergleich der bekanntesten PM-Zertifikate

Wie unterscheidet sich die PMI-ACP Zertifizierung von Scrum?

Wichtige grundlegende agile Prinzipien wie Selbstorganisation und Interdisziplinarität kleiner, dedizierter Produktteams sind auch in Scrum bereits allgegenwärtig. Die Hintergründe dafür werden aber im Scrum Guide oder in den Prüfungen kaum genauer betrachtet oder situativ hinterfragt.

Projektmanagement-Theorie spielt außerdem in Scrum Prüfungen kaum eine Rolle. Die Inhalte bewegen sich größtenteils auf der Ebene von Produktentwicklungsteams incl. Product Owner und Scrum Master.

In diesen Scrum-Rollen gehen klassische Projektmanagement-Aufgaben zwar teilweise auf, werden jedoch kaum detailliert betrachtet. Zum Teil bleiben sie auch völlig unberührt, und Überlegungen dazu werden anderen überlassen. So hat sich zum Beispiel das PMI die Standardisierung von agilem Projektmanagement auf die Fahne geschrieben.

Dies gilt auch für andere Zertifikate im Scrum-Umfeld, die auf die anderen Rollen oder auf Skalierungsthemen zugeschnitten sind.

Andere agile Zertifikate

Derzeit gibt es auf dem Markt nur wenige Formate, die sich ähnlicher Verbreitung erfreuen wie die oben Genannten. Viele agile Ansätze kommen auch gänzlich ohne Zertifizierungen aus. Sie bestehen beispielsweise mehr aus Empfehlungen für Praktiken und Werte als aus relativ detaillierten Rollen- und Prozessbeschreibungen wie bei Scrum.

Einige Angebote seien an dieser Stelle erwähnt:

• GPM / IPMA Zusatzzertifikat „hybrid +“
• APMG Agile Project Management oder Agile Programme Management (apmg-international.com)
• International Consortium for Agile (icagile.com)

Die GPM bietet z.B. ihr „hybrid+“ als Zusatzqualifikation für Projektleitende an, die das Level-C-Zertifikat besitzen (Zulassungsvoraussetzung). Sie konzentriert sich besonders auf hybride Betrachtungen, also die Kombinationsmöglichkeiten klassischer und agiler Ansätze.

Lesetipp: Agile Projektmanagement-Zertifizierungen im Vergleich – wie sollten Sie vorgehen?

PMI-ACP Prüfung: Welche Inhalte Sie kennen sollten

Die PMI Agile Certified Practitioner Prüfung fragt zunächst wichtige agile Themen in fiktiven situativen Fragestellungen ab. Diese müssen Sie oft aus Sicht einer generell als „agiler Coach“ oder „agiler Praktiker“ bezeichneten Person beantworten.

Neben den bereits genannten Themen Selbstorganisation und Interdisziplinarität sind das zum Beispiel:

• die Umsetzung der Werte aus dem agilen Manifest
• Wertsteigerung für Kunden und Stakeholder
• agile Bedingungen in regulierten Umgebungen, Vertragswesen
• die räumliche Zusammenführung von Teams soweit möglich
• Servant-Leadership und agile Führungsmethoden auf Augenhöhe
• Werkzeuge für effektives Facilitating (Moderieren von Gruppenprozessen)
• Face-to-Face-Kommunikation
• Informationsaustausch auch über Team- und Firmengrenzen hinweg
• Problemlösungsstrategien und Fehleranalyse
• Kontinuierliche Verbesserung und Retrospektiven
• Arbeiten mit „Information Radiators“ und „Low Tech High Touch“-Werkzeugen

Wenn Ihnen der Begriffe „Information Radiators“ bzw. „Low Tech High Touch“ noch unbekannt sind: So werden in der agilen Welt Ansätze genannt, die oft in hochgradig komplexen Technologieumgebungen eingesetzt werden. Sie sorgen für zwischenmenschliche Interaktionen und arbeiten bewusst mit haptischen Werkzeugen, z.B. indem Planungen statt über Software mit Post-Its auf Wänden umgesetzt werden oder Teams bzw. ganze Firmen ihre aktuellen Projektneuigkeiten für alle gut sichtbar ausstellen.

Darüber hinaus testet die Prüfung Ihr Wissen zu Praktiken, Werkzeugen und Ideen aus verschiedensten agilen Methodenwerken. Dazu gehören neben Scrum auch

• der gedankliche „Urvater“ Lean Manufacturing und das daraus entstandene Kanban
• Extreme Programming (XP)
• Dynamic Systems Development Model (DSDM Atern)
• Test-Driven Development etc.

Hinweis: Hier finden Sie einen Überblick agiler Methoden

Abgefragt werden zudem auch Fragen zu Verbindungen verschiedener Methoden sowie generelle Betrachtungen zu hybriden Ansätzen und zum Zuschneiden von Prozessen auf Projektsituationen.

Zu guter Letzt sollten Sie sich als Anwärter:in auf das PMI-ACP Zertifikat auch auskennen mit:

• den Teambildungsprozessen und -theorien
• den Metriken zur Fortschrittsmessung und
• den „Buzzwords“, die im agilen Bereich allgegenwärtig sind.

Hintergrundwissen aus der PMP Vorbereitung und dem „Guide to the Project Management Body of Knowledge“ (PMBOK® Guide) des PMI ist durchaus hilfreich. Das hat zwei Gründe:

1. Die PMI Sicht auf die Welt des Projektmanagements ist damit bereits deutlich vertrauter, was bei der Beantwortung von Prüfungsfragen hilft
2. Einige Werkzeuge und Begriffe finden sich beim PMI-ACP wieder, zum Beispiel
   • IRR / ROI / BCR (Internal Rate of Return, Return on Investment, Benefit/Cost Ratio),
   • das Kano-Modell,
   • das Voice-of-the-Customer-Konzept aus dem Qualitätsmanagement,
   • Risikomanagement-Prozesse
   • oder sogar agiles Earned Value Management etc.

Wichtige Literatur für die PMI-ACP Prüfung

Zunächst sollten Sie sich als Prüfungskandidat:in für eine PMI Prüfung immer das zum Zertifikat gehörige Handbuch und den notwendigen Lehrplan zu den Prüfungsinhalten („Exam Content Outline“) besorgen. Dies können Sie kostenlos herunterladen.

Zusätzlich empfehlenswert: Der PMBOK® Guide in der aktuellen 7. Ausgabe (zumindest grobe Kenntnis empfohlen) als Bundle mit dem „Agile Practice Guide“. Der Download ist für PMI Mitglieder kostenlos.

Diese Kombination kommt nicht von ungefähr: Das PMI hat sich 2017 mit der Agile Alliance zusammengetan und dieses Dokument neu verfasst. Dies geschah, um den übergreifenden und methodenunabhängigen agilen Ideen einen gedanklichen Überbau und eine gewisse Struktur zu geben. Deshalb sollten PMI-ACP Aspirant:innen damit vertraut sein, wenn sie in die Prüfung gehen.

Weitere Literatur hat das PMI online unter den Zertifizierungsinfos zusammengestellt. Gegebenenfalls empfiehlt sich auch ein gutes Vorbereitungsbuch wie „PMI-ACP Exam Prep“ von Mike Griffiths, der als einer der Mitgestalter der Prüfung nah genug an der Quelle ist, um zu wissen, was besonders prüfungsrelevant ist. Das Studium dieses Buchs erspart Ihnen größtenteils, jedes einzelne Buch aus der Referenzliste des PMI erwerben und studieren zu müssen.

Zusammen mit einem guten PMI-ACP Vorbereitungsseminar haben Sie so einige sehr effektive Mittel für eine fundierte Vorbereitung in der Hand.

Sprachlichen Kenntnisse für die PMI-ACP Prüfung

Anders als beim PMP, wo eine deutsche Übersetzungshilfe bei der Bezahlung kostenlos zugebucht werden kann, besteht diese Möglichkeit beim PMI-ACP zumindest derzeit nicht.

Die Prüfung ist ausschließlich auf Englisch.

Ein sicheres Beherrschen englischer Alltags- und Geschäftssprache, agiler Terminologie sowie PMI spezifischer Ausdrücke ist für den Prüfungserfolg absolute Voraussetzung. Ein Vorbereitungsseminar für die PMI-ACP Zertifizierung kann hierbei sehr hilfreich sein. Aber dennoch sollten Sie ein gewisses Maß an Sprachsicherheit mitbringen.

Zusammenfassung – Die PMI-ACP Zertifizierung

Das Zertifikat zum „PMI Agile Certified Practitioner“ (PMI-ACP) ist ein Pluspunkt im Lebenslauf von Projektleiter:innen, die mit agilen Methoden bereits etwas vertraut sind. Dies gilt besonders, wenn Sie dieses Wissen auf ein stabiles theoretisches Fundament stellen wollen.

Diese agile Zertifizierung eignet sich sehr gut als Ergänzung zum „Project Management Professional“ (PMP) oder zu einer Scrum-Zertifizierung. Aber auch für sich alleine hat das Zertifikat schon viel Aussagekraft für Projektprofis im agilen Umfeld.

Mit der richtigen Vorbereitung und ausreichenden Englischkenntnissen haben Sie gute Chancen, einen agilen Qualifikationsnachweis zu erlangen, der sich branchenübergreifend stetig wachsender Bekanntheit und Beliebtheit erfreut.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für ein höheres Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig beim TPG PMI-ACP Training zur Prüfungsvorbereitung.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.

Der Beitrag PMI-ACP Zertifizierung: Was spricht für den PMI Agile Certified Practitioner und wie geht’s? erschien zuerst auf TPG Projektmanagement Blog für Profis.

Lesen Sie in diesem Artikel, wie das gelingen kann und erhalten Sie Tipps zur konkreten Umsetzung mit Links zu mehr Informationen. Sie erfahren in drei Teilen:

• Teil 1: Warum braucht es Skalierungs-Rahmenwerke wie SAFe?
• Teil 2: SAFe – Voraussetzungen, Aufbau, erste Schritte
• Teil 3: Unterschied SAFe zu anderen Skalierungs-Rahmenwerken
• Könnte SAFe der richtige Ansatz für Ihr Unternehmen sein?
• Zusammenfassung

Legen wir los mit der Definition von SAFe Scaled Agile Framework.

Definition SAFe Scaled Agile Framework

Die Abkürzung SAFe steht für „Scaled Agile Framework“. Es bietet ein Rahmenwerk für größere Unterfangen oder Unternehmen, die agiles Projektmanagement leben wollen und sich in einer agilen Transformation befinden. SAFe gehört aktuell zu den beliebtesten Skalierungslösungen und eignet sich auch für hybrides Projektmanagement.

Hinter SAFe steht die Organisation Scaled Agile Inc., die auch Zertifizierungen im Zusammenhang mit SAFe anbietet. Gegründet wurde sie von Dean Leffingwell. Er schrieb in seinem Buch „Agile Software Requirements“ bereits 2010, wie man agile Ansätze unternehmensweit skalieren kann.

Teil 1: Warum braucht es Skalierungs-Rahmenwerke wie SAFe?

In den letzten Jahrzehnten ist die Zahl der agil arbeitenden Teams stark angestiegen. Das gilt nicht nur für IT-Abteilungen, die lange eine Art Vorreiterstellung hatten. Jetzt sind auch immer mehr andere Bereiche in Organisationen betroffen.

Die Landschaft agiler Ideen wirkt dabei oft wie ein Flickenteppich: So vielseitig wie die verschiedenen Methodenwerke Scrum, Kanban oder Extreme Programming – XP u.a. sind, so unterschiedlich arbeiten auch die Teams bei der Umsetzung.

Die Vielfältigkeit der Vorgehensweisen macht es schwer, sich untereinander und mit Kunden abzustimmen. Außerdem werden häufig auf Teamebene bereits viele Veränderungen umgesetzt und gelebt, aber wenig davon dringt in der Unternehmenshierarchie weiter nach oben.

Zudem geben Leitfäden (z.B. der Scrum Guide) keine Auskunft, wie bei Projekten mit mehr als einem Umsetzungsteam von drei bis neun Leuten vorzugehen ist. Ganz zu schweigen von untereinander abhängigen, parallellaufenden Projekten.

Dies liegt daran, dass der Scrum Guide versucht, Antworten auf eine ganz bestimmte Fragestellung zu geben: Welche Prozesse eignen sich für agile Arbeitsweisen?

Andere Fragen, wie etwa „welche gedanklichen Einstellungen müssen dahinterstehen?“ oder „welche Techniken wenden wir an, um hohe Qualität der Ergebnisse sicherzustellen?“ bleiben weitestgehend unangesprochen.

Skalierungs-Frameworks wie SAFe bieten hier einen Ansatz, methodische Lücken zu schließen: Sie vereinheitlichen die unternehmensweite Einführung agiler Ideen und Methoden auf eine Weise, die ein systematisches Vorgehen erleichtert.

Auch wenn inzwischen die Auswahl der Skalierungs-Ansätze selbst etwas unübersichtlich wird, ist SAFe das derzeit beliebteste und am meisten verbreitete Skalierungs-Rahmenwerk.

Auf einen Blick: Was unterscheidet Scrum von SAFe?

Warum die Umsetzung agiler Methodenwerke oft scheitert

In einzelnen Teams agile Arbeitsweisen einzuführen, das kann bereits ein Umdenken bewirken. So können Sie vor allem auf Einzelteam- bzw. Einzelprojektebene Erfolge erzielen. Und Prozesse, Innovationen oder die Beteiligung von Teams und Stakeholdern lassen sich bereits deutlich beweglicher gestalten – sofern es Ihr Umfeld erlaubt.

Aber: Die große Herausforderung ist, dass Pionierteams intern und bei der Zusammenarbeit mit anderen Firmen schnell auf Hindernisse stoßen.

Diese Hindernisse liegen oft an unterschiedlichen Auffassungen, dem „Mindset“.

Versucht ein neues Scrum Team sich im Projekt an die agilen Prozesse, Rollen und Arbeitsweisen zu halten, gibt es häufig folgende Reibungspunkte:

1. Fehlendes methodische Verständnis: Internen Stakeholdern, Kunden oder Nutzer:innen des entwickelten Produkts ist oft nicht oder nicht ausreichend bewusst, was das Scrum Team tut und warum.
   Beispiel: Ein Kunde soll zu Ende jedes Sprints zum Review-Meeting Feedback zum bis dato entwickelten Produkt abgeben. Er kann dies aber kaum bis gar nicht einrichten. Oder: Ein Scrum-Team braucht eine Person mit speziellen Entwicklungskenntnissen in Vollzeit, um Deadlines einhalten zu können. Diese Person wird aber auch von anderen dringend gebraucht.
2. Ungeeignete Verträge: Kundenaufträge sind nicht auf Bedürfnisse von Scrum Teams zugeschnitten.
   Beispiel: Manche Vertragsmodelle für agile Projekte sehen eine Teilung nicht verbrauchten Rest-Budgets nach Projektbeendigung vor. Dies soll die Kostenrisiken fairer aufteilen und für ein konstruktives Streben nach gemeinsamen Zielen sorgen. Budgetplanungs-Prozesse in vielen großen Unternehmen geben eine solche Freiheit allerdings gar nicht her. Daher sind solche Vertragsklauseln nicht umsetzbar.
3. Ungeeignete Unternehmensorganisation: Viele Firmen sind nach wie vor stark in Silos organisiert.
   Beispiel: Ein Scrum Team möchte möglichst abteilungsübergreifend an einer neuen Lösung arbeiten. Kolleg:innen in diesen Abteilungen sind eine solche Art der Zusammenarbeit aber nicht gewohnt. Und es fehlen auch die räumlichen Möglichkeiten, sich kollaborativ auszutauschen.
4. Klassische strategische Ausrichtung: Firmen, die in Projekten zusammenarbeiten, haben manchmal völlig unterschiedliche Vorstellungen von Agilität und auch verschiedene Reifegrade.
   Beispiel: Ein Dienstleister für Softwareentwicklung hat viel Erfahrung in agilen Methoden und möchte mit dem Kunden für ein neues Projekt zunächst eine Produktvision mithilfe von neuen Methoden wie Lego Workshops entwickeln. Der Kunde reagiert irritiert und ist zögerlich in der Bereitschaft, an einem solchen Workshop überhaupt teilzunehmen. Er zieht es vor, schwer verständliche Use Cases per E-Mail zu schicken.
5. Projekt- statt Produktorientierung: Die Produktorientierung, die agile Teams für ihre Motivation und zielgerichtete Arbeit brauchen, ist vielen Firmen noch völlig fremd.
   Beispiel: Ein Scrum Team plant seine Sprints so, dass jeder im Team die selbst gesetzten Ziele im Sprint kennt. Vorgesetzte des Product Owners haben jedoch andere Vorstellungen davon, woran die Leute im Team genau jetzt arbeiten sollten – Sie „funken“ mit abweichenden Anforderungen dazwischen. Da der Product Owner um seinen Job fürchtet, wenn er sich nicht an die Anweisungen hält, gibt er diese ungefiltert weiter. In der Folge sinkt die Motivation des Teams bezüglich der eigenen Planung von Sprint zu Sprint – da dies sowieso nicht haltbar sein wird.

Diese Liste ließe sich weiter fortsetzen. Die Szenarien aus den Beispielen sind so alle bereits vorgekommen und ereignen sich häufig.

Wie können Skalierungs-Frameworks hier helfen?

Im Prinzip geht es darum, bei allen Beteiligten ein „agiles Bewusstsein“ zu schaffen:

• Führungskräfte eines Unternehmens verschreiben sich bestimmten Werten des agilen Mindsets. Damit können einzelne Teams und am Ende die ganze Organisation erfolgreicher sein.
• ALLE Projektbeteiligten und Stakeholder leben diese Einstellung täglich bei ihrer Arbeit – das gilt auch für Kundenfirmen und Dienstleister.
• Teams innerhalb der Organisation ziehen alle am gleichen Strang, anstatt bei der Zusammenarbeit in Konkurrenz zu treten.
• Bei weltweit verteilten Standorten gibt es eine gemeinsame und durchdachte Strategie.

SAFe bietet viele Ansätze, wie ein wichtiges und großes Vorhaben gelingen kann. Es ist damit aber – wie andere Skalierungs-Frameworks auch – nicht als Blaupause zu verstehen.

Teil 2: SAFe – Voraussetzungen, Aufbau und erste Schritte

Wichtige Voraussetzung für SAFe

SAFe liefert konkrete Vorschläge, wie Sie mit der hohen Komplexität bei Prozessskalierungen umgehen. Dabei ist wichtig zu wissen, dass die Umsetzung Zeit sowie eventuell Schulungen erfordert.

Tipp: Greifen Sie zu Beginn Ihres Weges in die Agilität Ihrer Organisation auf jeden Fall auf Menschen mit Erfahrung und Kenntnissen in Scrum und skalierenden Ansätzen zurück.

Der „State of Agile“-Bericht nennt bei der Einführung von Skalierungs-Frameworks die folgenden fünf Top-Erfolgsfaktoren:

Wie ist SAFe aufgebaut?

SAFe basiert auf neun Prinzipien, angelehnt an Ideen und Prinzipien aus dem Agilen Manifest. Der wesentliche Unterschied zu den klassischen Richtlinien liegt im Aufbau der einzelnen Rollen und Ebenen pro Ausbaustufe (Anforderungen an Projekt- bzw. Teamgröße / Anzahl der Teams).

Die Ausbaustufen von SAFe

Möchten Sie SAFe als Rahmenwerk einführen, sollten Sie sich zunächst zwei Dimensionen bewusst machen:

• Wie stufen wir unsere Vorhaben im Hinblick auf Komplexität und Größe ein? Hier können Sie die untenstehende Tabelle zu Rate ziehen. Das „Essential SAFe Toolkit“ bietet weitere Anhaltspunkte zur Selbsteinordnung. Auch erfahrene SAFe Berater:innen können dabei helfen. Bei Unsicherheit gilt: lieber erst einmal die Umsetzung der Prinzipien in der einfachsten Stufe ausprobieren, bevor ein Ansatz konzernweit ausgefahren wird.
• Welche Ebenen sollen einbezogen werden? Geht es uns mehr um die Einzelteam- und Programmebene? Oder betrachten wir unsere Arbeitsweisen gleich auf Portfolioebene? Oder gar für einen ganzen Großkonzern (Large Solution und bei international agierenden auch Full SAFe)?

SAFe bietet je nachdem, wie Sie diese Frage für Ihre Situation beantworten, verschiedene Ausbaustufen hinsichtlich Projektkomplexität und -größe.

Tipp: Einen guten Überblick erhalten Sie mithilfe der Grafik auf scaledagileframework.com – klicken Sie dort auf die einzelnen Reiter, um das Diagramm für jede der Stufen zu sehen.

Zum besseren Verständnis gehen wir folgend näher auf die Ausbaustufen, einbezogenen Ebenen und Rollen in SAFe ein.

Die SAFe-Stufen im Einzelnen

Die Ebenen im Einzelnen

Je umfangreicher die Skalierung und je komplexer die Anforderungen, desto mehr Ebenen sollten Sie zur Erledigung der Aufgaben pro Stufe einbeziehen:

• Teamebene: SAFe nutzt das normale Scrum Team Setup und wandelt dies ein wenig ab. Pro Team kümmern sich fünf bis neun (statt in Scrum drei bis neun) Developer um die Umsetzung. Sie werden begleitet von einem Product Owner und einem Scrum Master für je circa 1-2 Umsetzungsteams. Außerdem arbeitet der PO dem übergeordneten Produktmanagement auf Programmebene zu. Die Teams arbeiten dabei funktionsübergreifend und weitestgehend selbstorganisiert.
• Programmebene: In SAFe arbeiten bis zu 10 Teams als sogenannte „Agile Release Trains“ für ein Programm zusammen. Produktmanager:innen sammeln und managen die Anforderungen, Product Owner brechen diese auf Teamebene umsetzungsnah herunter. So werden Programm- und Teamebene zusammengebracht. Eine Rolle „Release Train Engineer“ kümmert sich ab Ausbaustufe 2 um Abhängigkeiten und Integrationsaspekte.
• Portfolioebene: Auf dieser Ebene erfolgt die strategische Sicht auf Produktentwicklung, Budgetzuordnung und Abgleich mit Unternehmenszielen.
• Large-Solution-Ebene: Die allergrößten Projekte der Produktentwicklung erhalten mit dieser Ebene einen eigenen „Release Train“ zur Kontrolle des Wertstroms. So will SAFe den Anforderungen besonders großer und komplexer Programme gerechter werden.

Die SAFe-Rollen im Einzelnen

Die Rollen in SAFe sind auf Ebene 1 zunächst die normalen Scrum Teamrollen. Ab Ausbaustufe 2 gibt es zusätzlich folgende Rollen (ähnlich typischen Strukturen in klassischen Unternehmen):

• Ein Product Manager verantwortet das übergeordnete Product Backlog, das dann Program Backlog heißt
• Ein System Architect ist für die Systemgestaltung zuständig
• Ein Release Train Engineer kümmert sich als eine Art teamübergreifender Scrum Master für die Zusammenarbeit und Abhängigkeiten zwischen Teams
• Ein Business Owner behält den Blick auf ROI und Wertmaximierung sowie der Ausbalancierung von Kosten und Nutzen in der Produktentwicklung auf Systemebene; somit entlastet er den Product Manager etwas in dieser Hinsicht
• Natürlich darf auch der Kunde nicht zu kurz kommen – das ist der wichtigste Stakeholder.

Auf den Ebenen 3 und 4 kommen weitere Rollen hinzu, um der steigenden Komplexität gerecht zu werden.

Tipp: Die einzelnen Komponenten von SAFe sollten Sie vor Einführung auf ihre Sinnhaftigkeit in der gegebenen Umgebung prüfen. Genau dies ist die Motivation hinter Rahmenwerken, wie auch Scrum eines ist: einen Rahmen vorzugeben, innerhalb dessen sich Details situationsangepasst gestalten lassen.

Teil 3: Unterschied SAFe zu anderen Skalierungs-Rahmenwerken

Natürlich gibt es neben SAFe eine ganze Reihe Wettbewerber, die jeweils unterschiedliche Schwerpunkte haben. Der folgende Vergleich zeigt die wesentlichen Unterschiede:

Tipp: Die Frameworks in dieser Liste können zur Orientierung und Inspiration dienen; eine Umsetzung sollte aber immer mit Augenmaß dank entsprechender Erfahrung oder Beratung erfolgen. Auch unternehmensweite Ziele sollten Sie zunächst ausarbeiten und kommunizieren, damit sich keiner der Betroffenen überrumpelt fühlt.

Wie eingangs erwähnt nutzen die meisten Unternehmen das SAFe Framework als Inspirationsquelle für mehr Agilität in der Organisation. Warum ist das so?

Die Vorteile von SAFe

SAFe trägt aktiv zu einem agileren Mindset bei. So wichtig eine agile Transformation ist – mit dem Ansatz „Holzhammer-Methode“ wird sie vermutlich scheitern. Dies gilt gerade in großen, gewachsenen Unternehmen, die nicht mit kleineren Start-ups zu vergleichen sind.

Deshalb versuchen sie sich lieber an hybriden Ansätzen, als große Veränderungen zu wagen und dabei an mangelnder Akzeptanz zu scheitern.

So weit, so gut.

Kritikpunkte an SAFe

Befürworter:innen klassischer agiler Methoden sehen SAFe nur als pseudoagiles Rahmenwerk. Zu den häufigen Kritikpunkten zählen:

• SAFe ist nicht agil genug
• Überholte Managementpraktiken bleiben bestehen
• Die Einführung zusätzlicher Ebenen widerspricht dem agilen Prinzip flacherer Hierarchien
• Andere Skalierungsansätze, wie etwa LeSS, sind schlanker gestaltet und näher an agilen Grundprinzipien.

Dennoch: Für viele Unternehmen ist es schwierig, einen Wandel ohne Übergänge zu gestalten. SAFe liefert hier den passenden Zwischenschritt:

• für das hybride Vakuum zwischen traditionellen und komplexen Organisationsstrukturen auf der einen, und
• möglichst agiler Selbstorganisation sowie leichtgewichtigen Prozesse auf der anderen Seite

Tipp: Es gibt kein klar definiertes Einsatzszenario, das für oder gegen eine Einführung von SAFe als agiles Rahmenwerk spricht. Hier wird kontrovers diskutiert. Da SAFe aber sehr detaillierte Vorgaben zur Strategie und Umsetzung liefert, gilt pinzipiell die Empfehlung: Je niedriger der agile Reifegrad der Organisation, desto geeigneter ist SAFe als Veränderungsansatz „Schritt für Schritt“.

Weitere Orientierungshilfe für die Methodenauswahl finden Sie hier: Die bekanntesten Skalierungsansätze im Überblick.

Könnte SAFe der richtige Ansatz für Ihr Unternehmen sein?

Wir empfehlen folgende erste Schritte zur Evaluierung bzw. Einführung nach dem SAFe Rahmenwerk:

• Sammeln Sie Argumente für eine Skalierung (z.B. unsere Projekte sind zu groß für kleine agile Einzelteams und wir wollen eine einheitliche Vorgehensweise)
• Holen Sie die relevanten Stakeholder an Bord, insbesondere auf den wichtigen Entscheidungsebenen
• Prüfen Sie das agile Mindset in der Firma und bei anderen Projektbeteiligten
• Finden Sie interne Experten / Expertinnen und / oder beauftragen Sie externe Berater:innen
• Stimmen Sie das weitere Vorgehen immer mit dem Management ab

Tipp: Ganz wesentliche Faktoren für eine erfolgreiche Einführung eines agilen Umfeldes: Sorgen Sie für die enge Kommunikation intern wie extern (mit Kunden- und Partnerfirmen) und richten Sie ein cleveres Change Management ein.

Zusammenfassung – SAFe Scalable Agile Framework

Sie haben in diesem Artikel gelernt, dass Sie mit dem Skalierungsmodell SAFe mehr Agilität in die Organisation und Prozesse Ihres Unternehmens bringen können.

Sie haben erfahren:

• Warum die Nachfrage nach Skalierungsansätzen wie SAFe so groß ist
• Wie sich SAFe von agilen Methoden unterscheidet
• Welche alternativen Ansätze existieren
• Was Sie beachten sollten, wenn Sie SAFe einführen möchten
• Wie SAFe aufgebaut ist und
• Welche Schritte Sie gehen können, um SAFe in Ihr Unternehmen zu bringen.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifegrad Ihres Projektmanagements!

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin.

Der Beitrag Scaled Agile Framework (SAFe) – Erklärung des Rahmenwerks und wie Sie Ihre Organisation agiler gestalten erschien zuerst auf TPG Projektmanagement Blog für Profis.

In diesem Artikel erhalten Sie vier Tipps, wie Developer Jira und Confluence als Tools für die bessere Begleitung der Prozesse und die Zusammenarbeit im Team nutzen können – und was Sie unbedingt beachten sollten. Dieser Artikel ist Bestandteil unserer Blog-Reihe „Jira für Rollen im Projektmanagement“.

Diese Kapitel warten auf Sie:

• Welche Aufgaben von Developern können Jira und Confluence unterstützen? 
• Tipp 1: Personalisiertes Dashboard
• Tipp 2: Status eines Vorgangs aktualisieren
• Tipp 3: Labels, Versionen, Komponenten und Filter
• Tipp 4: Codes teilen mit dem Code-Block-Makro
• Fazit – Developer Jira und Confluence Tipps

Legen wir los mit einer kurzen Definition. 

Was ist ein Developer laut Scrum?

Als Developer werden in einem Scrum-Team (und auch in diesem Artikel) jene Teammitglieder bezeichnet, die aktiv an der Entwicklung eines Produkts beteiligt sind (aller Art, insbesondere Software), etwa als Entwickler:innen, Tester:innen oder Designer:innen.  

Welche Aufgaben von Developern können Jira und Confluence unterstützen?

Jira ist vor allem für Aufgabenmanagement gedacht. Es bildet die Realitäten verschiedener und insbesondere agil arbeitender Teams durch diverse Projekt- und Boardtypen ab. Somit kann es besonders Developern die Planung und Organisation ihrer Arbeit sowie den Austausch darüber erleichtern.

Durch die einfache Anbindung von Code-Plattformen wie Bitbucket, Github und weiteren Software-Entwicklungstools können die verschiedenen verwendeten Umgebungen integriert und Arbeitsabläufe automatisiert werden. Das kann die Effizienz von Software-Teams drastisch erhöhen.

Die wichtigste Voraussetzung dabei ist allerdings, dass die Teammitglieder eng in die Einrichtung und Abbildung der Prozesse eingebunden sind. Die Prozesse sollten möglichst leichtgewichtig gestaltet werden. Software wie Jira kann dann die Arbeit tatsächlich unterstützen und wird nicht als Belastung gesehen, weil der tägliche Aktualisierungsaufwand gering bleibt.

Damit Ihnen dies besser gelingt, finden Sie folgend einige wichtige Tipps, wie Developer Jira und Confluence in ihrem Umfeld gut zum Einsatz bringen können.

Tipp 1: Personalisiertes Dashboard

Wollen Sie als Teammitglied zu Arbeitsbeginn einen schnellen Überblick erhalten, welche Themen offen und als Nächstes abzuarbeiten sind? Solche Informationen aufzubereiten, ist eine der Stärken von Jira.

Mit eigenen Jira Dashboards können Teammitglieder selbst eine Übersicht zusammenstellen, die die Einführung einer täglichen Routine unterstützen. Die Zusammenstellung der Kästen (“Gadgets”) kann durch jeden Jira User in einem eigenen Dashboard selbst festgelegt werden. 

Auch das Teilen – und damit das Einrichten von Dashboards für ein Team oder auch einen festgelegten Personenkreis – ist in Jira möglich. 

Tipp 2: Status eines Vorgangs aktualisieren

Developer haben mit der Produktentwicklung meist alle Hände voll zu tun. Die Aktualisierung der Planung und des Arbeitsfortschritts sollte daher möglichst intuitiv und schnell geschehen können.

Aus dem Grunde ist es in Jira in den letzten Jahren immer einfacher geworden, solche Updates vorzunehmen: durch intuitivere Benutzerführung und Automatisierung – aber auch dadurch, dass besonders in Jira Cloud oft viele Wege zum Ziel führen.

So lässt sich der Status eines Issues (deutsches Jira: „Vorgang“), also eines Eintrags in einem Projekt, der als Planungsgrundlage für die Arbeit dient, auf mehreren Wegen aktualisieren. Diese geht über:

1. Issue-Schnellansicht
2. Issue-Vollbildansicht
3. einen verlinkten oder einen Parent Issue

Tipp 3: Labels, Versionen, Komponenten und Filter

In Jira dienen Labels, Versionen und Komponenten dazu, Projekte und Issues zu organisieren und zu kategorisieren.  

Labels können wie Schlagwörter betrachtet werden, mit denen Issues gekennzeichnet und gesucht werden können.  

Unser Tipp: Achtung! Labels können durch alle Nutzenden frei erstellt werden. Um Wildwuchs zu vermeiden, sollten Sie hier verpflichtende Vorgaben für alle Nutzenden definieren.

Versionen ermöglichen es, den Fortschritt von Projekten zu verfolgen und zu planen – durch die Verwaltung geplanter und tatsächlicher Releasedaten.  

Was Jira Releases angeht, haben die Information über sie eher informativen Charakter – außer wenn weitere Developer-Tools angebunden und Automatisierungen eingerichtet werden. Releases / Versionen decken eher die zeitlichen Aspekte der Planung ab. 

Jira Komponenten hingegen ermöglichen es Ihnen, Issues nach Funktionsbereich oder Modul zu gruppieren (etwa für ein zu entwickelndes Produkt).  

Hinweis: Jira Komponenten sind nur in unternehmensverwalteten Softwareprojekten verfügbar.

Diese Gruppierungsmöglichkeiten erleichtern die Zusammenarbeit im Team und machen es Ihnen dadurch einfacher, die Arbeit gemeinsam effektiver zu planen und zu verfolgen. 

Auch dienen sie als Basis für Suchfilter, die sich auf Ihre Arbeit zuschneiden lassen. Labels, Versionen und Komponenten sind filterbar. Die Filtersuche können Sie speichern sowie auf Dashboards abbilden. 

Tipp 4: Codes teilen mit dem Code-Block-Makro 

Ein weiteres interessantes Feature für Developer betrifft Confluence und dient dem Teilen von Code oder Script-Elementen: Mit dem „Code Block Makro“ können Sie die Sprache ihres Codes wählen und dann von der Funktion „Syntax Highlighting“ profitieren.  

Wie Sie den Code Block Schritt für Schritt hinzufügen: 

1. Wählen Sie das „+“ Symbol von der Symbolleiste und dann „Andere Makros“
2. Wählen Sie „Code Block“ in der „Formatting“-Kategorie
3. Wählen Sie die Sprache ihres Codes
4. Wählen Sie „Hinzufügen“
5. Tippen oder fügen Sie Ihren Code im Makro-Platzhalter ein 

Das Code Makro unterstützt viele Sprachen wie z.B. JS, C++, Java. 

Fazit: Developer Jira und Confluence Tipps

Jira lässt sich für die Zwecke von Scrum-Teams sinnvoll nutzen. Die Voraussetzung dafür ist, dass Developer das Tool nach gemeinsamen Standards und effizient einsetzen. Persönliche Dashboards, regelmäßige Aktualisierungen der Issues, richtige Labels, Komponenten und Filter helfen dabei.

Gegebenenfalls kann Sie dabei auch die Nutzung von Makros in Confluence unterstützen. Mit den oben dargestellten Tipps können Sie Ihre Arbeit als Teammitglied einfacher durchführen und auf Dauer erfolgreichere Ergebnisse erreichen. 

Die Blog-Reihe „Jira für Rollen im Projektmanagement“

Dieser Artikel zu Jira und Confluence ist Teil einer Reihe, in der wir die Möglichkeiten der Tools für verschiedene Rollen beschreiben. Hier die Übersicht:

• Teil 1: Jira für das PMO
• Teil 2: Jira für Scrum Master
• Teil 3: Jira für Product Owner
• Teil 4: Jira für Developer (dieser Artikel)
• Teil 5: Jira Tipps zu Filtern, Dashboard und Berichten

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei der TPG Jira Schulung (für Einsteiger, Fortgeschrittene und Experts).

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin.

Der Beitrag 4 Developer Jira und Confluence Tipps, durch die Sie in der Scrum-Umgebung leichter arbeiten erschien zuerst auf TPG Projektmanagement Blog für Profis.

Lernen Sie, wie Sie diese Tools für eine bessere Begleitung Ihrer Prozesse sowie für die Team-Fortschrittsmessung nutzen können. Dieser Artikel ist Bestandteil unserer Blog-Reihe „Jira für Rollen im Projektmanagement“.

Diese Kapitel warten auf Sie:

• Welche Aufgaben eines Scrum Masters können Jira und Confluence unterstützen?
• Tipp 1: Quickfilter für das Sprintboard einsetzen
• Tipp 2: Retrospektive mit Sprint-Report verknüpfen
• Tipp 3: Retrospektiven-Vorlage in Confluence und weitere Templates
• Fazit – Jira lässt sich für Scrum Team Zwecke sinnvoll einsetzen

Legen wir los mit zwei kurzen Definitionen.

Was ist Jira?

Atlassian Jira ist ein webbasiertes Tool für Aufgabenmanagement, Projektmanagement und Fehlerverwaltung. Es kommt hauptsächlich bei Teams in der Produkt- und Softwareentwicklung zum Einsatz. Teams, die im agilen Projektmanagement arbeiten, werden mittels verschiedener Projekt- und Boardtypen (z.B. Kanban, Scrum, Projektmanagement u.v.m.) unterstützt.

Was ist Confluence?

Atlassian Confluence ist eine webbasierte Wiki-Software, die die interne Zusammenarbeit in Projektteams und im Unternehmen unterstützt. Das Tool lässt sich hervorragend mit Jira integrieren und bietet in dieser Kombination beste Voraussetzungen für agil arbeitende Teams.

Welche Aufgaben eines Scrum Masters können Jira und Confluence unterstützen?

Jira ist vor allem für Aufgabenmanagement gedacht und bildet dabei die Realitäten verschiedener Teams durch diverse Projekt- und Boardtypen gut ab.

Für Scrum Teams gibt es in Jira unter den Softwareprojekten den Vorlagentyp „Scrum“.

Diesen Vorlagentyp zeichnet gegenüber beispielsweise Kanban Projekten aus, dass er eine Sprint-Funktionalität hat. Dies bedeutet, dass ein Sprintboard für Planung und Durchführung von Arbeit in getakteten Iterationen zur Verfügung steht.

In Scrum Teams kümmern sich Scrum Master insbesondere darum, die Prozesse und die Zusammenarbeit des Teams bestmöglich zu unterstützen. Sie helfen der Organisation dabei, Scrum besser zu verstehen und anzuwenden.

Als Scrum Master können Sie die Arbeit Ihres Scrum Teams mit den speziellen Funktionalitäten von Scrum Projekten in Jira und Confluence gut begleiten. Drei aus unserer Sicht sehr wichtige Tipps lesen Sie im folgenden Text.

Fangen wir mit dem Sprintboard an.

Tipp 1: Quickfilter für das Sprintboard einsetzen

Quickfilter befinden sich direkt über dem Board. Mit ihnen lassen sich die Issues filtern, die in Form von Karten auf dem Board angezeigt werden. Wenn beispielsweise ein Quickfilter für eine bestimmte zugewiesene Person (Assignee) aktiviert ist, sind auf dem Board nur diejenigen Issues zu sehen, welche gerade dieser Person zugewiesen sind.

Dies lässt sich gut als Moderationshilfe einsetzen: Gerade bei neuen Scrum Teams ist es häufig noch ein Scrum Master, der zumindest unterstützend durch das Daily Scrum Event führt. Das Daily Scrum dient als tägliche Zusammenkunft zur Überprüfung des Fortschritts im Hinblick auf das Sprintziel.

Wenn das Team das Daily so gestaltet, dass jedes Teammitglied den anderen zu seinen aktuellen Themen etwas erzählt (etwa zu Arbeitsfortschritt, Hindernissen, Erfolgen), können Sie als Scrum Master auf einem geteilten Bildschirm deren aktuelle Themen schnell für alle transparent machen. Nutzen Sie dazu die jeweilige Aktivierung des Quickfilters für die betreffende Person.

Unser Tipp: Springen Sie bei Ihren Daily Scrum Events auf diese Weise einmal reihum durch die Mitglieder Ihres Teams – und durch das Board mithilfe der Quickfilter, wie oben beschrieben.

Quickfilter für Assignees gibt es in Jira oft schon voreingestellt. Darüber hinaus können Sie auch für viele andere Faktoren selbst weitere Filter einrichten – Board-Konfigurationsrechte vorausgesetzt.

Quickfilter für Jira Boards basieren auf der so genannten „Jira Query Language“. Alles, was sich in Jira filtern lässt, können Sie auch als Boardfilter einsetzen, wie zum Beispiel verschiedene Prioritätsstufen.

Auf diese Weise können Sie als Scrum Master sicherstellen, dass in den Team-Meetings und Scrum Events die Themen auf dem Board angezeigt werden, auf die sich das Team gerade konzentrieren möchte.

Tipp 2: Retrospektive mit Sprint Report verknüpfen

Zu Ihrem Aufgabenfeld als Scrum Master kann auch gehören, möglichst produktive Retrospektiven zu gestalten. Zum Beispiel, indem Sie diese selbst moderieren. Oder indem Sie den anderen Scrum Teammitgliedern zeigen, wie sie selbst Retrospektiven abhalten können, die zu sinnvollen und nachhaltigen Verbesserungen von Prozess und Teamarbeit führen.

Die Arbeit von Scrum Teams wird in Jira durch Scrum-projektspezifische Auswertungen in Form von Reports unterstützt. Für Retrospektiven am Ende eines Sprints kann Ihnen der Sprint Report in Jira helfen, die Effektivität der erledigten Arbeit besser zu verstehen.

Wenn aktive Sprints in Jira beendet werden, zeigt die Software automatisch einen Sprint Report an:

Tipp 3: Retrospektiven-Vorlage in Confluence und weitere Templates

Damit Teams ihre Retrospektiven moderativ begleiten und ihre Erkenntnisse notieren können, gibt es einige verschiedene Vorlagen in Confluence. Wenn Sie eine neue Seite in Confluence mit der entsprechenden Vorlage anlegen möchten, können Sie beim Beenden eines Sprints dem Link aus Schritt 3 im vorherigen Tipp folgen – oder einfach in Confluence auf Vorlagen (engl. Templates) klicken.

In einigen Confluence Versionen gelangen Sie zu den Vorlagen über den Erstellen-Button (engl. Create). Wählen Sie hier die Vorlagen mit dem Namen „Retrospective“.

Neben Metadaten wie Seitentitel, Datum und Teilnehmende der Retrospektive können Sie bei der Bearbeitung von Retrospektiven-Seiten in Confluence auf Basis dieser Vorlage eingeben, was die Teilnehmerinnen und Teilnehmer im nun gerade zu Ende gehenden Sprint beobachtet haben und welche Verbesserungsvorschläge sie für den nächsten Sprint hätten.

Außerdem lassen sich Action Items zur konkreten Umsetzung dieser Verbesserungen festhalten und zuweisen. Diese werden dann allerdings in Confluence und nicht in Jira getrackt.

Alternativ können Sie auch Backlog-Einträge in Jira für die Umsetzung erstellen.

Eine weitere Retrospektivenvorlage, die Confluence bietet, ist die „4Ls“-Retrospektive: Sie unterscheidet sich von der vorherigen Vorlage vor allem durch das eingesetzte Diskussionsformat. Statt „Start Doing“, „Stop Doing“ und „Keep Doing“ gibt es hier vier Kategorien:

1. „Loved“ (dt. „geliebt“): Was fanden die Teammitglieder in diesem Sprint am allerbesten?
2. „Longed For“ (dt. „danach gesehnt“): Was hätten sie sich zudem gewünscht?
3. „Loathed“ (dt. „verachtet“): Was fanden sie ganz furchtbar?
4. „Learned“ (dt. „gelernt“): Was haben sie in diesem Sprint dazugelernt?

Außerdem können sie gemeinsam Meilensteine festhalten, deren Erreichung sie besonders wichtig finden, und die 4 Ls nach diesen gruppieren.

Fazit – Jira lässt sich für Scrum Team Zwecke sinnvoll einsetzen

Jira und Confluence lassen sich für die Zwecke eines Scrum Teams dann wirklich sinnvoll einsetzen, wenn Sie als Scrum Master wissen, was Ihnen diese Tools bieten.

In den oben vorgestellten drei Tipps haben Sie erfahren, wie Sie Ihr Scrum Team effektiver begleiten mit den richtigen Filtern im Sprint-Board Ihres Teams, Sprint Reports für eine gemeinsame Analyse des Sprintverlaufs und Retrospektiven-Vorlagen in Confluence zum Moderieren und Festhalten Ihrer Diskussionen und beschlossenen Verbesserungen.

Damit können Sie auf Dauer nachhaltigere positive Veränderungen in Ihrem agilen Projektumfeld bewirken.

Die Blog-Reihe „Jira für Rollen im Projektmanagement“

Dieser Artikel mit Scrum Master Jira / Confluence Tipps ist Teil einer Reihe, in der wir die Möglichkeiten der Tools für verschiedene Rollen beschreiben. Hier die Übersicht:

• Teil 1: Jira für das PMO
• Teil 2: Jira für Scrum Master (dieser Artikel)
• Teil 3: Jira für Product Owner
• Teil 4: Jira für Developer
• Teil 5: Jira Tipps zu Filtern, Dashboard und Berichten

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei der TPG Jira Schulung (für Einsteiger, Fortgeschrittene und Experts).

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin.

Der Beitrag 3 Scrum Master Jira / Confluence Tipps, durch die Sie leichter mit den Tools arbeiten erschien zuerst auf TPG Projektmanagement Blog für Profis.

• Aufgaben eines Product Owners
• Tipp 1: Stories schreiben, die nicht bleiben
• Tipp 2: Akzeptanzkriterien für gute Stories
• Tipp 3: Wenn es mal zu viel wird: Stories aufteilen
• Fazit – der Einsatz von Jira als Product Owner ist leicht, aber…

Doch bevor wir mit den Aufgaben und Tipps für den Product Owner starten ist es sinnvoll, einen Überblick über die verschiedenen Atlassian Tools zu haben. Klären wir also zunächst, worum es sich bei Jira und Confluence handelt.

Was ist Jira?

Atlassian Jira ist ein webbasiertes Tool für Aufgabenmanagement, Projektmanagement und Fehlerverwaltung. Es kommt hauptsächlich bei Teams in der Produkt- und Softwareentwicklung zum Einsatz. Agil arbeitende Teams werden mittels verschiedener Projekt- und Boardtypen unterstützt, z.B. Kanban, Scrum, Projektmanagement.

Was ist Confluence?

Atlassian Confluence ist eine webbasierte Wiki-Software, die die interne Zusammenarbeit in Projektteams und im Unternehmen unterstützt. Das Tool integriert sich gut mit Jira, daher bietet diese Kombination beste Voraussetzungen für agil arbeitende Teams.

Warum spezielle Jira Tipps für Product Owner?

Die Rolle des Product Owner wird mittlerweile in vielen Projekten eingesetzt – auch bei denen, die nicht auf dem Framework Scrum basieren, sondern lediglich Elemente daraus bedienen. Der Aufgabenbereich des Product Owner ist folglich von Unternehmen zu Unternehmen unterschiedlich, da Scrum nicht als einheitliche Grundlage verwendet wird.

Jira wiederum ist eine Aufgabenmanagement-Software, die weltweit bei über 14.000 Kunden von Atlassian im Einsatz ist. Sie hat demnach eine sehr hohe Verbreitung und wird sowohl in klassisch geprägten Konstellationen als auch in modernen Projektmanagement-Organisationen verwendet.

Als Product Owner kommen Sie heute kaum noch um den Einsatz digitaler Tools herum. Da Jira aktuell der Weltmarktführer für Aufgabenmanagement ist, konzentrieren wir uns in diesem Artikel auf die Tipps im Umgang mit Jira.

Aufgaben eines Product Owner

Wie bereits erwähnt, ist es von Organisation zu Organisation unterschiedlich, welche Aufgaben ein Product Owner übernimmt. Folgende Aufgaben fallen jedoch häufig in den Verantwortungsbereich der Rolle:

• Anforderungen aufnehmen und abstimmen
• Repräsentation von Stakeholdern im Team
• Kommunikation nach innen und außen
• Produkt- oder Projekt-Marketing
• Definition der Roadmap
• Beschreibung, WAS umgesetzt werden soll
• Priorisierung und Budgetierung
• Fokus auf der Produktentwicklung und Integration in die Unternehmensstrategie

Die meisten dieser Punkte können mithilfe von Jira umgesetzt werden. Der Schwerpunkt von Jira liegt dabei auf der Formulierung der Anforderungen und der Erstellung der Roadmap.

Schauen Sie sich nun die Liste noch einmal genau an. Fällt Ihnen etwas auf?

Bei den Anforderungen an den Product Owner liegen kaum Unterschiede zur Rolle der Projektleitung vor. Der Fokus liegt hier allerdings mehr auf dem Projekt und dessen erfolgreicher Umsetzung. Anders beim Product Owner: Der Fokus liegt hier darauf, dass das Produkt langfristig erfolgreich ist und dass es zur Gesamtstrategie des Unternehmens passt.

3 Tipps für Product Owner

Anforderungen aufnehmen, das WAS beschreiben, priorisieren und eine Roadmap erstellen. Das sind alles Aufgaben, die Sie als Product Owner in Jira abbilden können. Aber auch wenn Sie es nicht selbst machen, sondern die Aufgabe an das Team delegiert haben, werden Ihnen die nachfolgenden Tipps sicher weiterhelfen.

Tipp 1: Stories schreiben, die nicht bleiben

Stories schreiben in Jira ist sehr einfach. Doch gute Stories zu schreiben, die vom Team verstanden werden und das beinhalten, was die Stakeholder wollen, ist die Herausforderung.

Warum also Stories schreiben, die nicht bleiben?

Eine Story dient nur einem Zweck: der Umsetzung einer Anforderung oder eines Wunsches. Sie ist nicht für die Dokumentation ausgelegt, gleichwohl wird sie in manchen Unternehmen auch zur Dokumentation des Umgesetzten eingesetzt.

Was sind Anforderungen?

Anforderungen sind funktionale und nicht-funktionale Spezifikationen, Wünsche und Ideen. Meistens sind Anforderungen zunächst unklar und entwickeln sich mit der Zeit. Wenn sie spezifisch genug sind, können sie als Story in Jira erfasst werden.

Wo werden Anforderungen ansonsten beschrieben?

Stories können grundsätzlich immer verwendet werden.

Es kann sich aber auch anbieten, Anforderungen zunächst in Confluence zu beschreiben und mit den Stakeholdern abzustimmen. Aus einer Anforderung werden dann eine bis mehrere Stories erstellt. Dafür bietet sich Jira als Tool an. Sie sollten jedoch darauf achten, dass Sie die Stories in Jira mit den Anforderungen in Confluence verlinken.

Was ist der Vorteil des Einsatzes von Confluence?

Wenn Sie die Anforderungen in Confluence beschreiben, haben Sie dort auch die geeignete Stelle zur Dokumentation gefunden. Confluence kann besser zur strukturierten Ablage von Informationen verwendet werden.

Jira ist kurzlebig. Sobald eine Story abgeschlossen ist, verschwindet sie aus dem sichtbaren Bereich und muss gesucht werden, um wieder sichtbar zu werden.

Wie kann das noch strukturiert werden?

Jira arbeitet standardmäßig mit sogenannten Epics. Ein Epic ist eine große Story. Diese wird in Jira als ein Strukturelement dargestellt. Unter einem Epic können dabei mehrere Stories untergebracht werden. Die Struktur der Anforderungen kann wie im folgenden Beispiel aussehen:

Die Struktur gestaltet sich in der Regel so:

1. Aus einer Anforderung in Confluence können eine bis mehrere Epics erstellt werden.
2. Unter einem Epic kann es Story, Bug und Task geben.
3. Stories und Tasks können dabei wiederum in Sub-Tasks unterteilt werden.

Wofür werden Stories verwendet?

Stories werden für die Beschreibung von Kundennutzen verwendet. In den letzten Jahren hat sich dafür ein Template zur Beschreibung von User Stories etabliert:

Als [Nutzer] möchte ich [Funktion], um [Mehrwert].

Ein Beispiel: Als Autor des Blogbeitrags möchte ich das Schreiben von Stories vermitteln, um Product Owner in ihrer täglichen Arbeit zu unterstützen.

Wie werden Stories in Jira dargestellt?

Drei Felder sind in Jira Pflichtfelder: Projekt, Vorgangstyp und Beschreibung.

Das oben genannte Template wird in der Beschreibung eingetragen. Für unser Beispiel bedeutet das:

Nur der einleitende Text wird allerdings nicht ausreichen, um die Story umzusetzen. Im Fall des Blog-Beitrags werden noch benötigt:

• Keywords des Beitrags
• Länge des Beitrags
• Beitragsbilder
• Welche Tipps behandelt werden sollen

Sie müssen als Product Owner also noch weitere Informationen liefern, um die Story zu beschreiben. Dazu können Sie einfach weitere Informationen in der Beschreibung ergänzen oder auch als Anhang hinzufügen.

Eine Möglichkeit, um weitere Informationen zu erfassen, ist in Form der Akzeptanzkriterien.

Tipp 2: Akzeptanzkriterien für gute Stories

Das zuvor beschriebene Beispiel wurde um die Akzeptanzkriterien ergänzt:

In dem Beispiel wurden zur Story drei Akzeptanzkriterien in der Beschreibung aufgenommen:

• Stories schreiben, Akzeptanzkriterien und Stories aufteilen wurden beschrieben
• Beitragslänge von ca. 1.500 Zeichen
• Absätze gehen nicht über 3 bis 4 Sätze hinaus

Alternativ zum Erfassen in der Beschreibung kann auch ein To-Do-Plugin verwendet werden. In diesem Fall werden die Akzeptanzkriterien dann als einzelne Einträge dargestellt, die Sie auch abhaken können.

Tipp: Ein geeignetes Plugin zur Erfassung der Akzeptanzkriterien in Jira ist z.B. Acceptance Criteria for Jira von HeroCoders.

Für den Start mit der Arbeit mit Jira Akzeptanzkriterien ist das Beschreibungsfeld allerdings ausreichend.

Tipp 3: Wenn es mal zu viel wird: Stories aufteilen

Auch wenn Sie die zuvor beschriebene Hierarchie verwenden, werden einige Stories zu groß sein. Aber was genau bedeutet zu groß?

Ist eine Story zu groß, dann kann sie nicht in einem angemessenen Zeitrahmen umgesetzt werden und auch die Schätzung des Aufwands oder Komplexität ist schwierig bis gar nicht machbar.

Wenn Sie als Product Owner nach dem Scrum Framework arbeiten, ist Ihr Maßstab ein Sprint. Eine Story sollte so beschrieben werden, dass sie im Rahmen eines Sprints umsetzbar ist.

Lesetipp: Scaled Agile Framework (SAFe) – wie Sie Ihre Organisation agiler gestalten

Arbeiten Sie ohne Sprints, dann können Sie mit dem Team zusammen herausarbeiten, wie umfangreich eine Story maximal sein sollte. Meistens einigen sich Teams darauf, dass Stories innerhalb von 2 Wochen abgearbeitet werden sollten.

Wie teile ich eine Story in Jira auf?

Um eine Story in Jira aufzuteilen, können Sie die Split-Funktion verwenden. Klicken Sie dazu im Backlog mit der rechten Maustaste auf Ihre Story und dann im sich öffnenden Kontextmenü auf Split issue.

Daraufhin öffnet sich dieses Dialogfenster:

Für unsere Beispiel-Story wollen wir hier das Korrekturlesen und auch die Veröffentlichung in separaten Stories behandeln. Zu den beiden Stories gehören noch weitere Aufgaben. Zum Beispiel gehört bei der Veröffentlichung auch dazu, dass Links auf dem Blogbeitrag hinzugefügt werden und der Beitrag in die Seitenstruktur aufgenommen wird.

Für unsere ursprüngliche Story – das Erstellen des Beitrags – ist das nicht mehr relevant. Wir können das Erstellen des Beitrags als fertig betrachten, auch wenn der Blogbeitrag noch nicht veröffentlicht worden ist.

So lässt sich eine Story in sinnvolle Zwischenschritte unterteilen.

Wie kann die Story sinnvoll aufgeteilt werden?

In dem vorherigen Beispiel wurde die Aufteilung aus logischer Sicht vorgenommen. Wir haben drei Stories, die sich am Prozess der Veröffentlichung orientieren:

• Schreiben des Beitrags
• Korrekturlesen
• Veröffentlichung

Aber auch das Schreiben des Beitrags hätte bereits in mehrere Stories unterteilt werden können. Zum Beispiel in:

• Schreiben der Einleitung
• Schreiben von Tipp 1
• Schreiben von Tipp 2
• Schreiben von Tipp 3
• Integration von Bildern
• Erstellen des Fazits

Hier wäre die Unterteilung in die einzelnen Arbeitsschritte erfolgt. Das kann zum Beispiel dann erfolgen, wenn unterschiedliche Teams an einer Story arbeiten. Oder wenn ein Teil für einen Sprint geplant wird und der Rest erst später. So könnte der Beitrag über mehrere Sprints hinweg entstehen und die Stories könnten einzeln abgeschlossen werden.

Die Story könnte auch funktional aufgeteilt werden, z.B.:

• Schreiben eines Beitrags mit Tipps für Product Owner
• Recherche nach geeigneten Bildern

In diesem Fall wird die Story aufgeteilt in das eigentliche Schreiben und die Bilder-Recherche. Übertragen auf ein Software-Projekt heißt das:

• Implementierung der Backend-Funktionalität
• Bereitstellung eines Frontends zur Bedienung des Backends

Wie Sie sehen, gibt es viele Wege und Möglichkeiten, eine Story sinnvoll aufzuteilen. Besprechen Sie mit Ihrem Team, was am besten funktioniert und am hilfreichsten für Sie ist.

Wie stellen Sie Abhängigkeiten dar?

Wenn Sie eine Story aufgeteilt haben, ist dies sowohl in der ursprünglichen Story, als auch in den neuen Stories ersichtlich:

Über die Board-Konfiguration können Sie sich Abhängigkeiten auch im Backlog (oder auch auf dem Board) in Textform anzeigen lassen. Gehen Sie dazu in die Konfiguration (Board Settings) oben rechts:

Gehen Sie dann auf Card layout (1) und fügen Sie anschließend “Linked issues” bei der Backlog-Ansicht (2) hinzu. Vergessen Sie bitte nicht, auch auf “Add” (3) zu klicken.

Wenn Sie nun in das Backlog zurückgehen, werden die Abhängigkeiten unterhalb der Zusammenfassung mit ausgegeben.

So sehen Sie die Abhängigkeiten von Stories in Textform untereinander.

Fazit – der Einsatz von Jira als Product Owner ist einfach, aber…

Mit den zuvor genannten Tipps lässt sich Jira als Product Owner einfach anwenden. Stories lassen sich schnell und strukturiert erstellen. Im Zusammenspiel mit Confluence können Sie Anforderung transparent und nachhaltig erfassen.

Durch Beschreiben der Jira Akzeptanzkriterien ist ganz klar, was eine Story beinhalten muss. Und arbeiten mehrere Leute an einer Story oder wird die Story schlichtweg zu groß, lässt sie sich sehr einfach auf mehrere Stories aufteilen.

Doch wie bei so vielem: Der Teufel steckt im Detail.

Die Blog-Reihe „Jira für Rollen im Projektmanagement“

Dieser Artikel zu Jira und Confluence ist Teil einer Reihe, in der wir die Möglichkeiten der Tools für verschiedene Rollen beschreiben. Hier die Übersicht:

• Teil 1: Jira für das PMO
• Teil 2: Jira für Scrum Master
• Teil 3: Jira für Product Owner (dieser Artikel)
• Teil 4: Jira für Developer
• Teil 5: Jira Tipps zu Filtern, Dashboard und Berichten

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei der TPG Jira Schulung (für Einsteiger, Fortgeschrittene und Experts).

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Der Beitrag 3 Product Owner Jira / Confluence Tipps, durch die Sie leichter mit den Tools arbeiten erschien zuerst auf TPG Projektmanagement Blog für Profis.

Lernen Sie in diesem Artikel, wie Sie bei der Stakeholderanalyse und beim Stakeholdermanagement im Projektmanagement mit einigen Werkzeugen und Methoden zielgerichtet am besten vorgehen. Diese Kapitel warten auf Sie:

• Was ist Stakeholdermanagement?
• Was sind Stakeholder im Projekt?
• Was sind typische Stakeholder?
• Stakeholderanalyse vs.Stakeholdermanagement
• Stakeholderanalyse Definition
• Stakeholderanalyse durchführen (Methoden und Werkzeuge)
• So erstellen Sie eine Stakeholderliste
• Der richtige Umgang mit Stakeholdern
• Stakeholdermanagement Beispiele
• Stakeholder in agilen Projekten managen
• Zusammenfassung

Zunächst aber zur Definition, was der Begriff „Stakeholdermanagement“ überhaupt bedeutet.

Was ist Stakeholdermanagement?

Projektbeteiligte und Betroffene angemessen einbinden sowie Erwartungshaltungen klären, darum geht es im Stakeholdermanagement. Das ist sehr lohnenswert, denn zufriedene Stakeholder steigern die Chancen auf den Projekterfolg wie kaum ein anderer Faktor. Für effektives Stakeholdermanagement gibt es gute Werkzeuge und wirkungsvolle Handlungsempfehlungen.

Was sind Stakeholder im Projekt?

Die Wortherkunft geht zurück bis auf alte Goldgräber-Zeiten: Wer seinen Anspruch auf ein Gebiet erheben und sichtbar machen wollte, rammte rundherum vier Pfosten (Stakes) in die Erde.

Im Projektmanagement werden daraus abgeleitet die Personen, die Ansprüche im Zusammenhang mit dem Projekt oder dessen Ergebnissen abstecken wollen, als Stakeholder bezeichnet. Der Begriff des „Stakeholders“, findet nicht nur im Englischen Anwendung, sondern auch in anderen Sprachräumen.

Aber beachten Sie: Verschiedene Projektmanagement-Organisationen definieren den Begriff durchaus unterschiedlich. Er wird daher oft von verschiedenen Leuten etwas unterschiedlich verstanden. Folgend eine kurze Übersicht der wichtigsten Organisationen:

Definition von Stakeholder nach PMI

Im Guide to Project Management Body Knowledge (PMBOK® Guide) des Project Management Institute (PMI) wird definiert: Stakeholder sind „Personen, Gruppen oder Organisationen, die auf das Ergebnis eines Projekts, Programms oder Portfolio Einfluss haben oder durch es betroffen sind“ – oder zumindest glauben, dies zu sein.

Definition von Stakeholder nach IPMA

Die International Project Management Association (IPMA) schreibt begleitend zu ihrem aktuellen Leitfaden Individual Competence Baseline (ICB 4) etwas Ähnliches: Stakeholder sind „alle Personen, Gruppen oder Organisationen, die an der Ausführung oder dem Ergebnis eines Projekts beteiligt sind, darauf Einfluss ausüben, davon beeinflusst werden oder sich dafür interessieren.“

Wichtig: Nach beiden Definitionen können auch Projektteam-Mitglieder und Projektmanager:innen selbst Stakeholder sein.

Definition von Stakeholder nach Scrum Guide

Anders ist das im Scrum Guide von den Scrum-Gründern Jeff Sutherland und Ken Schwaber. Hier lautet die Definition: Stakeholder sind „Personen mit einem Interesse am Projekt außerhalb des Scrum-Teams.“

Ob dieser feine Unterschied in der Praxis dazu führt, dass das Team sich nach PMI- und IPMA-Verständnis weniger als „wir“ und „die“ einteilt, mag dahingestellt sein.

Was sind typische Stakeholder?

Wer kann also Projekt-Stakeholder sein?

Beispiele für Stakeholder und Key Stakeholder (= wichtige Stakeholder, die direkten Einfluss haben):

• Projektsponsor
• Unternehmensführung und Manager:innen
• Das Project Management Office (PMO)
• Kund:innen
• Nutzende des Produkts, das im Rahmen des Projekts entsteht

Weitere können hinzukommen:

• Bei Bauprojekten auch Anwohner:innen, Politiker:innen etc.
• Regulative Organe, deren Auflagen erfüllt werden müssen etc.

Wichtig: Es kann versteckte Stakeholder geben, die nicht auf Anhieb klar sind. Auch wenn neue Projekte übernommen werden und ein Unternehmen dem Projektleitenden noch nicht komplett vertraut ist, sind Stakeholder zunächst einmal zu identifizieren.

Ansprüche der Stakeholder

Die „Stakes”, die Stakeholder in einem Projekt haben können, reichen über sehr unterschiedliche Dimensionen, wie:

•  Allgemeines Interesse am Projekt
• Wünsche zu Eigenschaften der Projektergebnisse
• Rechte an Bereichen im und um ein Projekt
• Wissen und Kenntnisse, die eingebracht werden wollen
• Macht, das Projekt in irgendeiner Weise zu beeinflussen
• Beteiligungen an Organisationen und Ergebnissen
• Und viele mehr

Stakeholderanalyse vs. Stakeholdermanagement

Zunächst soll die folgende Grafik verdeutlichen, wie die Begriffe Stakeholdermanagement, Stakeholderidentifikation und Stakeholderanalyse nach dem Verständnis in diesem Artikel zueinander stehen:

Wir verstehen hier also Stakeholdermanagement als eine Unterdisziplin bzw. ein Wissensgebiet im Projektmanagement.

Weiter zur Stakeholderanalyse.

Stakeholderanalyse Definition

Die Stakeholderanalyse fragt, wer im Projekt die Stakeholder sind (Stakeholderidentifikation). Dann identifiziert sie deren Eigenschaften wie Einfluss, die Ansprüche und ihr Maß an Interesse am Projekt. Die Stakeholderanalyse ist also dem Stakeholdermanagement untergeordnet. Die Stakeholderanalyse ist somit eine Ausprägung der Projektumfeldanalyse.

Wenn Sie eine Analyse der Stakeholder durchführen, dann dokumentieren Sie zudem deren:

• Bedürfnisse
• Anforderungen
• Wünsche
• Erwartungen
• Ängste

Aus dieser Dokumentation können Sie Projektanforderungen ableiten. Deshalb ist die Stakeholderanalyse so zentral. Findet sie nicht oder nur unvollständig statt, können wichtige Projektanforderungen übersehen werden.

Außerdem kann es dann passieren, dass sich während der Projektdurchführung Stakeholder zu Wort melden, von deren Existenz Sie nichts wussten – normalerweise keine angenehme Situation.

Richtig unangenehm kann es werden, wenn sich Stakeholder ignoriert fühlen.

Stakeholderanalyse durchführen (Methoden und Maßnahmen)

Wenn nur Sie und Ihr Team überlegen, wer die Stakeholder in Ihrem Projekt sind, dann ist die Gefahr groß, jemanden zu vergessen.

Um keinen Stakeholder zu übersehen, sollten Sie daher besser so vorgehen:

Führen Sie ein Brainstorming mit Personen durch, die sich in der Materie und/oder im Projektumfeld gut auskennen. Richtig geplant, können Sie mit einem solchen Workshop gute Erfolge erzielen.

So geht Brainstorming für die Stakeholderanalyse

Gutes Brainstorming folgt den 12 Regeln:

1. Es gibt eine:n Moderator:in, aber keine:n Leiter:in
2. Setzen Sie ein Zeitlimit und achten Sie darauf, dass der Workshop nicht unterbrochen wird.
3. Das Thema der Runde sollte Kreativität freilegen und sie nicht einschränken
4. Kritik und Beurteilung von Ideen sind nicht gewünscht
5. Auch keine genervten Laute, Grimassen oder Lachen
6. Ideen werden nicht diskutiert
7. Die Quantität der Ideen zählt
8. Radikale oder seltsame Ideen sind willkommen
9. Jede Idee wird notiert
10. Die Notizen bleiben unstrukturiert
11. Die Teilnehmenden der Runde sollten die Ideen der anderen erweitern
12. Eine Auswahl findet erst nach dem Brainstorming statt

Wenn Sie die richtigen Leute eingeladen haben und diese Regeln einhalten, sollten Sie am Ende eine umfangreiche Sammlung von Stakeholdern und deren wichtigsten Eigenschaften haben.

Unser Tipp: Gibt es in Ihrem Team oder unter den Experten, die Sie befragen, introvertiertere Menschen? Dominieren einige die Diskussion und schüchtern andere ein? Dann nutzen Sie eine Technik, mit der Sie im Brainstorming sichergehen können, dass alle Meinungen gehört werden: Die Nominal Group Technique, beschrieben in unserem Artikel zu Risikomanagement.

Halten Sie sich an die 12 Regeln für gutes Brainstorming, so werden Sie eine Vielzahl an wichtigen und unstrukturierten Beiträgen über die Stakeholder in Ihrem Projekt sammeln können.

Nun haben Sie eine unsortierte Ansammlung von Namen und wichtigen Punkten Ihrer Projekt-Stakeholder. Was können Sie tun, um diese in eine strukturierte und präsentierbare Form zu bringen?

Nutzen Sie ein Affinitätsdiagramm!

Affinitätsdiagramm zur Klassifikation von Stakeholdern

Ein Affinitätsdiagramm erstellen Sie in drei Schritten:

1. Brainstorming (das haben Sie bereits erledigt)
2. Geeignete Gruppierungen finden und benennen
3. Ihre Einträge den Gruppen zuordnen

Eine wertende Zuordnung kann natürlich eine gewisse politische Aussagekraft haben. Sie sollten sich überlegen, wie und vor allem wem Sie ein solches Diagramm zeigen. Bei Verwendung innerhalb des Projektteams etwa kann es der Klärung von Strategien gegen Widerstände dienen.

Klare Kommunikationsregeln helfen im Zweifelsfall dabei.

Matrix für die Zuweisung von Verantwortlichkeiten

Mit klaren Kommunikationsregeln erleichtern Sie Ihrem Team das Bewusstsein über

• Ansprechpartner,
• Ansprüche und
• Anforderungen

diverser Stakeholder bei der Zusammenarbeit im Projekt. Dafür können Sie in eine Übersicht darstellen, wer wofür zuständig ist und wann worüber informiert werden sollte.

Hierfür bietet sich etwa die folgende Matrix zur Zuweisung von Verantwortlichkeiten an.

Eine Responsibility Assignment Matrix (RAM), auch bekannt unter dem Namen RACI-Matrix, zeigt, welche Stakeholder wofür zuständig bzw. verantwortlich sind. Zudem ist sichtbar, wer zu welchem Thema befragt oder darüber informiert werden sollte. Folgend ist eine solche RAM- / RACI-Matrix dargestellt.

Egal, ob Sie agil, klassisch oder hybrid im Projekt arbeiten – grundsätzlich wollen Sie sicherlich eine offene und transparente Zusammenarbeit mit Ihren Stakeholdern fördern und möglichst ein Vertrauensverhältnis aufbauen.

Unser Tipp: Nutzen Sie verschiedene bewährte Methoden zur Visualisierung, um eine klare Kommunikationsstruktur zu schaffen. Das unterstützt die Information der richtigen Personen über Wissenswertes und damit die reibungslose Zusammenarbeit innerhalb Ihres Projektes.

So erstellen Sie eine Stakeholderliste

Was im Stakeholdermanagement in jedem Fall hilft, ist eine ausführliche Stakeholderliste. Diese sollte alle wichtigen Informationen enthalten, wie:

• Position im Unternehmen
• Rolle des Stakeholders im Projekt
• Anforderungen
• Wünsche
• Erwartungen
• Projektbedarf
• Priorität
• Problemstellung
• Projektaufgaben (mit namentlicher Zuweisung)

Im Folgenden sehen Sie eine solche Liste als Beispiel.

Bis hier haben Sie viele Stakeholder für Ihr Projekt ermittelt und im Detail definiert. Nun stellen Sie sich die Frage: Was zählt eigentlich beim Umgang mit diesen?

Der richtige Umgang mit Stakeholdern

Jetzt sind Ihre Soft Skills gefragt. Kaum eine andere Aufgabe im Projektmanagement (außer der Teamführung) stellt so hohe Anforderungen an die zwischenmenschlichen Fähigkeiten, wie der richtige Umgang mit den Stakeholdern.

Sie sollten in der Lage sein:

• die Haltung und Persönlichkeit der Stakeholder zu verstehen
• Vertraulichkeiten zu respektieren
• Ihre Integrität zu wahren
• aktiv zu netzwerken
• den richtigen Ton anzuschlagen
• andere anzuleiten, ohne besserwisserisch aufzutreten

Wenn Sie all dies beherrschen, können Sie die Erwartungen Ihrer Stakeholder managen.

Beachten Sie bitte: Es ist nicht Ihre Aufgabe, die Stakeholder als Personen zu „managen“. Sie müssen sich aktiv um das Engagement Ihrer Stakeholder für das Projekt und deren  Erwartungen kümmern.

Stakeholdermanagement Beispiele

Alle Erwartungen werden sich wohl in keinem Projekt der Welt erfüllen lassen. Sie kennen das vielleicht; etwa, wenn bei einem bereits hoch beschäftigten Team immer neue Änderungswünsche aufschlagen. Ein „Nein“ oder ein Alternativangebot gegenüber Stakeholdern ist deshalb manchmal unumgänglich.

Beachten Sie bitte: Es lassen sich nie alle Wünsche erfüllen. Das bedeutet, dass Sie auch mal „Nein“ sagen können müssen oder über Alternativen nachdenken.

Aber damit Sie dies effektiv entscheiden können, ist es Ihre Aufgabe, zunächst aktiv zuzuhören und zu verstehen. Wenn Sie Stakeholder befragen, sollten Sie sich über die Fragen, und wem Sie diese stellen, im Klaren sein.

Erschwerend kommt hinzu, dass Stakeholder oft ihre Erwartungen nicht verständlich formulieren können. Manchmal wissen sie selbst gar nicht genau, was sie wollen. Dann gilt, es Vorschläge zu machen, die vielleicht nachhelfen können.

Außerdem werden Erwartungen oft von Personen beeinflusst, die außerhalb Ihrer Einflusssphäre sind.

• Wenn etwa eine Abteilungsleitung ständig neue Funktionen in einer Software von Ihnen erwartet, dann kann der Grund dafür Druck aus der nächsthöheren Führungsebene sein
• Ein Stakeholder hat Wünsche, die komplett im Gegensatz zu denen eines anderen stehen? Hier ist die schwierige Aufgabe, gut abgewogene Entscheidungen zu treffen und diese aktiv zu kommunizieren

Eine interessante Methode zum Visualisieren unterschiedlicher Stakeholder-Gruppen, bietet die agile Projektmanagement-Welt.

Nutzen Sie Personas

Personas sind Steckbriefe exemplarischer Mitglieder von Nutzergruppen. Diese müssen keinen real existierenden Personen entsprechen, sondern sollen sie nur repräsentieren. Somit kann sich das Team mit Stakeholdern besser identifizieren und auseinandersetzen.

Das wird gerne in Teams bei der Softwareentwicklung eingesetzt. Die Teammitglieder verlieren dadurch weniger schnell den Fokus auf die Menschen, für die sie letztendlich ihre Arbeit tun.

Das Spannende ist: Schon die Erstellung der Personas kann kreative Prozesse freisetzen und Ideen für neue Lösungen bringen.

Unser Tipp: Nutzen Sie den Persona-Ansatz zur besseren Visualisierung. Hin und wieder sollte ein Team die Personas auf Aktualität überprüfen und sie ggf. überarbeiten.

Kraftfeldanalyse

Manche Projekte stehen vor der Herausforderung, dass sie große Änderungen mit sich bringen. Diese werden nicht immer alle Stakeholder begrüßen.

Ist das auch bei Ihnen der Fall, so kann es für Ihr Projektteam schwierig werden, effektiv gegen große Widerstände weiterzuarbeiten.

Für solche Situationen gibt es leider selten einfache Lösungen.

Hier sind Methoden wie aktives Change Managementoder gar Akzeptanzmanagement gefragt. Dabei gilt es natürlich immer, die Widerstände zu verstehen – diese sind sie ja meist nicht ohne Grund vorhanden.

Kurt Lewin (1890-1947) hat mit der Kraftfeldanalyse eine visuelle Darstellung entwickelt, bei der treibende und bremsende Kräfte gegenübergestellt werden. Damit lässt sich die Erfolgswahrscheinlichkeit einer Veränderung bewerten.

Hierbei stehen treibende Kräfte (driving forces) für eine Initiierung oder Unterstützung der Änderung. Diese können zum Beispiel sein:

• Anordnung einer Führungskraft
• Vorteile und Anreize
• Wettbewerbsdruck
• Stakeholder, die die Änderung aktiv bewerben

Zurückhaltende Kräfte (restraining forces) hingegen sind die Widerstände, die eine Veränderungen verlangsamen oder verhindern. Sie können sich zeigen als:

• Apathie oder Aggression bei Leuten, die dagegen sind
• Technische Probleme
• Kommunikationsschwierigkeiten
• Stakeholder, die den Wandel verhindern wollen

Bei der Kraftfeldanalyse werden diesen Haltungen Werte auf einem Spektrum in beide Richtungen zugewiesen und dann der Durchschnitt errechnet. Die folgende Grafik zeigt das am Beispiel.

Stakeholder in agilen Projekten managen

In der agilen Welt ist aktive Stakeholder-Einbindung fest verankert und für den Projekterfolg noch wichtiger als im klassischen und weiter vorausplanenden Projektmanagement.

Agile Projekte haben oft ein hohes Maß an inhaltlicher Unsicherheit und brauchen daher:

• gegenseitiges Vertrauen und Kooperation
• eine gemeinsame Projektvision und Ziele
• Raum für Stakeholder, sich einzubringen und Initiative zu zeigen
• Transparenz und Offenheit als Schlüsselwerte
• eine häufige Interaktion mit Stakeholdern

Für den letzten Punkt haben die meisten agilen Methoden und Rahmenwerke auch konkrete Vorgaben.

Scrum sieht eine Überprüfung der lieferbaren Zwischenergebnisse nach jedem Arbeitsintervall (Sprint) zusammen mit den Stakeholdern vor. In diesem Treffen dürfen und müssen sie sich aktiv mit ihrem Feedback dazu einbringen und entscheiden so über den weiteren Projektverlauf mit.

Bei Extreme Programming gibt es das Prinzip des „Customer on site“. Hier arbeitet der Kunde oder ein:e Repräsentant:in mit dem Team permanent gemeinsam vor Ort an den Ergebnissen mit – oder redet zumindest mit.

Nicht zuletzt verlangt das agile Manifest „Customer collaboration over contract negotiation“. Damit zeigt es ganz selbstbewusst, dass selbst prinzipiell wichtige Themen wie Vertragsverhandlungen niemals der erfolgreichen Kollaboration mit Stakeholdern im Projekt im Weg stehen sollten.

Lesetipp: Agiles Projektmanagement, klassisch oder hybrid? Wann welche Methode passt.

Zusammenfassung

In diesem Artikel haben Sie erfahren, was die Begriffe Stakeholder, Stakeholderanalyse und Stakeholdermanagement bedeuten und wie sie im Zusammenhang stehen.

• Jetzt wissen Sie, warum das aktive Stakeholdermanagement  im Hinblick auf deren Erwartungen und Bedürfnisse so wichtig ist.
• Sie haben verschiedene Methoden für die Stakeholderanalyse und Zusammenarbeit mit den Stakeholdern kennengelernt.
• Und Sie sind informiert über die spezielle Bedeutung der engen Kollaboration mit Ihren Stakeholdern in agilen Projekten.

Mit diesen Informationen haben Sie einiges an Methoden und Werkzeugen für Ihr Stakeholdermanagement in der Hand. Damit können Sie jetzt die Stakeholder in Ihren Projekten besser einbinden und ihre Wünsche mit den Projektzielen ausbalancieren.

Dies dient der besseren Kommunikation und damit dem Erfolg Ihrer künftigen Projekte.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für einen höheren Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig beim TPG Change Management Seminar.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.

Der Beitrag Stakeholderanalyse im Projektmanagement und Stakeholdermanagement richtig durchführen (Methoden und Beispiele) erschien zuerst auf TPG Projektmanagement Blog für Profis.

• Definition Agiles Projektmanagement
• Vorteile von agilem Projektmanagement
• Woher kommt agiles Projektmanagement?
• Das Agile Manifest von 2001
• Die 12 Agilen Prinzipien zusammengefasst
• Agiles vs klassisches Projektmanagement – wichtigste Unterschiede
• Welche agile Methoden gibt es?
• Wann agiles Projektmanagement – für welche Projekte?
• Zusammenfassung – Agiles Projektmanagement Grundlagen

Legen wir los mit der Definition von „agil“ und „Agiles Projektmanagement“.

Das Adjektiv „agil“ meint, dass Management und Steuerung von Projekten und Prozessen sehr dynamisch und flexibel erfolgen. Damit lassen sich etwa Änderungsanträge schnell umsetzen.

Definition Agiles Projektmanagement

Agiles Projektmanagement folgt einem iterativen Ansatz, bei dem in kurzen Abständen (Teil)-Ergebnisse geliefert werden und schnelles Feedback von Stakeholdern eingeholt wird. Im Gegensatz zum traditionellen Projektmanagement wird die Einhaltung von Terminen und Kosten oder die Erfüllung eines spezifizierten Leistungsumfangs weniger oder nicht berücksichtigt. Stattdessen steht das zu liefernde Werk und dessen Akzeptanz durch die Endanwender:innen im Fokus.

Die Vorteile von agilem Projektmanagement

Agiles Projektmanagement bietet viele Vorteile für Unternehmen, die sich in einem dynamischen und komplexen Umfeld bewegen. Einige sind etwa:

• Hohe Anpassungsfähigkeit: Agiles Projektmanagement hat den Vorteil, schnell auf geänderte Anforderungen, Kundenwünsche oder Marktsituationen reagieren zu können. Durch kurze Iterationen und regelmäßiges Feedback kann das Projektteam flexibel auf Veränderungen eingehen und das bestmögliche Ergebnis erzielen.
• Hohe Kundenzufriedenheit: Die Kunden werden beim agilen Vorgehen aktiv in den Entwicklungsprozess eingebunden. Sie können ihre Erwartungen und Bedürfnisse jederzeit äußern und erhalten laufend (Teil-)Ergebnisse, die sie bewerten und abnehmen können. So entsteht ein Produkt, das genau auf den jeweiligen Kundenwunsch zugeschnitten ist.
• Hohe Qualität: Agiles Projektmanagement legt großen Wert auf die Qualität des Produkts oder der Dienstleistung. Durch automatisierte Tests, ständige Optimierung und kontinuierliche Verbesserung wird sichergestellt, dass das Produkt fehlerfrei, funktional und benutzerfreundlich ist.
• Hohe Kreativität: Die Kreativität und Innovation des Projektteams wird durch agiles Projektmanagement gefördert. Durch offene Kommunikation, flache Hierarchie und hohe Eigenverantwortung können die Teammitglieder ihre Ideen einbringen und umsetzen. Das führt zu neuen Lösungen und Wettbewerbsvorteilen.

Doch zunächst die Antwort auf die Frage: Wie und warum sind agile Methoden eigentlich entstanden?

Woher kommt agiles Projektmanagement?

Grundsätzlich gehen viele agile Ideen zurück auf die Philosophie des Lean Manufacturing, auch bekannt als Toyota Production System.  Dabei hat man in Japan bereits kurz nach dem 2. Weltkrieg verstanden, dass es auf zwei Dinge in der Produktion ankommen sollte:

• Den menschlichen Faktor – wenn ein Problem auftrat, sollten Menschen in die automatisierten Prozesse eingreifen können, anstatt tatenlos zuzusehen, wie fehlerhafte Ergebnisse gefertigt werden.
• Schlanke Prozesse – Ergebnisse sollten „just in Time“ erzeugt werden. Das bedeutet, dass jeder Prozess nur das hervorbringt, was der nächste Prozess braucht. Und das zur richtigen Zeit und in der richtigen Menge.

Diese Ideen wurden mit der Zeit auch in anderen Ländern bekannter. Sie waren schließlich auch eine wichtige Inspiration für 17 Männer, die in den 1990er-Jahren neue Management-Ansätze für die Softwareindustrie entwickelten – zuerst unabhängig voneinander.

Lesetipp: Agile Projektmanagement-Zertifizierungen im Vergleich – wie sollten Sie vorgehen?

Das Agile Manifest von 2001

2001 kamen diese Softwareexperten schließlich in einem Skiresort in Utah zusammen, um die Ideen festzuhalten, auf die sie sich alle als gemeinsame Grundlage einigen konnten. Sie unterschrieben das Agile Manifest, in dem einige Werte (linke Seite) definiert sind, die wichtiger sein sollten als andere (rechte Seite):

• Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
• Funktionierende Software ist wichtiger als ausführliche Dokumentation
• Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen
• Reaktion auf Veränderungen ist wichtiger als die Befolgung eines Plans

Ganz wichtig ist der Zusatz:

„Während die Dinge auf der rechten Seite durchaus einen Wert haben, schätzen wir die Dinge auf der linken Seite als wertvoller ein“.

Das wird oft übersehen.

Es ging den Autoren des agilen Manifests nicht darum, Prozesse, Dokumentation, Verträge und Pläne für überflüssig zu erklären. Vielmehr wollten sie, dass diese Dinge, so notwendig sie sein mögen, an die richtige Stelle rücken: An die hinter den Menschen, die im Projekt arbeiten und die Ergebnisse nutzen, und hinter die Ergebnisse der Arbeit.

Die 12 Agilen Prinzipien zusammengefasst

Da das agile Manifest eher kurz und knackig formuliert wurde, gibt es zum besseren Verständnis der Absichten dahinter noch 12 ergänzende Prinzipien. Diese finden Sie folgend zusammengefasst:

Qualität und Wert für den Kunden

Wert für den Kunden zu erzeugen, ist die höchste Maxime. Dies kam für die Autoren des agilen Manifests nicht von ungefähr: Die Standish-Group hatte 1996 in einer Studie festgestellt (Seite 15), dass 45 % aller Softwarefunktionen nicht verwendet wurden, 19 % selten.

Es ist zu hoffen, dass sich dieses Missverhältnis mittlerweile verbessert hat. Allerdings kennt wahrscheinlich jeder von uns Beispiele für teure und aufwändige Softwarefunktionen, die wir niemals nutzen. Deshalb helfen agile Projektmanagement-Methoden bei der Klärung der Frage, was der Kunde wirklich braucht und will.

Eins bedeutet Agilität nicht: Schnelle Ergebnisse um jeden Preis. Qualität und Wert für den Kunden stehen im Mittelpunkt und dürfen keinen zeitlichen oder monetären Zielen geopfert werden.

Mit Veränderungen umgehen und kontinuierlich besser werden

Agile Methoden bieten durch iterative und inkrementelle Vorgehensweisen Möglichkeiten, schnell auf Änderungen reagieren zu können.

Wer häufig in möglichst kurzen Entwicklungs- und Lieferzyklen (Iterationen) liefert, hat zwei Vorteile:

• Quick Wins: Frühe nutzbare Ergebnisse generieren bereits Einkommen
• Frühes Feedback: Die regelmäßige Präsentation und Übergabe von Ergebnissen ermöglicht, nah am Kunden zu sein und auf Wünsche und Anregungen besser eingehen zu können.

Wie kurz die Iterationen sein sollen, sieht jede agile Methode etwas anders vor. Es hängt auch von einigen projektspezifischen Faktoren ab wie Marktsituation und -fenster, Personalverfügbarkeit, vertragliche Vorgaben, Deadlines und vielen mehr.

Nicht nur das Ergebnis der Arbeit, sondern auch die Teamdynamik und die Prozesse selbst werden häufiger Prüfung unterzogen: In regelmäßigen Retrospektiven erörtern und diskutieren die Teammitglieder Probleme und finden Lösungen und Verbesserungsvorschläge.

Menschen im Mittelpunkt

• In agilem Projektmanagement geht es vor allem um Menschen und ihre Interaktionen (erster Wert des Manifests). Ohne enge Zusammenarbeit zwischen Projektteam und Stakeholdern keine brauchbaren Ergebnisse.
• Das “agile Mindset” beinhaltet den festen Glauben an das Gute im Menschen. Ein motiviertes Team, zum Beispiel dank einer guten Vision, mit der sich alle identifizieren können, hat bessere Chancen auf vorzeigbare Projektergebnisse, auf die alle stolz sein können. Interessant ist hier auch die genaue Formulierung: Der motivierte Mensch steht im Mittelpunkt des Projekts.
• Wenn wir gerade über Menschen sprechen, sollten wir nicht vergessen, dass Teammitglieder eine motivierende Umgebung, Unterstützung und Vertrauen brauchen. Wer all dies nicht bereitstellen will oder kann, braucht sich an agilen Methoden kaum zu versuchen.
• Agile Methoden sind für komplexe Umgebungen mit unsicheren Anforderungen gemacht. Es scheint fast so, als soll dazu ein Ausgleich gefunden werden, um in all der Hochtechnologie, die von agilen Teams entwickelt wird, den Menschen nicht aus dem Blick zu verlieren. Ein Credo aller agilen Methoden ist deshalb die Bevorzugung von direkter Kommunikation, Angesicht zu Angesicht – nicht etwa per E-Mail, die normalerweise sehr zeitverzögert ist und oft in einer Flut an Information untergeht. Das kommt Verschwendung gleich, die wir ja vermeiden wollen.

Funktionierende Software als wichtigste Basis für Fortschrittsmessung

Vorgesetzte oder Kundenkontakte fragen oft nach ausführlichen Berichten zum Projektfortschritt. Diese zu erstellen, kostet Sie oft mehr Zeit, als Sie möchten? Sie haben das Gefühl, Ihre berichteten Zahlen sind zum Versandzeitpunkt bereits nicht mehr aktuell? Mit diesem Problem sind Sie nicht alleine. Mit Sicherheit findet in diesem Bereich einiges an Verschwendung von Zeit und Ressourcen statt.

In agilen Methoden gibt es nach wie vor Fortschrittsmessungen und KPIs, allerdings verschlankter gegenüber klassischen Methoden. Und prinzipiell zeigen aktuelle Arbeitsergebnisse am besten, wo ein Team steht.

Nachhaltigkeit und Einfachheit

Nachhaltigkeit ist in Zeiten knapper Ressourcen oberstes Prinzip. Also: Nicht mit schwer aufrechtzuerhaltenden Billigprodukten Mittel und Zeit verschwenden.

Zu Nachhaltigkeit gehört es auch, keine Menschen auszubeuten. Die Vermeidung von dauerhaft vorkommenden Überstunden im Team gehört dazu.

KISS – “Keep it simple, stupid!” ist ein bekanntes Motto. Wer allerdings versucht, wirklich immer nur das gerade Notwendige zu tun und eigentlich überflüssige Prozesse abzubauen, weiß, dass das sehr herausfordernd sein kann.

Das zehnte Prinzip sagt: „Einfachheit – die Kunst, die Menge nicht erledigter Arbeit zu maximieren –  ist essentiell“. Damit ist nicht etwa gemeint, sich auf die faule Haut zu legen – sondern eigentlich überflüssige Tätigkeiten zu identifizieren und zu streichen. Damit am Ende der Aufwand in die Arbeit gesteckt wird, die sich tatsächlich lohnt.

Selbstorganisation und Moderation

Informationen über hierarchische Strukturen hinweg und Befehlsketten machen Agilität fast unmöglich. Selbstorganisierte Teams sind notwendig: Sie haben ein hohes Maß an Demokratie und Konsensfindungsprozessen.

Das erfordert eine gewisse Teamreife und kann auch mal müßig werden. Sie sind dabei aber nicht alleine. Agile Coaches oder bei Scrum auch Scrum Master helfen, unterstützen und beraten. Wenn es einmal nicht mehr weitergeht, hauen sie im Notfall auch mit der Faust auf den Tisch und treffen Entscheidungen.

All diese Werte und Prinzipien waren von Programmierern vorrangig für die IT-Branche gedacht. Aber natürlich sind sie auch für Projekte außerhalb von Softwarethemen wichtig. Und sie können dort genauso angewendet werden.

Agiles vs klassisches Projektmanagement – wichtigste Unterschiede

Die Unterschiede zwischen agilem und klassischem Projektmanagement lassen sich grob zusammenfassen wie folgt:

Steht beim klassischen Projektmanagement das Ziel fest und Termine wie Kosten sind veränderbar, so ist es im agilen Ansatz anders: Termine und Kosten werden soweit möglich fixiert und das Ergebnis ist am Ende ggf. völlig anders, als zu Projektbeginn avisiert – aber es schafft den geforderten Kundennutzen!

Lesetipp: Projektmanagement-Methoden Vergleich: Agil, klassisch oder hybrid?

Welche agilen Methoden gibt es?

Einige der Unterzeichner des agilen Manifests haben eigene Methoden und Frameworks entwickelt. Jede davon mit eigenen Lösungsvorschlägen, wie die Ideen aus dem Manifest konkret angewendet werden können. Einige lassen sich auch gut miteinander kombinieren.

Das bekannteste und meistbenutzte Framework ist Scrum.

Einige Organisationen bieten dazu auch Scrum Zertifizierungen an, etwa zum:

• Professional Scrum Master der Scrum.org – 80 Multiple-Choice-Fragen in einer Stunde, nicht ganz einfach zu knacken und deshalb anerkannt
• Certified Scrum Master der Scrum Alliance – eine der ersten und ältesten Zertifikate im Scrum-Bereich

Einige weitere agile Projektmanagement-Ansätze unter vielen sind:

Extreme Programming (XP) – vor allem basierend auf Werten und Prinzipien für Entwicklungsteams und ihre Kunden. Einige XP-Prinzipien sind weltweit anerkannt und werden häufig eingesetzt, wie etwa Pair Programming oder Continuous Integration.

Kanban – ein Werkzeug zur Aufgabenplanung, das aus Lean Manufacturing entstanden ist („Kanban“ ist japanisch für „Schautafel“). Selbst, wenn dieser Begriff unbekannt ist, kennt fast jeder Tabellen mit Aufgaben in Spalten namens „To Do“, „In Progress“ und „Done“. Das Team schiebt die Aufgaben selbst zwischen den Spalten hin- und her. Software wie Trello bildet das recht simpel ab.

Ein wichtiges Prinzip im Kanban ist die Begrenzung von gerade stattfindender Arbeit (Work in Progress oder kurz WIP Limit): Da Teams, die versuchen, immer mehr zu erledigen, paradoxerweise immer langsamer Ergebnisse liefern, darf nie mehr als eine bestimmte Anzahl Aufgaben gleichzeitig in Arbeit sein.

• Test-Driven Development (TDD) – ein Ansatz der Softwareentwicklung, bei dem zuerst Test Cases geschrieben werden, „gegen“ die dann Code geschrieben wird. Zunächst schlagen deshalb alle Test Cases erst einmal fehl. Steht der Code, wird er gemäß den Test Cases getestet und dann für gut befunden, wenn dieser Test erfolgreich war. So soll vermieden werden, dass Dinge entwickelt werden, die überhaupt nicht angefordert sind.
• The Spotify Model – Die Firma Spotify hat ihren eigenen Weg zur agilen Organisation gefunden und diesen als Video auf Vimeo mit der Welt geteilt. In der Folge übernehmen nun viele Firmen diese Ansätze. Ein bisschen stellt sich dabei die Frage, wie erfolgversprechend es sein kann, auf andere Unternehmen zugeschnittene Lösungen für sich selbst zu kopieren.

Besonders geeignet, miteinander kombiniert zu werden, sind etwa:

• Scrum und XP, da Scrum das Prozess-Rahmenwerk liefert und XP Handlungsempfehlungen
• Scrum und Kanban (zu dieser Kombination bietet Scrum.org sogar eine eigene Zertifizierung)
• Zu einem gewissen Grad auch klassische und agile Methoden

Eine Zertifizierung, die deutlich mehr als nur Scrum abdeckt, sondern alle agile Methoden und die ihnen gemeinsamen Ideen dahinter unter einem Hut vereint, ist der Agile Certified Practitioner  des Project Management Institute (PMI®).

Die Vielfalt der Ansätze führt uns als Nächstes zur Frage: Welche Projekte und Umgebungen sind überhaupt für agile Methoden geeignet? Gibt es Faktoren, die eher dagegen sprechen?

Der Scrum Guide 2020

Zum 25. Geburtstag von Scrum, dem 18. November 2020, hat der Scrum Guide 2017 sein letztes Update bekommen. Im neuen Scrum Guide wird Scrum als Rahmenwerk beschrieben, das dabei hilft, durch adaptive Lösungen für komplexe Probleme Wert zu generieren. Dabei wurden aus der alten Version teilweise Passagen gekürzt oder sogar gestrichen.

Insgesamt beschreibt der Scrum Guide 2020 jetzt weniger, wie die Elemente von Scrum umgesetzt werden sollen. Das erleichtert das inhaltliche Verständnis beim Lesen.

Weitere Änderungen des Scrum Guides 2020 sind außerdem:

• Rollen: Statt „Development Team“ ist jetzt die Rede von „Developers“
• Es gibt drei Zielsetzungsebenen, denen das Team sich verschreiben soll: Das Product Goal für das Produkt, das Sprint Goal für den Sprint und die Definition of Done für das Inkrement
• Der Scrum Master ist nun offiziell verantwortlich für die Effektivität des Scrum Teams
• Statt „selbstorganisiert“ ist das Scrum-Team nun „self-managing“

Hier finden Sie den Scrum Guide 2020 zum Download.

---

Wann agiles Projektmanagement – für welche Projekte?

Agiles Projektmanagement wurde für hochkomplexe Umgebungen wie in der Softwarebranche entwickelt. Dennoch erfreuen sie sich auch in anderen Bereichen steigender Beliebtheit.

Wann also passt agiles Projektmanagement? Agile Methoden passen für alle Projekte oder Projektumgebungen mit einem hohen Maß an Unsicherheit bei z.B.

• Anforderungen
• verwendeten Technologien
• Risiken
• Umgebungskomplexität

Und wenn das Ziel zu Beginn noch nicht klar definiert ist und häufige Änderungen zu erwarten sind, dann passen agile Methoden ebenfalls.

Zusammengefasst: Agile Methoden werden besonders in Projekten eingesetzt, die zu Anfang sehr unklare Anforderungen haben. Oft sind häufige Änderungen abzusehen. Meist gibt es sogar nicht mehr als nur eine Vision. Diese soll dann auf innovative Weise vom Team umgesetzt werden.

Knapp ein Drittel aller Projektmanagerinnen und Projektmanager leitet nach eigenen Angaben Projekte, bei denen die Identifizierung der Anforderungen Teil des Projekts ist – Tendenz steigend.

Für solche Situationen bieten agile Methoden Wege, mit denen Sie besser durch unsichere Gewässer navigieren. Vorteile ergeben sich unter anderem durch:

• Kurze Planungshorizonte, nur grobe langfristige Planung
• Kurze und häufige Iterationen als Liefer- und Feedbackzyklen mit inkrementeller Ergebniserzeugung
• Klare Taktung und Rhythmisierung der Arbeit durch die Iterationen
• Enge Einbindung der Stakeholder von Anfang an
• Selbstorganisierte Teams, Unterstützungsprozesse und Motivatoren
• Räumliche Zusammenführung von Teams und Fokussierung auf Ergebnisse
• Klar kommunizierte Visionen für das Produkt bzw. das Ergebnis
• Vermeidung von Verschwendung von Zeit und Ressourcen oder zu viel Verwaltungsaufwand
• Führungsstile mit positiver Grundhaltung sowie flache Hierarchien

Es stellt sich die Frage: Gibt es auch Projekte und Branchen, für die agiles Projektmanagement nicht so geeignet ist?

Hier ist vielleicht der Ansatz des Hybriden Projektmanagements der richtige. Lesen Sie dazu den folgenden Artikel.

Lesetipp: Hybrides Projektmanagement und Vorgehensmodell – Wie Sie agile und klassische Methoden verbinden

Zusammenfassung – Agiles Projektmanagement Grundlagen

In diesem Artikel haben Sie erfahren, was agiles Projektmanagement ausmacht und was seine Vorteile gegenüber der klassischen Herangehensweise sind. Sie haben die wichtigsten Werte und Prinzipien des Agilen Manifests kennengelernt und mehr über einige agilen Methoden erfahren. Außerdem kennen Sie jetzt die wichtigsten agilen Projektmanagement-Zertifizierungen. Und Sie wissen, für welche Projekte agile Methoden besonders geeignet sind.

Grundsätzlich gilt zum Schluss: Agilität und die Haltung dahinter können Sie nicht erzwingen. Sie sind am wirkungsvollsten, wenn die Vorzüge bei der Projektabwicklung im Team freiwillig zum Vorschein treten dürfen.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für ein höheres Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig beim TPG Scrum Grundlagen Seminar.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

FALSE

---

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.

Der Beitrag Agiles Projektmanagement Grundlagen – Definition, Vorteile und Methoden für Einsteiger erschien zuerst auf TPG Projektmanagement Blog für Profis.

Die Projektarbeit benötigt künftig einen klareren Fokus auf den Geschäftswert, mehr Innovationskraft und Kreativität sowie auch kürzere aber solide Planungshorizonte. Dass Unternehmen diesen Wechsel vollziehen, zeigt sich unter anderem am Entstehen neuer agiler Berufsbilder. Und hier spielen agile Projektmanagement Zertifikate eine Rolle.

Lesen Sie in diesem Beitrag:

• Neue Berufsbilder durch agiles Projektmanagement
• Warum sind Scrum-Zertifizierungen sinnvoll?
• Weitere Ansätze und Zertifikate für agiles Projektmanagement
• Übersicht wichtiger agiler Projektmanagement Zertifikate
  • PMI Agile Certified Practitioner (PMI-ACP)
  • Certified Scrum Master (CSM)
  • Professional Scrum Master I (PSM I)
  • Certified Scrum Practitioner (CSP)
  • Scaled Agile Framework (SAFe)
• Welche agile Zertifizierung ist die Richtige für Sie?
• Zusammenfassung: Agile PM-Zertifizierungen

Legen wir los!

Neue Berufsbilder durch agiles Projektmanagement

Wussten Sie, dass sich ‚Scrum Master‘ und auch ‚Product Owner‘ immer mehr zur eigenständigen Berufsbezeichnung mausern?

Vom Namen einer Rolle im Scrum-Team kommend, werden diese Begriffe immer häufiger in Stellenanzeigen explizit ausgeschrieben. Und Firmen nehmen diese Bezeichnungen in die Karrierepfade für die Mitarbeitenden auf.

Wie in jedem Bereich zählt hier die Erfahrung der Kandidatinnen und Kandidaten. Sie darf auf keinen Fall unterschätzt werden. Scrum Master brauchen in ihrer hochgradig vermittelnden und unterstützenden Rolle neben genug Berufserfahrung zudem:

• gute Menschenkenntnis
• Feingefühl
• Moderationsfähigkeit
• Konfliktlösungskompetenz

Warum sind Scrum-Zertifizierungen sinnvoll?

Rund um Scrum gibt es viele Missverständnisse. Die erfolgreiche Einführung der Methoden hängt auch stark vom Wissensschatz der Beteiligten ab.

Daher können Grundlagen für agile Projektmanagement Zertifizierungen wie etwa der „Professional Scrum Master I“ von Scrum.org oder der „Certified Scrum Master“ von der Scrum Alliance sehr hilfreich sein.

Diese beiden Zertifizierungen sind für Einsteiger:innen in die agilen Methoden gedacht.

Zunächst signalisieren Sie als zertifizierte Person, dass Sie die Grundprinzipien des Scrum Framework verstanden und dies in einer Prüfung unter Beweis gestellt haben.

Außerdem zeigen Sie durch eine der oben genannten Zertifizierungen die Bereitschaft:

• in einer solchen Rolle andere zu führen und unterstützen,
• der Organisation bei der Umsetzung von Scrum zu helfen und
• selbst mehr Erfahrung mit Scrum sammeln zu wollen.

Der letzte Punkt ist besonders wichtig, wenn Sie selbst noch am Beginn einer Scrum-Karriere stehen.

Durch agile Zertifizierungen signalisieren Sie als angehender oder bereits aktiver Scrum Master, dass Sie die relevanten Inhalte des Scrum Guides und weitere Literatur gelernt und dieses Wissen in einer Prüfungssituation unter Beweis gestellt haben.

Weitere Ansätze und Zertifikate für agiles Projektmanagement

Ein hervorragender Scrum Master verengt den Blick nicht auf Scrum allein. Es gibt eine Vielzahl agiler Methoden und Ansätze. Sie können miteinander kombiniert werden und haben viele Aspekte gemeinsam. Beispielsweise basieren viele Methoden auf:

• ein vertrauendes und offenes Menschenbild oder
• einer iterativ-inkrementelle Arbeitsweise.

Außerdem gibt es Umfeld-Themen in Organisationen, denen agile Methoden oft weniger Beachtung schenken. Hier sind beispielsweise zu nennen:

• Portfoliomanagement
• Ressourcenmanagement
• Projektauswahlmethoden
• Organisationsstrukturierung
• etc.

All dies führt nun von der Produktentwicklung auf Einzelteamebene, für die Scrum primär entwickelt wurde, zurück zu Projektmanagement-Themen. Dies erfordert einen ganzheitlichen und eher übergeordneten Blick auf die Themen.

Hier kommt der PMI-ACP® („Project Management Institute Agile Certified Practitioner“) ins Spiel.

PMI Agile Certified Practitioner (PMI-ACP)

Das PMI-ACP-Zertifikat ist für Personen gedacht, die bereits (agile) Projekterfahrung vorweisen können. Es hat den Anspruch, die Ideen aller agilen Methoden zu sammeln und standardisiert zusammenzufassen.

Dies ist ein Ziel, mit dem es das Project Management Institute (PMI)® durchaus ernst meint: So wurde sein Standardleitfaden für die Projektmanagementbranche, der „Guide to the Project Management Body of Knowledge“ (PMBOK® Guide) in seiner 6. Ausgabe im September 2017 als Bundle zusammen mit dem Agile Practice Guide herausgebracht. Mittlerweile gibt es den PMBOK® Guide in der 7. Ausgabe – der Agile Practice Guide aber ist immer noch aktuell.

Download (PDF): Hybrid – Wie Sie agile und klassische PM-Methoden verbinden

Laden Sie sich dieses PDF mit vielen praktischen Tipps zum Um- und Einsetzen von hybridem Projektmanagement jetzt kostenlos herunter.
* Pflichtfeld  |  Datenschutzhinweise

Dieses Formular wird durch Ihre Cookie-Einstellung zu unserer Website blockiert. Bitte klicken Sie hier und wählen Sie mindestens die Marketing-Cookies aus. Dann wird dieses Formular angezeigt. Vielen Dank.

Agile Practice Guide

Der Agile Practice Guide enthält, neben Betrachtungen zu einzelnen agilen Methoden, auch  Leitfäden und Hilfestellungen für situative Methodenauswahl sowie Brückenschläge zu klassischen Projektmanagement-Methoden.

Diese werden immer noch sehr dringend benötigt an all den Punkten, an denen agile Ansätze bei der Problemlösung nicht ausreichend dienen können.

Die Inhalte des Agile Practice Guide sind aus einer Zusammenarbeit des PMI mit der Agile Alliance (ein Zusammenschluss vieler Förderer der agilen Ideen und nicht zu verwechseln mit der Scrum Alliance) entstanden.

Dies signalisiert eine solide Expertenbasis für den neuen Agile Practice Guide.

Seit Ende März 2018 ist dieser Guide auch die offizielle Prüfungsreferenz für den PMI-ACP – aber nur als eine von vielen relevanten Quellen aus dem Katalog agiler Literatur.

Die Popularität des Agile Certified Practitioner Zertifikats steigt in letzter Zeit stark an. Folglich ist der Bedarf an qualitativ hochwertigem Material zur Prüfungsvorbereitung vorhanden.

Immerhin hilft der Agile Practice Guide Prüfungskandidaten aber dabei, die Perspektive des PMI auf agiles Projektmanagement besser einordnen zu können sowie die vorgestellten Methoden in der Praxis anzuwenden.

Kombination von PMI-ACP mit der PMP-Zertifizierung

Der PMI-ACP eignet sich übrigens sehr gut als Kombi-Zertifikat zum klassischen PMP® (Project Management Professional) des PMI.

Für eine Kombination spricht auch, dass die Prüfungsvoraussetzungen für Personen mit PMP® Zertifikat leichter zu erfüllen sind. Wenn Sie also PMP sind, dann müssen Sie keine zusätzliche Projekterfahrung nachweisen. In Bezug auf agile Projekterfahrung und Training gilt dies allerdings nicht. Nachweise dazu werden nach wie vor von allen Kandidat:innen verlangt.

So erhält die PMP-Prüfung seit Anfang 2021 zusätzlich Fragen zu drei Projektmanagement-Ansätzen:

• Prädiktiv
• Adaptiv / agil
• Hybrid

Damit müssen auch PMP-Prüflinge einige agile Ideen und Methoden kennen, z.B. Backlog-Pflege, Schätzmethoden oder Retrospektiven.

Download (PDF): PM-Methoden – agil, klassisch oder hybrid? (ein Vergleich)

In diesem herunterladbaren Artikel zum PM-Methoden Vergleich (agil, klassisch und hybrid) erfahren Sie die Unterschiede und erhalten mehr Klarheit im Umgang mit der Wahl der richtigen Methode.
* Pflichtfeld  |  Datenschutzhinweise

Dieses Formular wird durch Ihre Cookie-Einstellung zu unserer Website blockiert. Bitte klicken Sie hier und wählen Sie mindestens die Marketing-Cookies aus. Dann wird dieses Formular angezeigt. Vielen Dank.

Übersicht wichtiger agiler Projektmanagement Zertifikate

Im Folgenden finden Sie die in diesem Artikel erwähnten agilen Zertifikate noch einmal gegenübergestellt. Zusätzlich werden die Zertifizierungen Certified Scrum Practitioner (CSP) für Fortgeschrittene und Scaled Agile Framework (SAFe) für die Skalierung agiler Methoden aufgegriffen.

PMI Agile Certified Practitioner (PMI-ACP)
Aussteller des Zertifikats: Project Management Institute

Voraussetzungen

– 2000 Stunden Projekterfahrung (entfällt für PMP Zertifikatsträger)
– 1500 Stunden Erfahrung in agilen Umgebungen
– 21 Stunden Training in agilen Methoden (z.B. durch das PMI-ACP Seminar bei TPG)

Art der Prüfung

Vor Ort im Test-Center; 120 Multiple-Choice-Fragen mit vier Antwortoptionen und je einer richtigen Antwort, zu beantworten in 3 Stunden

Auch möglich: Online Proctored Exam (Online-Prüfung mit per Webcam zugeschaltetem Prüfungsverantwortlichen)

Passing Score (Anteil benötigter richtiger Antworten)

Geheim (geschätzt auf ca. 70 %)

Kosten für Prüfung

$ 435 (PMI® Mitglieder, etwas höher für Nichtmitglieder)

Gültigkeit

3-Jahres-Zyklus (30 Professional Development Units – PDUs müssen in diesem Zeitraum in agilen Arbeitsumgebungen und / oder Aktivitäten erarbeitet sein.)

Zweck

Standardisierung möglichst vieler agiler Methoden

Zielgruppe

Personen, die ihre Erfahrung mit agilen Methoden und ihr Verständnis davon verbessern und unter Beweis stellen möchten

Certified Scrum Master (CSM)
Aussteller des Zertifikats: Scrum Alliance

Voraussetzungen

Absolvierung eines 2-tägigen Seminars durch einen speziell autorisierten Trainer, nicht länger zurückliegend als 90 Tage vor der Prüfung

Art der Prüfung

Online; 35 Multiple-Choice-Fragen, zu beantworten in 1 Stunde

Passing Score (Anteil benötigter richtiger Antworten)

68,6%

Kosten für Prüfung

Prüfung nur erhältlich nach Seminarbuchung und in Seminarkosten enthalten

Gültigkeit

2-Jahres-Zyklus (Rezertifizierung danach online für 100 $)

Zweck

Klarstellung und Förderung von Scrum

Zielgruppe

Personen, die einen ersten Schritt hin zur Beherrschung von Scrum machen möchten

Professional Scrum Master I (PSM I)
Aussteller des Zertifikats: Scrum.org

Voraussetzungen

Keine formalen (tiefes Verständnis des Scrum Guides zum Bestehen notwendig; Probeprüfung „Scrum Open” gibt es auf scrum.org)

Art der Prüfung

Online; 80 Multiple-Choice-Fragen mit unterschiedlich vielen Antwortoptionen und einer oder mehreren richtigen Antworten, zu beantworten in 1 Stunde.
Tipp: Bei TPG erhalten Sie ein Scrum-Seminar mit anschließender Prüfungsmöglichkeit. Nach nur 3 Tagen können Sie damit Ihr PSM I Zertifikat zielsicher und schnell in Händen halten.

Passing Score (Anteil benötigter richtiger Antworten)

85%

Kosten für Prüfung

150 $

Gültigkeit

Unbegrenzt

Zweck

Klarstellung und Förderung von Scrum

Zielgruppe

Personen, die einen ersten Schritt hin zur Beherrschung von Scrum machen möchten

Certified Scrum Practitioner (CSP)
Aussteller des Zertifikats: Scrum Alliance

Voraussetzungen

Zertifikat als A-CSM, min. 2 Jahre Erfahrung in der Rolle des Scrum Masters innerhalb der letzten 5 Jahre.
Abschluss der am Ende des Kurses verteilten Hausaufgaben innerhalb von 12 Monaten.

Eine Teilnahme am Kurs ist auch ohne diese Voraussetzungen möglich. Allerdings wird dann kein Zertifikat erworben.

Art der Prüfung

–

Passing Score (Anteil benötigter richtiger Antworten)

–

Kosten für Prüfung

$ 250

Gültigkeit

Dauerhaft

Zweck

Ausbau der agilen Produktmanagement-Expertise

Zielgruppe

Die CSP-SM-Zertifizierung eignet sich für Scrum Master, wohingegen sich die CSP-PO-Zertifizierung für Product Owner eignet.

Scaled Agile Framework (SAFe)
Aussteller des Zertifikats: Scaled Agile, Inc.

Voraussetzungen

5+ Jahre in Software-Entwicklung, Testen, Geschäftsanalyse, Produkt- oder Projektmanagement & Erfahrung in Scrum

Kurs zur Abdeckung der SAFe-Inhalte durch Ausbildungsanbieter

Art der Prüfung

Multiple-Choice, 45 Fragen in 90 Minuten, online möglich.

Passing Score (Anteil benötigter richtiger Antworten)

76%, 34 Fragen

Kosten für Prüfung

$ 435

Gültigkeit

1 Jahr, nach Ablauf der Gültigkeit kann die Zertifizierung für $ 100 ohne erneute Prüfung verlängert werden.

Zweck

Agile Skalierung / Scrum Methoden

Zielgruppe

Führungskräfte, Scrum Master, Product Owner, Anforderungs-, Release- und Testmanager, Coaches, Projektleiter, die mehrere Teams erfolgreich agil organisieren wollen.

Welche agile PM-Zertifizierung ist die richtige für Sie?

Nun haben Sie die wichtigsten agilen Zertifizierungen kennengelernt. Doch woher wissen Sie, welche für Sie die richtige ist?

Zunächst empfehlen wir es als sinnvoll, bei den Grundlagen von Scrum zu beginnen. So schaffen Sie eine gute Basis für die Mehrzahl der oben genannten Zertifizierungen.

Anschließend haben Sie die Möglichkeit, Ihr Wissen wie in folgender Grafik gezeigt weiter auszubauen:

Zusammenfassung: Agile PM-Zertifizierungen

In diesem Artikel haben Sie erfahren, was agile Methoden allgemein sind und wo ihre Anwendung vorteilhaft sein kann. Weiterhin wurde ein besonderer Fokus auf Scrum gelegt.

Sie haben folgende agile Zertifizierungen kennengelernt:

• PMI Agile Certified Practitioner (PMI-ACP)
• Certified Scrum Master (CSM)
• Professional Scrum Master I (PSM I)
• Certified Scrum Practitioner (CSP)
• Scaled Agile Framework (SAFe)

Damit können Sie nun besser einschätzen, welcher Weg für Sie persönlich oder für Ihre Mitarbeitenden am sinnvollsten ist.

Unsere Tipps zum Schluss: Lernen Sie das individuell anpassbare “The PPM Paradise” kennen – die optimale Umgebung für ein unternehmensweites Projekt-, Programm-, Portfolio- und Ressourcenmanagement (PPM). Laden Sie sich jetzt hier das eBook dazu herunter (nur klicken, ohne Formular).

Und abonnieren Sie unseren Projektmanagement Newsletter mit mehr MS Project Tipps, praxisstarken Artikeln, Webinaren, Podcasts, eBooks etc. für ein höheres Reifengrad-Level Ihres Projektmanagements!

Sie wollen das Gelernte vertiefen, weitere wichtige Tipps erfahren und Ihre Fragen stellen? Dann sind Sie genau richtig bei den folgenden TPG Seminaren Scrum Seminar bzw. PMI-ACP Seminar.

Haben Sie noch Fragen? Dann hinterlassen Sie einen Kommentar, auf den wir in Kürze antworten werden – garantiert.

FALSE

---

Über die Autorin:
Antje Lehmann-Benz, PMP, PMI-ACP, PSM

Antje Lehmann-Benz, PMP, ist Trainerin für Projektmanagement mit einem besonderen Schwerpunkt auf agilen Themen und Scrum Seminaren. Außerdem hat sie Erfahrung in Software-Trainings (JIRA, Confluence) und -Beratung. Neben der Vermittlung von Frameworks und theoretischen Inhalten hat sie Erfahrung in der Anwendung von Agile Games und praktischen Übungen zur Vertiefung der gelernten Inhalte.

Mehr über Antje Lehmann-Benz auf Linkedin oder Xing.

Der Beitrag Agile Projektmanagement-Zertifizierungen im Vergleich – wie sollten Sie vorgehen? erschien zuerst auf TPG Projektmanagement Blog für Profis.