Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel

Größe: px

Ab Seite anzeigen:

Download "Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel 14.09.2012"

Ute Gitta Auttenberg
vor 8 Jahren
Abrufe

1 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? PMI Prof. Dr.-Ing. Holger Günzel

2 Verglühte die Raumfähre Columbia durch einen unflexiblen Projektmanagementprozess? Rückblick: 2003 verglühte die Raumfähre Columbia beim Wiedereintritt Ursache: Schaumstoffteil hat ein Loch in das Hitzeschild des rechten Flügels gerissen Problem: Technische Lösungen waren den Ingenieuren bekannt Keine prozessurale Möglichkeit für eine Integration der Lösung Quelle: Seite 2

hat ein Loch in das Hitzeschild des rechten Flügels gerissen Problem: Technische Lösungen waren

3 Kommunikationsprojekt Auch andere Nicht-IT-Projekte sollen nicht nur nicht in time and budget, sondern auch flexibel durchgeführt werden. Drei Wünsche des Auftraggebers an das Projektmanagement des Projekts Landratsamtweites Kommunikationskonzept Erfüllung der übergreifenden Ziele Ergebnisse in kundenspezifischer Qualität unter Einhaltung der zeitlichen und finanziellen Rahmenbedingungen + ABER mit: Hoher Flexibilität im Projektablauf (bzgl. zusätzliche Anforderungen, Änderungen der Anforderungen, vorzeitiges Projektende, etc.) Seite 3

Drei Wünsche des Auftraggebers an das Projektmanagement des Projekts Landratsamtweites Kommunikationskonzept Erfüllung der

4 Die (hohe) Flexibilität des Ablaufs steht im Widerspruch zu den Grundsätzen des konventionellen Projektmanagements. Ausgewählte Eigenschaften des konventionellen Projektmanagements z.b. nach PMI PMBOK Standardisierter, fixierter Projektmanagementprozess mit Aktivitäten, Rollen, Ergebnissen Projektleiter als Verantwortlicher in der Planung, Durchführung, Überprüfung und Anpassung des Projekts Anforderungen (und das Vorgehensmodell) dienen als Grundlage zur Planung und Steuerung Change Requests stellen die Ausnahme dar Seite 4

nach PMI PMBOK Standardisierter, fixierter Projektmanagementprozess mit Aktivitäten, Rollen, Ergebnissen Projektleiter als

5 Trotz standardisierten Projektmanagementvorgehensweisen ergeben sich häufig weitere Problemfelder in Projekten. Das Projektergebnis entspricht oftmals nicht den gesetzten Zielen Die Anforderungen an das Projekt werden vom Auftraggeber anfangs selten eindeutig formuliert Der Erfolg eines Projekts hängt nicht nur vom Prozess, sondern von den Projektmitgliedern ab Team-Mitglieder fühlen sich manchmal nur bedingt für das Ergebnis verantwortlich Das Lernen aus den Stärken und Schwächen erfolgt erst nach Abschluss des Projekts Es existiert nur eine scheinbare Transparenz des Status Projekte laufen zeitlich, finanziell und qualitativ aus dem Ruder Bei einem vorzeitigen Abbruch bleibt das Risiko des Totalverlustes Seite 5

Projekts hängt nicht nur vom Prozess, sondern von den Projektmitgliedern ab Team-Mitglieder fühlen sich manchmal nur bedingt für das Ergebnis verantwortlich Das Lernen aus den

6 Schon vor 20 Jahren entstand in IT-Projekten die Idee der agilen Vorgehensweise und wird heute erfolgreich eingesetzt. Anfang 90er: Jeff Sutherland: Initiale Scrum-Aktivitäten Mitte 90er Ken Schwaber: Vorstellung Scrum auf OOPSLA 2001 Agiles Manifest In ausgewählten Projekten wurden signifikante Veränderungen festgestellt: Höhere Produktivität: 90% Geringere Kosten: 25% Schnelleres Time-to-Market: 75% Höhere Ergebnisqualität: 60% Höhere Zufriedenheit der Stakeholder: 75% Gesteigertes Engagement der Mitarbeiter: 75% * Mike Cohn Agile Softwareentwicklung (inkl. div. Studien 2008) Seite 6

ausgewählten Projekten wurden signifikante Veränderungen festgestellt: Höhere Produktivität: 90% Geringere Kosten: 25% Schnelleres Time-to-Market: 75%

7 Bei agilen Vorgehensweisen stehen neue Werte im Vordergrund; dennoch sind auch die anderen Werte wichtig. Menschen und deren Zusammenarbeit sind wichtiger als Prozesse und Werkzeuge Einsetzbare Lösungen sind wichtiger als eine ausführliche Dokumentation Zusammenarbeit zwischen Betroffenen und Beteiligten ist wichtiger als formale Regelungen Offenheit für Änderungen sind wichtiger als das Befolgen eines festen Plans Quelle: modifiziert nach dem Agilen Manifest Seite 7

eine ausführliche Dokumentation Zusammenarbeit zwischen Betroffenen und Beteiligten ist wichtiger als formale

8 Auch in Nicht-IT-Projekten kann Agilität als Die Kunst des Machbaren verstanden werden. 1. Fokus auf Produkt mit Business Value statt auf Detaillierung der Anforderungen 2. Iteratives Vorgehen zur Konkretisierung der Komplexität 3. Flexibilität des Vorgehens zur Erhöhung der verwertbaren Ergebnisse 4. Selbstorganisierte Teams mit ständiger Verbesserung Seite 8

Iteratives Vorgehen zur Konkretisierung der Komplexität 3.

9 Agil Konventionell 1. In agilen Projekten liegt der Fokus auf dem Business Value des Produkts anstatt auf einer frühen Detaillierung der Anforderungen Überprüfung Überprüfung Business Ziele Detaillierung Umsetzung Anforderung Projektergebnis Einsatz Quelle: Modifiziert nach Wolf/ Bleek 2011 Business Ziele Vision Ableitung des Business Value User Stories: Nutzer/ Aktivität/ Wert Projektergebnis Detaillierung & Umsetzung Seite 9

Detaillierung der Anforderungen Überprüfung Überprüfung Business Ziele Detaillierung Umsetzung Anforderung

10 Kommunikationsprojekt Mit den User Stories werden unabhängige und testbare Werte des Produkts beschrieben. User Story 1: Landrat kommuniziert mit den Abteilungsleitern, um. User Story 2: Abteilungsleiter kommunizieren mit dem Landrat, um User Story 3: Landrat kommuniziert mit den Gruppenleitern, um User Story 4: Gruppenleiter kommunizieren mit dem Landrat, um User Story 5: Landrat kommuniziert mit den Mitarbeitern, um User Story 6: Mitarbeiter kommunizieren mit dem Landrat, um Seite 10

User Story 2: Abteilungsleiter kommunizieren mit dem Landrat, um User Story 3: Landrat kommuniziert mit den

11 2. Das Prinzip der Iterativität ermöglicht die Komplexität zu konkretisieren. Konventionelle, Schichten -Vorgehensweise Agile, Stückchen -Vorgehensweise Seite 11

12 Kommunikationsprojekt Die Vielzahl an Kommunikationsteilnehmern erhöht die Komplexität des Projekts. Unternehmen Bürger Rechnungs prüfungsaus schuß Verbände Presse, Medien Bürgermeister Lieferanten (z.b. Agenturen) Information und Kommunikation Kreisrat Kommunen Abteilungsleiter Landrat Sachgebiets -leiter Mitarbeiter Personalrat IT Rechnungsprüfer Projekte Personal- management Beteiligungs management Finanzmanagement Seite 12

nde Presse, Medien Bürgermeister Lieferanten (z.b.

13 Durch das iterative Vorgehenskonzept wird neben schnellen Erfolgen das Projektergebnis erarbeitet Kommunikationsprojekt Vorgehensmodell Kommunikationsprojekt Projektmanagement Planung Analyse Konzept Kommunikationskonzept Maßnahmen Evaluati on I 1 I 2 I 3 R1 R2 Veränderungsmanagement I 4 I n R Rx: Release I x: Iteration Seite 13

Kommunikationsprojekt Projektmanagement Planung Analyse Konzept Kommunikationskonzept

14 3. In Scrum wird ein leichtgewichtiger Prozess zur flexiblen Planung, Durchführung und Steuerung angeboten. Daily Meeting Projektstatus: Burndown Diagramm Probleme: Hindernisliste Vision Sprint Besprechungen User Stories: Solution Backlog Iterationsumfang: Sprint Backlog Fertige (Teil-)Lösung Lessons Learned Prognosetreffen Planungstreffen Review Retrospektive Seite 14

Daily Meeting Projektstatus: Burndown Diagramm Probleme: Hindernisliste Vision Sprint

15 4. In einer agilen Vorgehensweise steht das - in Planung und Durchführung - eigenverantwortliche Team im Mittelpunkt. Product Owner als inhaltlicher Treiber und Priorisierer Team: Planung und Umsetzung der Projektergebnisse mit einem selbstorganisierten Team Scrum Master als organisatorischer und methodischer Treiber des Themas und Teams (Coach) Seite 15

Product Owner als inhaltlicher Treiber und Priorisierer Team: Planung und Umsetzung der

16 Wann macht agiles Vorgehen Sinn? bei einer Vielzahl an Änderungen während des Projekts bei neuartigen Projekten mit unklaren Anforderungen für eine schnelle Teilauslieferung des Produkts bei einer Vielzahl an Interaktionspartnern Seite 16

neuartigen Projekten mit unklaren Anforderungen für eine

17 Scrum kann die geforderte Flexibilität auch in Nicht-IT- Projekten erbringen Kleine Iteration helfen, schnelle (und wichtige) Erfolge zu erzielen Big Picture Vision ist wichtig - unscharfe Anforderungen sind dennoch verwendbar Flexibles Ende des Projekts möglich Schnelles Lernen durch kurze Zyklen für Team und Kunde Reduktion des Change-Management-Aufwands eines Projekts Seite 17

Anforderungen sind dennoch verwendbar Flexibles Ende des Projekts möglich Schnelles Lernen

18 aber die Mitarbeiter und Organisation müssen fit für die neue Vorgehensweise sein. Anpassen der fachlichen Methodik Abstimmung der inhaltlichen Vorgehensweise (z.b. Prozessoptimierungsprojekt) Training & Coaching für Mitarbeiter Planungs- und Durchführungsverantwortung als Team Einführung von neuen Rollen Product Owner und Scrum Master Change Management für die Organisation Anpassung der Organisationsstruktur Verankerung der PM-Vorgehensweise Seite 18

timmung der inhaltlichen Vorgehensweise (z.b.

19 Agiles Projektmanagement - auch geeignet für Nicht-IT-Projekte? Prof. Dr.-Ing. Holger Günzel Am Stadtpark München Holger.guenzel@hm.edu

Ähnliche Dokumente

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen