Professionelles Projektmanagement in der Praxis



Ähnliche Dokumente
Professionelles Projektmanagement in der Praxis

Professionelles Projektmanagement in der Praxis. Veranstaltung 6 Teil 4 ( ):

Professionelles Projektmanagement in der Praxis

Professionelles Projektmanagement in der Praxis. Veranstaltung 5 Teil 3 ( ):

Professionelles Projektmanagement in der Praxis

Professionelles Projektmanagement in der Praxis

Agile Softwareentwicklung mit Scrum

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 ( ):

Praktische Erfahrungen beim Einsatz des Vorgehensmodells "SCRUM" bei AGFA HealthCare

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

SCRUM. Legalisierung der Hackerei? GI Regionalgruppe Dortmund Dipl.-Inform. (FH) Dirk Prüter.

Sabotage in Scrum. dem Prozess erfolglos ins Knie schiessen. Andreas Leidig (andrena objects ag) Vortrag bei den XP Days 2007

Meetings in SCRUM. Leitfaden. Stand:

Taking RM Agile. Erfahrungen aus dem Übergang von traditioneller Entwicklung zu Scrum

Agile Programmierung - Theorie II SCRUM

Sollten folgende drei Fragen durch das Team positiv beantwortet werden, sind wichtige SCRUM-Elemente in Ihrem Team erfolgreich installiert.

Wir erledigen alles sofort. Warum Qualität, Risikomanagement, Gebrauchstauglichkeit und Dokumentation nach jeder Iteration fertig sind.


Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

SCRUM. Software Development Process

Agile Entwicklung nach Scrum

Einführung in das Scrum Framework & welche 10 Praktiken helfen, Scrum wirklich gut zu machen

Scrum. Übung 3. Grundlagen des Software Engineerings. Asim Abdulkhaleq 20 November 2014

Agile Software Development

Scrum. Agile Software Entwicklung mit. Agile Software Entwicklung mit. Scrum. Raffael Schweitzer 18. November 2003

Projektmanagement durch Scrum-Proxies

Projektmanagement Vorlesung 12/ 13

Scrum undprojektmanagement à la GPM. Markus Schramm compeople AG Frankfurt

Projektplan. Software Engineering Projekt. November 11 Fachbereich Informatik Software Engineering Projekt Sebastian Proksch 1

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

Projektstart für Auftraggeber und Entscheider. Bern, 27. August 2013

Scrum in der Praxis (eine mögliche Umsetzung)

Leitfaden zum Erstellen der Projektarbeit

Projektmanagement Vorlesung 14/ 15: Wiederholung ausgewählter Themen zur Klausurvorbereitung. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Gelebtes Scrum. Weg vom Management hin zur Führung

Erfahrungsbericht Agile Entwicklung einer BI Anwendung für das Meldewesen

Agile Management Einführung in agiles Management

Agile Softwareentwicklung

Transferprojekt zum Projektmanagement Fachmann /-frau GPM/IPMA Level D

Hilfe, mein SCRUM-Team ist nicht agil!

Projektmanagement. Vorlesung von Thomas Patzelt 8. Vorlesung

Andrea Grass & Dr. Marcus Winteroll oose Innovative Informatik GmbH. Geschäftsprozessmanagement und Agilität geht das zusammen?

Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung

Projektmanagement in der Spieleentwicklung

oose. Was (noch) klassische Projekte von Scrum & Co lernen können eine empirische Studie

Globale Scrum Retrospektive

Effiziente Steuerung von BI-Projekten - Agiles Projektmanagement vs. klassische Vorgehensmodelle. Windhoff Software Services GmbH

Michael Franken. Serum für bummies. Übersetzung aus dem Niederländischen (/on Susanne Bonn. WlLEY. WILEY-VCH Verlag GmbH & Co.

Informationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:

Zuckerbrot oder Peitsche

Agile Enterprise Development. Sind Sie bereit für den nächsten Schritt?

The big picture: Prince2 featuring SCRUM. Bernd Lehmann, Prince2-Tag Köln, 12. Mai 2011

PROJEKTMANAGEMENT GRUNDLAGEN_2

Trotz Agilität nicht ins Abseits geraten Modellierung in einem agilen Umfeld. Susanne Mühlbauer, Philip Stolz, HOOD GmbH MID Insight 2012

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Dokumentation. Projekt: Innovation Management Plattform To Activate Creative Thoughts

Das Wasserfallmodell - Überblick

Projektmanagement. Einleitung. Beginn. Was ist Projektmanagement? In dieser Dokumentation erfahren Sie Folgendes:

Projektmanagement Leitfaden für Organisations- u. Verbesserungsprojekte

Checkliste: Projektphasen

Agile Prozessverbesserung. Im Sprint zu besseren Prozessen

Projektmanagement. Muster-Projekthandbuch

Agile Softwareentwicklung. Referat von Kristina Schrickel Praxisprojekt Ruby Leitung : Ralf Berger

POCKET POWER. Projektmanagement. 3. Auflage

Scrum mit User Stories

Unsere These: Meilensteindefinitionen sind wichtig für die Projektplanung und die Bewertung des Projektstatus.

Umfrage zum Informationsbedarf im Requirements Engineering

Agiles Design. Dr.-Ing. Uwe Doetzkies Gesellschaft für Informatik mail:

Projektsteuerung Projekte effizient steuern. Welche Steuerungsinstrumente werden eingesetzt?

Projektplanung für Softwareprojekte: KLIPS 2.0 Prof. Dr. Manfred Thaller WS 2011/ Dana Wroblewski

Einführung in Scrum. Agiles Projektmanagement. Martin Krüger Entwicklung von Workflowanwendungen

Formularsammlung. zum methodischen Leitfaden. für eine effiziente Projektarbeit in. virtuellen Teams mit teamspace

Machbar? Machbar!

«PERFEKTION IST NICHT DANN ERREICHT, WENN ES NICHTS MEHR HINZUZUFÜGEN GIBT, SONDERN DANN, WENN MAN NICHTS MEHR WEGLASSEN KANN.»

Scrum ist ein agiles Framework zur Software-Entwicklung. SCRUM bei Festo. Was ist SCRUM? Frank M. Hoyer, House of Software

Der Business Analyst in der Rolle des agilen Product Owners

Scrum for Management Praxis versus Theorie oder Praxis dank Theorie. ALM Day 26.Oktober 2011 Urs Böhm

Fragebogen: Abschlussbefragung

Inhaltsverzeichnis. Ralf Wirdemann. Scrum mit User Stories ISBN: Weitere Informationen oder Bestellungen unter

Water-Scrum-Fall Ein Entwicklungsprozess mit Zukunft? Bernhard Fischer

10 Jahre agile Softwareentwicklung Wie erwachsen sind wir geworden?

Teamaufstellung - Zwischen Dream und Nightmare

AGILE SOFTWAREPROJEKTE IN REINFORM WAS BEDEUTET DAS RECHTLICH? RA Daniel Schätzle Berlin, 22. April 2015

READY-STEADY-DONE! Der Product Owner are you READY for agile?!

IT-Basics 2. DI Gerhard Fließ. Vorgehensmodelle

PROJEKTCOACHING Thomas Kettner

GPP Projekte gemeinsam zum Erfolg führen

SPC Lehrgang Projektmanagement Basic

Softwareentwicklungsprozesse optimieren. wie Sie die Vorteile klassischer und agiler Methoden erfolgreich kombinieren

Prozessoptimierung. und. Prozessmanagement

07. November, Zürich-Oerlikon

arbeitspaketbasierendes Projektmanagement im Anlagenbau: Smart Pro Webinar: Christian Eichlehner, Anton Lorenz Primas CONSULTING

Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen. Wir bringen Qualität. Wir beraten Sie. Wir unterstützen Sie. Wir schaffen Lösungen

SmartPM Toolbox. Tool 007: Bluesheet

Projektmanagement. Agile Vorgehensweise / Scrum. Version: 1.0 Stand:

Wie Projekte im Bürgerschaftsengagement gelingen können. Projektmanagement

Agiles Projektmanagement nach Scrum mit Projektron BCS - Erfahrungsaustausch -

Unsere Kunden erzählen keine Geschichten. Ursula Meseberg microtool GmbH Berlin

Projektmanagement. Projekte erfolgreich führen! Patrick Frontzek

Projektmanagement. Bern, 15. März Hans Peter Gächter

Transkript:

Institute of Computer Science Chair of Communication Networks Prof. Dr.-Ing. P. Tran-Gia Vorlesung Professionelles Projektmanagement in der Praxis Prof. Dr. Harald Wehnes Veranstaltung 10 (29.06.2015): Projektreview, Projektabschluss, Projektinkasso Besonderheiten von Softwareprojekten, Agiles Projektmanagement Konflikt- und Krisenmanagement SS 2015

Agenda (29.06.2015) Organisatorisches: Termine, Projektexposé/-broschüre, Projektbericht, Zertifizierungsprüfung Präsentationen PL der Teams 5, 7 und 8 (Aufgabe 9) Projektreview, Projektabschluss, Projektinkasso Aufgabe 10 (letzte Aufgabe der Vorlesung) Besonderheiten von Softwareprojekten, Agiles Projektmanagement Konflikt- und Krisenmanagement Wichtiger Hinweis: Vorlesungsumfrage SS 2015 Institut für Informatik Einladungs-Emails wurden in der letzten Woche verschickt. Bitte nehmen Sie teil! Vielen Dank Professionelles Projektmanagement in der Praxis 2 2 2

Termine Vorträge Team 27.04.2015 04.05.2015 18.05.2015 01.06.2015 08.06.2015 15.06.2015 22.06.2015 29.06.2015 06.07.2015 13.07.2015 Pre-Prototype- Abnahme Projekt-Abnahme 1 x x x x x x 2 x x x x x x 3 x x x x x 4 x x x x x x 5 x x x x x x 6 x x x x 7 x x x x x x x 8 x x x x x x x 9 x x x x Abschlussveranstaltung (Dauer: ca. 3 h): 13.07.2015, 13:00 Uhr Klausur (Dauer: 80 Minuten): 20.07.2015, 12:00 Uhr Zuse-HS PM-Zertifizierung (Dauer: 120 Minuten): 20.07.2015: 15:00 Uhr, HS 4 Professionelles Projektmanagement in der Praxis 3 3 3

Projektexposés / Projektbroschüre Alle Exposés liegen vor Zusammenfassung zur Projektbroschüre 2015 für die Presse und externe Teilnehmer der Abschlussveranstaltung (Frau Lesch) Professionelles Projektmanagement in der Praxis 4 4 4

Projektbericht 1. Projekt / Projektziele 2. Projektumfeld, Stakeholder 3. Risikoanalyse 4. Projektorganisation, Kommunikation 5. Phasenplanung, Meilensteine 6. Projektstrukturplan, Arbeitspakete 7. Ablauf- und Terminplanung 8. Einsatzmittel- / Kostenplanung 9. Lessons Learned 9. Verhaltenskompetenz 10. Wahlelemente Anhang Zu jedem Abschnitt (PM-Element) Einleitende kurze Beschreibung der Theorie / PM-Methodik Beispiel: Warum macht man eine Projektzieldefinition? Wie geht man dabei vor? Was ist besonders zu beachten? Beschreibung des konkreten Vorgehens im Projekt Wie wurden die Projektziele ermittelt, klassifiziert etc.? Beschreibung der erzielten Ergebnisse und Erfahrungen Tabellarische Darstellung der Projektziele mit Erläuterungen, Zielhierarchie, Zielbeziehungen, Reflektion! Der Projektbericht Ihres Teams ist das einzige für die Klausur zugelassene Hilfsmittel! Professionelles Projektmanagement in der Praxis 5 5 5

Aktueller Status der Projektberichte Einleitende Beschreibung der Theorie / PM-Methodik gut bis vorbildlich Beschreibung des konkreten Vorgehens im Projekt teilweise noch ausbaufähig bis vorbildlich Beschreibung der erzielten Ergebnisse und Erfahrungen teilweise noch ausbaufähig (Ergebnisdarstellungen sind vorhanden, aber ohne erläuternden Text) bis vorbildlich Hinweise: Rechtschreibung prüfen Durchgängiger Schrifttyp und größe Nicht Beispiele der Vorlesung als Projektergebnisse Professionelles Projektmanagement in der Praxis 6 6 6

Aufgabe 9: Projektorganisation 1. Begründen Sie die von Ihnen gewählte Organisationsform für Ihr Projekt und stellen Sie Ihre Projektorganisation grafisch dar 2. Erstellen Sie eine Verantwortungsmatrix ABV-Matrix.xls mit Aufgaben Befugnissen Verantwortung 3. Führen Sie im nächsten JF wieder eine Statusbetrachtung mit MTA-Aktualisierung und Fortschrittslinie durch 4. Analysieren Sie die Abweichungen zwischen IST- und PLAN-Daten und treffen Sie Steuerungsmaßnahmen Professionelles Projektmanagement in der Praxis 7 7 7

Zertifizierungsprüfung Voraussetzungen Nachweis einer Projektmanagementausbildung im Umfang von mindestens 24 Präsenzstunden (à 60 Minuten) oder 32 Unterrichtsstunden (à 45 Minuten) an einer anerkannten Hochschule Anforderungen werden durch die Lehrveranstaltung PPM erfüllt 2-stündige schriftliche Zertifizierungsprüfung ohne Pause Fragenkomplex aus 5 Gruppen (120 Punkte) Aufgabe 1: Ja/Nein Fragen (10 Punkte) Aufgabe 2: Offene Fragen (Text) (50 Punkte) Aufgabe 3: Zeichnen Sie die Diagramme (40 Punkte) Aufgabe 4: Netzplan und Balkenplan (10 Punkte) Aufgabe 5: Sachlich-logische Reihenfolge (10 Punkte) 60 Punkte (= 50%) erforderlich zum Bestehen Professionelles Projektmanagement in der Praxis 8 8 8

Prüfungsschwerpunkte 1.12 Ressourcen 1.15 Konfiguration und Änderungen 1.19 Projektstart 1.20 Projektabschluss Professionelles Projektmanagement in der Praxis 9 9 9

Anmeldeverfahren Antrag zur Zertifizierung am Rechner ausfüllen und beim Dozenten abgeben Dozent sammelt und leitetet die Anträge (mit den Klausuren) an Zertifizierungsstelle PM Zert PM Zert wertet Klausuren aus, erstellt und übersendet die Zertifikate an die angegebene Anschrift Optional: Studentische Mitgliedschaft Abgabe des Antrags mit Immatrikulationsbescheinigung beim Dozenten Erhalt personalisierter e-book-schlüssel per Mail Weitere Informationen: http://www.gpm-ipma.de/qualifizierung_zertifizierung/basiszertifikat_fuer_projektmanagement_gpm.html Professionelles Projektmanagement in der Praxis 10 10 10

Konditionen für Studierende staatlicher Hochschulen Das Basiszertifikat Projektmanagement (GPM) hat keine zeitliche Befristung Professionelles Projektmanagement in der Praxis 11 11 11

Vorteile für studentische GPM-Mitglieder Professionelles Projektmanagement in der Praxis 12 12 12

Agenda (29.06.2015) Organisatorisches: Termine, Projektexposé/-broschüre, Projektbericht, Zertifizierungsprüfung Präsentationen PL der Teams 5, 7 und 8 (Aufgabe 9) Projektreview, Projektabschluss, Projektinkasso Aufgabe 10 (letzte Aufgabe der Vorlesung) Besonderheiten von Softwareprojekten, Agiles Projektmanagement Konflikt- und Krisenmanagement Professionelles Projektmanagement in der Praxis 13 13 13

Projektverlauf: Phasenkonzept Projekt läuft in mehreren Phasen ab Initialisierung Definition Planung Durchführung Abschluss Idee Aufgaben des Projektleiters ändern sich stark während der Laufzeit des Projektes Projekt- Ergebnis Professionelles Projektmanagement in der Praxis 14 14 14

Projektbewertungen Projekt Abschlussphase Projektreview Projektabschluss Projektinkasso t Projektreview: im Projektverlauf Projektabschluss: am Projektende Projektinkasso: mit angemessenem zeitlichen Abstand zum Projektende Professionelles Projektmanagement in der Praxis 15 15 15

Projektreview Nachbetrachtung einer wichtigen abgeschlossenen Projektphase: Standortbestimmung Reviewteam; kann ggf. von einem Externen geleitet werden Analyse der erreichten Ergebnisse Bewertung des bisherigen Projektverlaufs Diskussion von Problemen/Schwachstellen Lernen für den weiteren Projektverlauf Was war besonders gut und sollte verstärkt werden? Was lief bisher nicht so gut und muss verändert werden? Ermittlung von Verbesserungsbedarf Ergebnis: Review-Bericht Projektreviews sind ein wesentlicher Bestandteil des Projekt- Qualitätsmanagements (syn. Projektassessments, Projektaudits) Professionelles Projektmanagement in der Praxis 16 16 16

Praxis: Projektreviews im Rahmen des Projektes NIMBUS Bewertungen durch das Projektteam (Web-Befragung) Projektleitung und prozesse Individuelles Projektbild Stimmungsbarometer Listen Was läuft besonders gut und sollte ausgebaut werden? Welche Mängel werden gesehen? Optimierungsvorschläge für den weiteren Projektverlauf Auswertung der Projektmitarbeiter-Befragungen durch das Kernteam Maßnahmen (Konsequenzen) für den weiteren Projektverlauf identifizieren, priorisieren und festlegen Maßnahmen umsetzen und Wirksamkeit controllen Professionelles Projektmanagement in der Praxis 17 17 17

Review: Projektteam (1) Professionelles Projektmanagement in der Praxis 18 18 18

Review: Projektteam (2) Professionelles Projektmanagement in der Praxis 19 19 19

Review: Projektteam (3) Professionelles Projektmanagement in der Praxis 20 20 20

Review: Projektteam (4) Professionelles Projektmanagement in der Praxis 21 21 21

Projektabschluss: Inhalte Ziel: Erfolgreicher Abschluss des Projektes Formaler Projektabschluss Übergabe der Projektergebnisse an die Linie Projektabschluss-Workshop Projektabnahme durch den Auftraggeber, Entlastung der Projektleitung Freigabe der Projektmitglieder und -ressourcen, Auflösung der Projektorganisation Erhebung der Zufriedenheit der Stakeholder (Feedbacks) Erstellung und Veröffentlichung des Projektabschlussberichtes Erfahrungssicherung Analyse Projektverlauf & Projektergebnisse Erfahrungssicherung für Folgeprojekte Professionelles Projektmanagement in der Praxis 22 22 22

Projektabschluss-Dokumentation Produktdokumentation (z.b. Betriebshandbuch, Benutzeranleitung) Teil der Projektabnahme Prüfung auf Verständlichkeit und Vollständigkeit Projektabschlussbericht / Projektbericht Zusammenfassung des Projektverlaufs (Ausgangslage, Vorgehensweise) Darstellung der Projektergebnisse: erbrachte Leistungen, Termine, Kosten, Erfahrungen, Projektfortführung in der Line Projektdokumentationen Strukturierte Ablage von Beginn an erforderlich Überholte Dokumente am Projektende ausmisten Archivierung aller wichtigen Unterlagen (Haftung!) Abschlussbericht Professionelles Projektmanagement in der Praxis 23 23 23

Abnahmetests Üblich bei Softwareprojekten Überprüfungen zur Anwendung Installation und Tests in Testumgebung _ Plausibilität der Ergebnisse Vollständigkeit der Funktionalitäten Erfolgreiche Massentests (möglichst mit Echtdaten) Gutes Performanceverhalten (Antwortzeiten, Verarbeitungszeiten) bei realistischen Datenmengen Störungsfreier Wiederanlaufs nach Abbruch Vollständigkeit der Dokumentation Auftraggeber-Verantwortung Aufbau der Testumgebung Bereitstellung von Testfällen/-daten Organisation von Anwendern, für Funktions- bzw. Massentests PL Verantwortung AG Professionelles Projektmanagement in der Praxis 24 24 24

Ressourcen-Freigabe und Auflösung der Projektorganisation Ressourcen: Mitarbeiter, Räume, Rechner etc. sind nur für einen bestimmten Zeitraum bereitgestellt müssen wieder freigegeben werden ggf. Verträge für Räume, Geräte usw. kündigen Zielkonflikt beim Projektende Erfahrenes Team muss das Projekt erfolgreich zu Ende führen Projektmitarbeiter wollen Sicherheit und orientieren sich auf Rückkehr in die Linie bzw. auf neue interessante Aufgaben Projektleiter besonders gefordert Projektende und Auflösung des Teams gemeinsam planen Professionelles Projektmanagement in der Praxis 25 25 25

Lessons Learned Ziel: Erfahrungssicherung Zeitpunkt ist günstig Erfahrungen sind noch frisch Lessons Learned : Essentielle Erfahrungen für neue Projekte sammeln, auswerten und sichern Verwendete Templates / Checklisten optimieren Leitfragen Was war besonders gut und sollte für Folgeprojekte übernommen werden? Welche Planänderungen gab es, und was waren die Ursachen? Welche Checklisten / Templates sind zu ergänzen/ändern? Was sollte bei einem ähnlichen neuen Projekt anders gemacht werden? Professionelles Projektmanagement in der Praxis 26 26 26

Projektabschluss-Workshop (Kickout) Kritische Bewertung und Würdigung Zusammenarbeit Projektteam, Projektleitung Projektergebnis Projektverlauf Identifikation von Restaufgaben und Regelung für deren Erledigung Gemeinsame Analyse der aufgetretenen Schwierigkeiten und Planabweichungen Feedback-Abfrage der Projektmitarbeiter zum Projekt (Ergebnisse und Verlauf) Kickout mit Abschluss-Event Professionelles Projektmanagement in der Praxis 27 27 27

Projektabschluss-Präsentation Zielgruppe: Auftraggeber / Lenkungsausschuß Primäres Ziel: Projektabnahme Inhalt der Präsentation Gegenüberstellung: Ergebnisse Ziele Zusätzlicher Nutzen (Erfolge) des Projektes Durchgeführte Arbeiten (nur im groben Überblick) Stellenwert der Präsentation Sehr hoch Konsequenz Intensive Vorbereitung Abstimmung der Präsentation mit den Teammitgliedern Professionelles Projektmanagement in der Praxis 28 28 28

Praxis-Beispiel: Überführung des Projektes NIMBUS in die Linie (Workshop vom 23.01.08) Workshopziele Sicherstellung eines reibungslosen Übergangs von der Projektverantwortung in die Linienverantwortung Identifikation offener Themen, die in der Linie weiterbearbeitet werden müssen Erwartete Ergebnisse To-Do-Liste für die Aufgabenübergabe Liste offener Themen Agenda Vorstellung NIMBUS: Ziele, Organisation, Ergebnis-Status (We.) Status der Teilprojekte und Themen für die Übergabe 1. Anwendungen (Z.) 2. Arbeitsplatzsysteme (S.) 3. Datennetz (Ri.) 4. Qualifizierung, Dokumentation, Kommunikation (Rö.) 5. Server (F.) 6. Support (H.) 7. Systemmanagement (M.) 8. NIMBUS-Tools (Wa.) Fragen, Diskussion und Abstimmung(en) zu offenen Themen Gruppenarbeiten: Aufgaben definieren, zuordnen und terminieren (To-Do-Liste) Plenum: Präsentation und Diskussion der Gruppenergebnisse Professionelles Projektmanagement in der Praxis 29 29 29

Praxis-Beispiel: Projektabschlussphase NIMBUS Workshops zur Übergabe der Projektergebnisse an die Linie Abschlusspräsentation und Projektabnahme im Lenkungsausschuss (separater Foliensatz) Abschlussworkshop mit Erfahrungssicherung des Projektteams (separater Foliensatz) Professionelles Projektmanagement in der Praxis 30 30 30

Praxis-Beispiel: Projektabnahme durch Lenkungsausschuss Agenda 1. Projektablauf (Gesamtüberblick) 2. Gegenüberstellung Ziele / Zielerreichung 3. Projektcontrolling 4. Kosteneinsparungen und Nutzengewinn 5. Innovationen in NIMBUS 6. Lessons learned 7. Benchmark mit prämiertem Vergleichsprojekt 8. Abnahme des Projektes 9. Bewerbung Project Excellence Award 2008 Professionelles Projektmanagement in der Praxis 31 31 31

Praxis-Beispiel Projektabschluss-Workshop: Ziele Gegenüberstellung Was waren die Projektziele? Was haben wir erreicht? Projektnachbetrachtung: Sichern der Projekterfahrungen für Folgeprojekte Was ist besonders gut gelaufen und sollte für Folgeprojekte übernommen werden? Was ist weniger gut gelaufen und sollte bei Folgeprojekten anders gemacht werden? Identifikation von Restaufgaben Klärung offener Fragen Überführung des Projektes in die Linie Würdigung der Leistungen der Projektteam-MitarbeiterInnen Professionelles Projektmanagement in der Praxis 32 32 32

Praxis-Beispiel Projektabschluss-Workshop: Agenda I. Projektergebnisse (Präsentationen; je 8-10 Minuten) (13 15:15 Uhr) Projektleitung (Harald W., Emeran P.) Projektcontrolling (Emeran P.) TP Anwendungen (Harald Z.) TP Arbeitsplatzsysteme (Christian S.) TP Datennetz und Netzwerküberwachung (Robert H.) TP Qualifizierung (Bernhard R.) TP Server (Jörg F.) und Beleglesung (Uwe F.) TP Support (Rainer H./ Emeran P.) TP Systemmanagement (Hubert M.) Rollout im Überblick (Manfred S.) II. Organisatorisches 15:30 16:00 Uhr III. Projektnachbetrachtung (1. in den Teilprojektteams; 2. im Plenum) (16:00/ 16:30/ 17:30) Was lief besonders gut im Projekt/Teilprojekt? Was lief nicht so gut im Projekt/Teilprojekt und sollte bei Folgeprojekten anders/besser gemacht werden? Welche Projektergebnisse sind besonders exzellent? Welche offenen Punkte gibt es und wie wir damit umgegangen? IV. Überführung von NIMBUS in die Linie (Ergebnisse vom 23./24.1.2008) (18:00 18:30) ab 19:00 Feierstunde zur Würdigung der exzellenten Projektarbeit mit Büffet und Kabarett Kaiserschmarrn Professionelles Projektmanagement in der Praxis 33 33 33

Praxis-Beispiel: Lessons Learned Besondere NIMBUS-Erfahrungen für Folgeprojekte und Linienarbeit Professionelles Projektmanagement (Stakeholder-, Kommunikations-, Qualitäts-, Risikomanagement usw.) sorgt für klares ergebnisorientiertes Vorgehen Sehr gute Kommunikation und partnerschaftlicher Umgang der Projektteams fördert den Projekterfolg Neue Kommunikationsplattform Projektportal (Informations- und Dokumentenmanagement) mittels SharePoint hat sich sehr bewährt Feedbackmanagement (Anwenderbewertung, Projektmitarbeiter bewerten Projektleitung und Projektmanagementprozesse) zeigt Schwachstellen und Handlungsbedarf auf Eine frühzeitige aufgabenbezogene Qualifizierung der Mitarbeiter ist essenziell Der TOP Problem of the day hat sich als Besprechungsschwerpunkt für Statusmeetings sehr bewährt Weitergabe der Erfahrungen Projektleitermeetings PM-Qualifizierungskonzept (Weiterbildungsprogramm) Ergänzungen im Projektmanagement-Portal (Vorlagen, Muster-Beispiele) Vorlesung Professionelles PM, Uni Würzburg Vorträge, Tagungsbeiträge, Case Study Professionelles Projektmanagement in der Praxis 34 34 34

Projektinkasso Häufige Situation: Projekterfolg tritt mit zeitlicher Verzögerung zum Projektendtermin ein Initialisierung Definition Planung Durchführung Abschluss Projektinkasso Ist der erwartete (prognostizierte) Nutzen - in der geplanten Höhe - wirklich eingetreten? Vorgehen Wirtschaftlichkeitsbetrachtung (Kosten vs. Nutzen) mit Ist-Daten durchführen (z.b. Projektleiter/ Linienverantwortlicher mit Project Office / Zentrales Projektbüro) Ggf. Maßnahmen erarbeiten, um Nachhaltigkeit des Projekterfolgs zu sichern Bericht/Entscheidung an Auftraggeber / LA / Steuerkreis Erfahrungssicherung für Folgeprojekte ca. 1 Jahr Professionelles Projektmanagement in der Praxis 35 35 35

Aufgabe 10: Projektstatus und Lessons learned Erarbeiten Sie im nächsten JF 1. Status-Betrachtung mit MTA-Aktualisierung und aktueller Fortschrittslinie mit Analyse der Abweichungen zwischen IST- und PLAN-Daten. (Was sind Ihre Steuerungsmaßnahmen?) 2. Lessons learned-betrachtung Welche Erfahrungen haben Sie gesammelt? Welche Probleme sind aufgetreten und wie haben Sie diese gelöst? Was ist besonders gut gelaufen und warum? Was würden Sie beim nächsten Mal anders machen? Erfahrungen in der Teamarbeit Erfahrungen in der Planung und Aufwandsschätzung Erfahrungen in der Projektdurchführung und Steuerung Erfahrungen mit Risikomanagement Erfahrungen beim Einsatz von MS Project Empfehlungen für zukünftige Projekte Professionelles Projektmanagement in der Praxis 36 36 36

Gliederung der Präsentation (Vorschlag) Agenda Kurzvorstellung des Projektes (Steckbriefdaten) Projektstatus MTA MS Project-Darstellung mit Fortschrittslinie Analyse von Planungsabweichungen und Steuerungsmaßnahmen Nächste Schritte mit Prognose zu Ergebnis-, Zeit- und Kostenzielen Projekterfahrungen (Lessons learned) Projektarbeit Projektkommunikation Projektrisikomanagement Verwendung von MS Project Empfehlungen für zukünftige Projekte Professionelles Projektmanagement in der Praxis 37 37 37

Termine zur Aufgabe 10 04.07.2015 Uploads Präsentation: A10_Team_x 8. JF Protokoll: P8_Team_x.doc Projektbericht: Projektbericht_9_Team_x.doc 06.07.2015 (Vorlesung) Präsentationen: Teams 7 und 8 Professionelles Projektmanagement in der Praxis 38 38 38

Projektbericht: Kapitel 9 9 Lessons learned 9.1 Erfahrungen in der Teamarbeit 9.2 Erfahrungen in der Planung 9.3 Erfahrungen in der Projektdurchführung und Steuerung 9.4 Erfahrungen mit Risikomanagement 9.5 Erfahrungen beim Einsatz von MS Project 9.6 Empfehlungen für zukünftige Projekte Professionelles Projektmanagement in der Praxis 39 39 39

Agenda (29.06.2015) Organisatorisches: Termine, Projektexposé/-broschüre, Projektbericht, Zertifizierung Präsentationen PL der Teams 5, 7 und 8 (Aufgabe 9) Projektreview, Projektabschluss, Projektinkasso Aufgabe 10 (letzte Aufgabe der Vorlesung) Besonderheiten von Softwareprojekten, Agiles Projektmanagement Konflikt- und Krisenmanagement Professionelles Projektmanagement in der Praxis 40 40 40

Schlechtes Image von Softwareprojekten IT-Projekte haben ein schlechtes Image: 100% 90% 80% 31 40 28 23 15 18 19 24 Abgebrochen 70% 60% 50% 40% 53 33 46 49 51 53 46 44 Zeit u/o Budget überschritten u/o gewünschte Qualität nicht erfüllt 30% 20% 10% 0% 34 35 27 26 28 29 32 16 1994 1996 1998 2000 2002 2004 2006 2008 Erfolgreich beendet Quelle: Standish Group Die Hälfte aller IT-Projekte kosten doppelt bis dreifach so viel wie veranschlagt Quelle: Universität St. Gallen Professionelles Projektmanagement in der Praxis 41 41 41

Warum diese gewaltigen Probleme in der IT-Branche? Workshopteil Projektmanager unterschätzt den Aufwand der für Projektentwickler anfällt Qualität von Code schwer einschätzbar Unvollständige Aufgabenbeschreibung Immer wieder neuere Technologien Nach unten korrigierte Schätzwerte um den Auftrag zu erhalten Abhängigkeit von externen Bibliotheken Hohe Komplexität von Softwareprojekten Zu hohe Ansprüche / falsche Vorstellungen von Kunden Professionelles Projektmanagement in der Praxis 42 42 42

Welche Lösungsansätze sehen Sie? Vorsicht bei der Auswahl der Technologie Meinung von erfahrenen Entwicklern mit einbeziehen Fokus auf kompetentes Personal Aufklärung der Kunden über die Komplexität Kundenkommunikation Workshopteil Keine Schätzung von großen AP, sondern Aufteilung in kleinere überschaubare APs Professionelles Projektmanagement in der Praxis 43 43 43

Komplexität und Risiken von Softwareprojekten Kleine Ursachen a dramatische Konsequenzen: DO 3 I = 1.3 statt DO 3 I = 1,3 a Verlust der Venussonde Mariner-1 (1962) Konvertierungsfehler a Absturz von ARIANE 5 (4.6.1996) Hohe Erwartungen der Auftraggeber/Anwender Instabile Anforderungen und Ziele Dynamischer Markt Funktionalitäten nicht eindeutig definiert Neue Technologien, z.b. neue Versionen (Betriebssystem, Tools), während der Projektlaufzeit Viele Schnittstellen zu bereits vorhandenen Systemen Professionelles Projektmanagement in der Praxis 44 44 44

Vorgehensmodelle in der Softwareentwicklung Ein Vorgehensmodell ist eine standardisierte Vorgehensweise in definierten Phasen für die Softwareentwicklung Vorgehensmodelle definieren viele Aktivitäten und bilden damit einen generischen PSP mit Zielen und Voraussetzungen Erforderliche Inputs und ihre Anforderungen Ergebnissen und Abschlusskriterien Klassische Modelle: Wasserfall-Modell, V-Modell Modernere Ansätze: Spiral-Modell, OO-Entwicklung, V-Modell XT, Rational Unified Process (RUP) Agile Methoden: extreme Programming (XP), Scrum, Adaptive Software Development (ASD), Feature Driven Development (FDD), Test Driven Development (TDD), Crystal, Kanban Professionelles Projektmanagement in der Praxis 46 46 46

Wasserfall-Modell Systemanforderungen Softwareanforderungen Analyse Jede Phase ist zu bearbeiten Rückkoppelung nur eine Stufe + Einfach, leicht erlernbar + Langjährig erprobt + Schätzmodelle verfügbar + Sehr gut strukturiert Design - Änderung von Anforderungen was in der Praxis üblich ist werden vom Modell nicht berücksichtigt - Integration der Module erst gegen Projektende birgt Risiken - Lange Projektlaufzeiten zu erwarten Programmierung Test Einführung/Wartung Professionelles Projektmanagement in der Praxis 47 47 47

V-Modell mit Testansatz Anforderungsdefinition Anwendungsszenarien Abnahmetest Validierung Grobentwurf Testfälle Systemtest Verifikation Feinentwurf Testfälle Integrationstest Modul- Implementierung Testfälle Modultest Professionelles Projektmanagement in der Praxis 48 48 48

Prototypen-Modell Prototyp spezifizieren Prototyp erstellen experimentieren Prototyp akzeptiert? nein ändern / erweitern ja Reduktion des Entwicklungsrisikos: Sicherstellung der Realisierbarkeit Schnelles Erstellen einer lauffähigen Anwendung, die ausgewählte Eigenschaften des Zielproduktes besitzt Einbeziehung der späteren Anwender bei der Gestaltung der Benutzerschnittstelle Praktischer Testeinsatz Anwendungsarten Demonstrationsprototyp Machbarkeitsprototyp Exploratives Prototyping bei kritischen Teilproblemen Professionelles Projektmanagement in der Praxis 49 49 49

Objekt-orientiertes Modell Ansatz Fokus auf Wiederverwendung auf verschiedenen Ebenen Architektur zuerst Vorgehensweise meist iterativ mit Prototyping Einsatz von objektorientierter Analyse (OOA), Design (OOD), Implementierungsmethoden und Tools (OOP) Vorteile Verbesserte Produktivität und Qualität Späte Änderungen und Erweiterungen sind einfacher machbar Nachteile Wiederverwendungskultur muss erlernt und akzeptiert werden Sehr hoher Schulungsaufwand Teilweise noch gewisse Skepsis/ Zurückhaltung in der Praxis Professionelles Projektmanagement in der Praxis 50 50 50

Spiral-Modell (Boehm) Kumulative Kosten Projektfortschritt Festlegung von Zielen, Lösungsvarianten, Nebenbedingungen und Einschränkungen Integrationund Testplan Detailentwurf Lebenszyklusplan RA PT 1 Risikoanalyse Risikoanalyse Risikoanalyse Proto- Typ 2 Software entwurf Erarbeitung und Beurteilung von Lösungsvarianten, Erkennen und Beseitigen von Risiken Proto- Typ 3 Pilotsystem Softwareanforderungen Vorgehensmodell Entwicklungsplan Planung der nächsten Phase Abnahme Entwicklung und Validierung des Produkts der nächsten Stufe Professionelles Projektmanagement in der Praxis 51 51 51

Spiral-Modell: Vor- und Nachteile Vorteile Höhere Flexibilität: Fehlende Funktionen und Fehler werden früh erkannt Gemeinschaftliche iterative Entwicklung mit den Endanwendern auf der Basis von Prototypen Verkürzung der Entwicklungszeit bis zum ersten Produkt Erfahrungen über den praktischen Einsatz des Systems können bei der Weiterentwicklung berücksichtigt werden Nachteile Erstes Produkt noch unvollständig; Gefahr eines dauerhaften, schlechten Images Falls wesentliche Anforderungen fehlen oder die Systemarchitektur überarbeitet werden muss, kann dies extrem teuer werden Nur für firmeninterne Projekte geeignet Professionelles Projektmanagement in der Praxis 52 52 52

Agenda: Agile Softwareentwicklung mit Scrum Warum agile Softwareentwicklung? Prinzipien und Merkmale agiler Methoden Scrum im Überblick Scrum-Prozess Rollen Meetings Artefakte / Dokumente Professionelles Projektmanagement in der Praxis 53 53 53

Agile Softwareentwicklung mit Scrum Wem sagt der Begriff Agile Softwareentwicklung etwas? Wer hat davon schon einmal von Scrum ( Gedränge ) gehört? Professionelles Projektmanagement in der Praxis 54 54 54

Warum Agile Softwareentwicklung? Kritik am Wasserfall-Modell Anforderungsdefinition Analyse Zu formal, zu starr Anforderungen ändern sich während der Projektlaufzeit Vielzahl von Regeln Dokumentenoverhead Entwurf Implementierung Test und als Ergebnis: verärgerte Kunden Professionelles Projektmanagement in der Praxis 55 55 55

Agile Manifest (2001): Grundprinzipien agiler SWE Individuen und Interaktionen Funktionierende Software Zusammenarbeit mit den Kunden Offenheit für Veränderungen Prozesse und Werkzeuge Umfangreiche Dokumentation Verhandlung von Verträgen Verfolgung eines detaillierten Plans Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas www.agilealliance.org Professionelles Projektmanagement in der Praxis 56 56 56

Das wäre das falsches Verständnis von agiler SWE! Planung: Es werden wiederholt Planungen durch geführt (nach jedem Iterationsschritt). Dabei fließen die bereits erzielten Erkenntnisse ein Dokumentation: Auch im agilen Projektmanagement muss dokumentiert werden; Umfang und Menge konzentrieren sich dabei auf das absolut Notwendige Professionelles Projektmanagement in der Praxis 57 57 57

Agile Methoden: Generelle Merkmale Die Entwicklung verläuft inkrementell mit häufiger Veröffentlichung neuer Versionen Die Entwicklung ist kooperativ: Kunden und Entwickler arbeiten beständig zusammen und kommunizieren dabei eingehend Die Entwicklung ist einfach in dem Sinne, dass die verwendete Methode schnell erlern- und veränderbar ist Die Entwicklung ist leicht anpassbar: Die Beteiligten können schnell und flexibel auf Änderungen reagieren Quelle: Abrahamsson, Pekka; Salo, Outi; Ronkainen, Jussi; Warsta, Juhani: Agile Software Development Methods: Review and Analysis. In: VTT Publications 478 (2002), S. 61 68 Professionelles Projektmanagement in der Praxis 58 58 58

Prinzip der kleinen Pyramide Klassisches Projektmanagement Ziel Plan Ergebnis Agiles Projektmanagement Ziel Plan Ergebnis Quelle: Philipp Meyerbröker: Das Prinzip der kleinen Pyramide Projekt Magazin 10/2010 Professionelles Projektmanagement in der Praxis 59 59 59

Grundprinzip von Scrum Scrum Master Scrum Team Daily Scrum Product Owner Sprint Planung Product Backlog Sprint Verwendbare Software Sprint Review passt auf einen Bierdeckel Quelle: Arne Roock: Scrum und Kanban sinnvoll kombinieren. Projekt Magazin 14/2011 Professionelles Projektmanagement in der Praxis 60 60 60

Rollen in Scrum Product Owner: verantwortlich dafür, dass die betriebswirtschaftlich richtigen Dinge gemacht werden ScrumMaster: sorgt für einen reibungslosen Prozess Scrum Team: erledigt die Arbeiten in Selbstorganisation Weitere Rollen im Umfeld: Management, Kunde (Auftraggeber), Anwender Professionelles Projektmanagement in der Praxis 62 62 62

Scrum Rollen: Der Product Owner Vertreter der Kundeninteressen Ist verantwortlich für den wirtschaftlichen Erfolg des Projekts Definiert die Produkt-Features Priorisiert Features abhängig vom Kundennutzen Bestimmt Auslieferungsdatum und Inhalt Passt Features und Prioritäten nach Bedarf für jeden Sprint an Akzeptiert oder weist Arbeitsergebnisse zurück Professionelles Projektmanagement in der Praxis 63 63 63

Scrum Rollen: Der ScrumMaster Verantwortlich, dass Scrum gelingt und die Regeln und Prinzipien von Scrum eingehalten werden Arbeitet mit dem Entwicklungsteam eng zusammen, gehört aber selber nicht dazu Räumt Hindernisse, die das Team von effizienter Arbeit abhalten, aus dem Weg Schützt das Team vor äußeren Störungen Moderiert Meetings Leitsatz: Dienen statt führen Professionelles Projektmanagement in der Praxis 64 64 64

Scrum Rollen: Das Scrum Team Verantwortlich für den Erfolg jedes einzelnen Sprints Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge Teamstruktur Typischerweise 5-9 Personen Funktionsübergreifend besetzt: Softwareentwickler, Tester, Designer, Qualitätssicherer etc. Team organisiert sich selbst Professionelles Projektmanagement in der Praxis 65 65 65

Scrum: Die traditionellen Rollen verändern sich Das Scrum Team organisiert sich selbst (Selbststeuerung). Im Team wird vereinbart, wer wann was macht und wer mit wem zusammenarbeitet. Quelle: http://www.pentaeder.de/wp-content/uploads/pm-camp-was_ist_des_agilen_pudels_kern1.pdf Professionelles Projektmanagement in der Praxis 66 66 66

Der Scrum Prozess Daily Scrum täglich Taskboard & Product Backlog Sprint Backlog Sprint 2-4 Wochen Burndown Chart Sprint Planung Sprint Review Sprint Retrospective Produkt- Inkrement Professionelles Projektmanagement in der Praxis 67 67 67 Meetings Artefakte/ Dokumente

Das Product Backlog Daily Scrum täglich Taskboard & Product Backlog Sprint Backlog Sprint 2-4 Wochen Burndown Chart Sprint Planung Sprint Review Sprint Retrospective Produkt- Inkrement Meetings Artefakte Dokumente Professionelles Projektmanagement in der Praxis 68 68 68

Das Product Backlog Produkt- Konzept Produkt-Vision Product Backlog Product Backlog: Priorisierte Liste, die alle Eigenschaften und Funktionalitäten umfasst, die das Produkt enthalten soll Jeder Eintrag sollte wertvoll für die Anwender des Produktes oder den Kunden sein Eintragungen mit der höchsten Priorität werden als erste im Sprint umgesetzt Vor Beginn jedes Sprints findet eine neue Priorisierung statt Verantwortlich: Product Owner Professionelles Projektmanagement in der Praxis 69 69 69

Das Product Backlog Item Nr. Beschreibung Priorität Aufwand Bemerkungen Schätzwerte des Scrum Teams Die Einträge im Product Backlog werden als Backlog Items bezeichnet Professionelles Projektmanagement in der Praxis 70 70 70

Beispiel: Product Backlog Nr. Beschreibung Priorität Aufwand Bemerkungen 1 Seminarbeschreibung eingeben 2 Seminarbeschreibung ändern A 3 Seminarbeschreibung löschen B 4 Termine zuordnen B 5 Referenten zuordnen C 6 Liste aller Seminare C 7 Seminar-Anmeldung A 8 Seminar-Anmeldung bestätigen Beispiel-Projekt: Website eines Seminar-Anbieters A A Professionelles Projektmanagement in der Praxis 71 71 71

Beispiel: Priorisiertes Product Backlog Nr. Beschreibung Priorität Aufwand Bemerkungen Höchste Priorität 1 Seminarbeschreibung eingeben A 2 Seminarbeschreibung ändern A 7 Anmeldefunktion A 8 Seminar-Anmeldung bestätigen A Hohe Priorität 3 Seminarbeschreibung löschen B 4 Termine zuordnen B Mittlere Priorität 5 Referenten zuordnen C 6 Liste aller Seminare C Beispiel-Projekt: Website eines Seminar-Anbieters Professionelles Projektmanagement in der Praxis 72 72 72

Anforderungen als User Story beschreiben Backlog Items werden als User-Story formuliert nicht technik-, sondern benutzerorientiert sollte Antwort auf mindestens drei Fragen liefern: Als User (Wer?) möchte ich diese Funktionalität (Was?), damit ich folgenden Nutzen habe (Wozu?) Beispiel: Projekt zur Entwicklung eines städtetauglichen Elektrofahrrads Als Führungskraft (Wer?) möchte ich auf dem Weg zur Arbeit wenig in die Pedale treten müssen (Was?), damit ich nicht verschwitzt ankomme (Wozu?) Professionelles Projektmanagement in der Praxis 73 73 73

Der Scrum Prozess: Sprint Planung und Sprint Backlog Daily Scrum täglich Taskboard & Product Backlog Sprint Backlog Sprint 2-4 Wochen Burndown Chart Sprint Planung Sprint Review Sprint Retrospective Produkt- Inkrement Meetings Artefakte Dokumente Professionelles Projektmanagement in der Praxis 74 74 74

Sprint Planungsmeeting und Sprint Backlog Sprint Planungsmeeting Product Backlog 1. Sprint Priorisierung Product Backlog analysieren und auswerten Sprint Ziel festlegen 2. Sprint Planung Was? Wie? Entscheiden, wie man das Sprint- Ziel erreichen kann (Design) Sprint Backlog (Tasks) aus Product Backlog (User Stories/Features) erstellen Sprint Backlog in Stunden schätzen Sprint Ziel Sprint Backlog Professionelles Projektmanagement in der Praxis 75 75 75

Beispiel: Sprint Backlog Product Backlog Item Seminarbeschreibung eingeben Seminarbeschreibung ändern Task (Aktivität) Verantwortlicher Aufwand (h) Design der Seminarbeschreibung Thorsten 35 Eingabefelder mit Plausi versehen Maria 15 Eingaben testen Tom, Jerry 10 Anzeige der Beschreibung im Änderungsmodus Änderungen prüfen und speichern Maria 15 Tom, Jerry 20 Beispiel-Projekt: Website eines Seminar-Anbieters Professionelles Projektmanagement in der Praxis 76 76 76

Grundregel: Keine Änderungen während eines Sprints! Änderungswünsche Sprint Backlog Sprint Produkt Inkrement Änderungs- und Zusatzwünsche werden während des Sprints vom Product Owner gesammelt und dem Product Backlog zugeführt Sie können erst beim nächsten Sprint durch entsprechende Priorisierung Berücksichtigung finden Professionelles Projektmanagement in der Praxis 77 77 77

Der Scrum Prozess: Daily Scrum Daily Scrum täglich Taskboard & Product Backlog Sprint Backlog Sprint 2-4 Wochen Burndown Chart Sprint Planung Sprint Review Sprint Retrospective Produkt- Inkrement Meetings Artefakte Dokumente Professionelles Projektmanagement in der Praxis 78 78 78

Scrum Meetings: Das tägliche Scrum-Meeting Ziel: Austausch über Projektfortschritt Regeln: Täglich, 15 Minuten lang, stets zur gleichen Zeit, im Stehen, ScrumMaster moderiert Jeder beantwortet folgende drei Fragen: Was hast Du gestern gemacht? Was wirst Du heute machen? Was behindert Dich an Deiner Arbeit? Teilnehmer: Professionelles Projektmanagement in der Praxis 79 79 79

Taskboard und Burndown Chart Daily Scrum täglich Taskboard & Product Backlog Sprint Backlog Sprint 2-4 Wochen Burndown Chart Sprint Planung Sprint Review Sprint Retrospective Produkt- Inkrement Meetings Artefakte Dokumente Professionelles Projektmanagement in der Praxis 80 80 80

Der Status der Erledigung der Tasks (Aktivitäten) wird auf einem Taskboard visualisiert Product Backlog Offene To-Dos In Arbeit Done Backlog Item 1 Task 1.3 Task 1.4 Task 1.2 Task 1.5 Task 1.1 Task 1.6 Backlog Item 2 Task 2.3 Task 2.4 Task 2.1 Task 2.2 Jeder hat den aktuellen Überblick über den Fortschritt im Sprint Professionelles Projektmanagement in der Praxis 81 81 81

Die geleistete und noch verbleibende Arbeit wird im Burndown Chart visualisiert Aufbau x-achse beschreibt Zeitverlauf (in Tagen) y-achse die geschätzten Aufwände der (noch) nicht erledigten Tasks Motivation Fortschritt wird transparent Erreichung des Sprint-Ziels ist abschätzbar 400 350 300 250 Burndown Chart 200 150 Restaufwand (h) Idealverlauf 100 50 0 1 2 3 4 5 6 7 8 9 10 Professionelles Projektmanagement in der Praxis 82 82 82

Der Scrum Prozess: Sprint Review und Retrospective Daily Scrum täglich Taskboard & Product Backlog Sprint Backlog Sprint 2-4 Wochen Burndown Chart Sprint Planung Sprint Review Produkt- Inkrement Sprint Retrospective Meetings Artefakte Dokumente Professionelles Projektmanagement in der Praxis 83 83 83

Scrum Meetings: Sprint-Review Meeting Sprint-Review Meeting: Ergebnisvorstellung und -abnahme Team: präsentiert die neuen Funktionalitäten des Sprints Dauer: max. 90 Minuten, keine Folien Produkt Owner / Anwender: begutachten und entscheiden, ob die Funktionalitäten abgenommen werden Unvollständige Features werden nicht abgenommen, kehren zurück ins Product Backlog und werden neu priorisiert Teilnehmer: Professionelles Projektmanagement in der Praxis 84 84 84

Scrum Meetings: Sprint-Retrospective Meeting Sprint-Retrospective Meeting: Interne Nachbetrachtung Findet jeweils am Ende eines Sprints statt, Dauer: 15 30 Minuten Ziel: Aus Erfahrungen lernen, Verbesserungsmöglichkeiten identifizieren (statt einzelne Personen kritisieren und Schuldige suchen) Team benennt Probleme und Hindernisse aus dem letzten Sprint ScrumMaster erstellt eine Liste mit priorisierten Verbesserungsmaßnahmen (Technik, Kommunikation, Organisation) und kümmert sich um deren Umsetzung Teilnehmer: Professionelles Projektmanagement in der Praxis 85 85 85

Schätzung der Backlog Items mit Planungspoker(1/2) Die Größe der User Stories (Backlog Items) werden vom Team geschätzt Jede User Story erhält Story Points, die die relative Größe (Funktionsumfang und Komplexität) im Vergleich zu den anderen widerspiegelt Story Points sind relative Vergleichsgrößen der einzelnen Backlog Items untereinander keine absoluten Schätzgrößen, wie Personentage Planning Poker Karten Kartenwerte: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100,? (steht für unsicher) und Kaffeetasse (steht für Pause) Professionelles Projektmanagement in der Praxis 86 86 86

Schätzung der Backlog Items mit Planungspoker (2/2) Vorgehen Jedes Team Mitglied erhält einen Satz von 13 Poker Karten Das Team identifiziert eine mittelgroße Referenz-Story und bewertet diese mit 5 Story Points 1. Product Owner erläutert eine Story 2. Jedes Teammitglied schätzt die Größe für diese Story im Vergleich zur Referenzstory und legt eine entsprechende Karte verdeckt auf den Tisch (z.b. etwa 4 x so groß 20 ) 3. Alle Karten werden aufgedeckt und verglichen 4. Stimmen diese nicht überein, so begründen die Teilnehmer mit der höchsten und der niedrigsten Karte ihre Bewertungen 5. Ggf. gibt es weitere Schätz- und Diskussionsrunden bis Konsens vorliegt 6. Weiter mit 1. bis alle Backlog Items geschätzt sind Professionelles Projektmanagement in der Praxis 87 87 87

Verwendete Quellen und Links Mike Cohn: Agile Softwareentwicklung: Mit Scrum zum Erfolg!, Addison- Wesley, München 2010, ISBN 978-3-8273-2987-5 Boris Gloger: Scrum Produkte zuverlässig und schnell entwickeln. Hanser, München, 3. Auflage 2011, ISBN 978-3-446-42524-8 Ralf Wirdemann: Scrum mit User Stories. Hanser, München, 2. Auflage 2011, ISBN: 978-3-446-42660-3 Ralf Wirdemann: Scrum eine Einführung, Projektmagazin 21/2009 agilemanifesto.org Grundlagen der agilen Philosophie www.wikipedia.de Stichworte: Agiles Projektmanagement, Scrum www.it-agile.de Informationen zu agilen Methoden und Praktiken www.mountaingoatsoftware.com Artikel und Informationen zu Scrum, u.a. frei verfügbarer Foliensatz zur Scrum-Einführung Professionelles Projektmanagement in der Praxis 88 88 88

Agenda (29.06.2015) Organisatorisches: Termine, Projektexposé/-broschüre, Projektbericht, Zertifizierungsprüfung Präsentationen PL der Teams 5, 7 und 8 (Aufgabe 9) Projektreview, Projektabschluss, Projektinkasso Aufgabe 10 (letzte Aufgabe der Vorlesung) Besonderheiten von Softwareprojekten, Agiles Projektmanagement Konflikt- und Krisenmanagement Professionelles Projektmanagement in der Praxis 89 89 89

Workshop: Teamkonflikte Welche Konflikte können in einem Team entstehen? Was sind die Ursachen? (Erfahrungen) Teammitglieder kommen ihren Aufgaben nicht nach Fehlende Wertschätzung für die Arbeiten Unterschiedliche Vorstellungen für die Implementierung Zwischenmenschliche Probleme Wie können Teamkonflikte gelöst / vermieden werden? Welche Präventions- und Behandlungsmaßnahmen für Konflikte schlagen Sie vor? (Erfahrungen) Klare Rollen und Zuständigkeiten Konfliktlösung mit Moderator Gegenseitige Wertschätzung Klare Kommunikation mit Begründung Luft holen und nachdenken Mit Abstand betrachten Professionelles Projektmanagement in der Praxis 90 90 90

Konfliktverlauf in Phasen Konfliktmanagement Entstehung Erkennung Analyse + Darstellung Lösung + Umsetzung Lessons Learned Ursachen Indikatoren Konfliktbehandlung Präventionsmaßnahmen K.-Lösungsstrategien für die Zukunft Negative und positive Konsequenzen Unzufriedenheit im Team Motivationsverlust Reduktion der Leistungsbereitschaft Bindung von Energie Positive Veränderungen werden ermöglicht Schaffung klarer Verhältnisse Neue Ideen werden erzeugt Chancen werden aufgedeckt Reife der Projektkultur Professionelles Projektmanagement in der Praxis 91 91 91

Konflikt-Ursachen und Konfliktarten Zielkonflikte Fehlende Klarheit über die Ziele Fehlendes Commitment der Stakeholder zu den Zielen Klassiker: Macht-Konflikt zwischen Tagesgeschäft (Linie) und Projekt Fehlende Kommunikation zwischen Projekt und Fachabteilung Entscheidungen werden am Projekt vorbei getroffen Ressourcenkonflikte Projektmitarbeiter nicht verfügbar wie geplant und abgestimmt Beziehungskonflikte Zwischenmenschliche Konflikte in der Zusammenarbeit Uneinigkeit in der Zieldefinition, Prioritäten, Aufgabenverteilung, Termin-, Ressourcen- und Kostenplanung Änderung der Prioritäten des Auftraggebers Mangelndes Verständnis über die Bedeutung von Änderungen und deren Auswirkungen auf das Projekt Professionelles Projektmanagement in der Praxis 92 92 92

Konflikt-Indikatoren Die größten Probleme sind die Probleme, die vom Projektleiter nicht erkannt werden Rauchzeichen für Konflikte Permanenter Streit und Aggressivität im Team Dienst nach Vorschrift Desinteresse, Gerüchte Mobbing, Intrigen Personalflucht Unerklärbare Leistungsabfälle Fehlende Rückmeldungen Fehlzeiten nehmen zu Beschwerden von Kunden Zynismus, Galgenhumor Der Durchbruch ist fast geschafft Professionelles Projektmanagement in der Praxis 93 93 93

Die neun Stufen der Konflikt-Eskalation nach Friedrich Glasl Die Eskalationsstufen: Abstieg zu immer tieferen, primitiveren und unmenschlicheren Formen der Auseinandersetzung Stufe 1 Verhärtung: Konflikte beginnen mit Spannungen, z. B. gelegentliches Aufeinanderprallen von Meinungen. Stufe 2 Debatte: Ab hier überlegen sich die Konfliktpartner Strategien, um den anderen von ihren Argumenten zu überzeugen. Meinungsverschiedenheiten führen zu einem Streit. Man will den anderen unter Druck setzen. Schwarz-Weiß-Denken entsteht. Stufe 3 Taten statt Worte: Die Konfliktpartner erhöhen den Druck auf den jeweils anderen, um sich oder die eigene Meinung durchzusetzen. Stufe 4 Koalitionen: Der Konflikt verschärft sich dadurch, dass man Sympathisanten für seine Sache sucht. Stufe 5 Gesichtsverlust: Der Gegner soll in seiner Identität vernichtet werden durch alle möglichen Unterstellungen oder ähnliches. Stufe 6 Drohstrategien: Mit Drohungen versuchen die Konfliktparteien, die Situation absolut zu kontrollieren. Stufe 7 Begrenzte Vernichtung: Hier soll dem Gegner mit allen Tricks empfindlich geschadet werden. Stufe 8 Zersplitterung: Der Gegner soll mit Vernichtungsaktionen zerstört werden. Professionelles Projektmanagement in der Praxis Stufe 9 Gemeinsam in den Abgrund: Ab hier kalkuliert man die eigene Vernichtung mit ein, um den Gegner zu besiegen. 94 Quelle: 94 Wikipedia 94