Professionelles Projektmanagement in der Praxis

Transkript

1 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 ( ): Projektreview, Projektabschluss, Projektinkasso Besonderheiten von Softwareprojekten, Agiles Projektmanagement Konflikt- und Krisenmanagement SS 2015

2 Agenda ( ) 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- s wurden in der letzten Woche verschickt. Bitte nehmen Sie teil! Vielen Dank Professionelles Projektmanagement in der Praxis 2 2 2

3 Termine Vorträge Team 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:00 Uhr Klausur (Dauer: 80 Minuten): , 12:00 Uhr Zuse-HS PM-Zertifizierung (Dauer: 120 Minuten): : 15:00 Uhr, HS 4 Professionelles Projektmanagement in der Praxis 3 3 3

4 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

5 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

6 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

7 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

8 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

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

10 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: Professionelles Projektmanagement in der Praxis

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

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

13 Agenda ( ) 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

14 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

15 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

16 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

17 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

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

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

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

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

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 Praxis-Beispiel: Überführung des Projektes NIMBUS in die Linie (Workshop vom ) 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

30 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

31 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

32 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

33 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./ ) (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

34 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

35 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

36 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

37 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

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

39 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

40 Agenda ( ) 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

41 Schlechtes Image von Softwareprojekten IT-Projekte haben ein schlechtes Image: 100% 90% 80% Abgebrochen 70% 60% 50% 40% Zeit u/o Budget überschritten u/o gewünschte Qualität nicht erfüllt 30% 20% 10% 0% 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

42 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

43 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

44 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 ( ) 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

45 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 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 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 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 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 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 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 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 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 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 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 Professionelles Projektmanagement in der Praxis

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 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 Professionelles Projektmanagement in der Praxis

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 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 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

61 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

62 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

63 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

64 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: Professionelles Projektmanagement in der Praxis

65 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 Meetings Artefakte/ Dokumente

66 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

67 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

68 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

69 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

70 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

71 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

72 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

73 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

74 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

75 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

76 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

77 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

78 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

79 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

80 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 Burndown Chart Restaufwand (h) Idealverlauf Professionelles Projektmanagement in der Praxis

81 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

82 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

83 Scrum Meetings: Sprint-Retrospective Meeting Sprint-Retrospective Meeting: Interne Nachbetrachtung Findet jeweils am Ende eines Sprints statt, Dauer: 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

84 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

85 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

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

87 Agenda ( ) 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

88 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

89 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

90 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

91 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

92 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