Projektmanagement Vorlesung 14/ 15: Grundlagen. Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern

Transkript

1 Projektmanagement Vorlesung 14/ 15: Grundlagen Prof. Adrian Müller, PMP, PSM-1, CSM FH Kaiserslautern phone: /

2 Inhalte: Grundlagen Klassisches Projektmanagement Grundlegende Definitionen Aufgaben der Projektleitung Projektauswahl Initiale Projektanalyse Projektantrag Lastenheft Lernkontrolle Anhang: Kreativitätstechniken Grundlagen Projektmgmt. - Prof. A. Müller Page 2

3 Definition Projekt nach DIN DIN definiert Projektmanagement als die "Gesamtheit von Führungsaufgaben, - organisation, -techniken und -mitteln für die Abwicklung eines Projektes". DIN : Ein Projekt ist "ein Vorhaben, das im wesentlichen durch eine Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist". Beispiele relevanter Bedingungen nach DIN Grundlagen Projektmgmt. - Prof. A. Müller Page 3

4 Drei Basisdefinitionen (PMI) Ein Programm ist eine Menge von miteinander verbundenen Projekten Ein Projekt ist ein Vorhaben: mit einem Anfang und einem Ende ist einzig-artig verbraucht Resourcen Ein Subprojekt (subproject) ist ein Teil eines Projektes, das mit einem bestimmten Level von Unabhängigkeit geleitet (managed) wird Grundlagen Projektmgmt. - Prof. A. Müller Page 4

5 Basisdefinitionen: Dimensionen eines Projekts Der Project Manager muss die drei Beschränkungen (Dimensionen, Rand- Bedingungen) seines Projektes??? beachten:?????? Grundlagen Projektmgmt. - Prof. A. Müller Page 5

6 Wie entstehen Projekte? Wann sind sie erfolgreich? Betriebswirtschaftlicher Bedarf oder Ziel (business need, business opportunity) Reaktion auf externes oder internes Programm u.a. Stimulationen Reaktion auf geänderte Bedingungen Initiative zum Wohle Dritter Beteiligte Prozesse (variieren stark je nach Land und Projektform) Ausschreibung, häufig in Form eines (Kern-) Lastenhefts Englisch-sprachl. Raum: CFT, RFI, RFP usw. Anträge Interner Auftrag Einwerben von Partnern A successful project is one that meets or exceeds the expectations of your stakeholders. (Quelle: PMBOK) Grundlagen Projektmgmt. - Prof. A. Müller Page 6

7 Projektleitung Project Manager ist verantwortlich für das Projekt der prinzipielle Ansprechpartner (single point of contact) für das Projekt verantwortlich, die potenziellen Stakeholder zu identifizieren und ihre Interessen zu beachten Bei Konflikten: zum Wohle des Projektes entscheiden Das Projektbüro (bei großen Projekten oder bei der Bündelung kleiner Projekte): Ein Stab, der die operative Kontrolle ganz oder in Teilen ausübt (engl: project office). Seine Aufgaben sind definiert Prozesse und Standards (bspw. Templates) ist anteilig an Statusmeetings beteiligt PO administrative Aufgaben bei mehreren kleinen oder einzelnen großen Projekte zentral ab (wie Finanzkontrolle und Planung, Außendarstellung) Grundlagen Projektmgmt. - Prof. A. Müller Page 7

8 Project Stakeholder (Interessengruppen des Projekts) Infrastruktur, Sicherheit Einkauf Sponsor Kunde Projektteam Ext. Interessensgruppen Finanzen Line Management Qualitätsmanagement Recht Grundlagen Projektmgmt. - Prof. A. Müller Page 8

9 Auswahl von Projekten Grundlagen Projektmgmt. - Prof. A. Müller Page 9

10 Es liegen eine oder mehrere Projektskizzen vor. Was nun? Projektziele (je Projekt) klären und ausformulieren Ziele des Unternehmens, des Sponsors, der Projektpartner Projektziele dabei in Übereinstimmung mit vitalen Interessen der projektrelevanten Rollen (Stake Holder) bringen Projekte auswählen bzw. abschätzen: Faktoren und Gewichtung für einen Vergleich mehrere Projekte festlegen Vorstudien, Machbarkeitsanalyse, Wirtschaftlichkeitsanalyse Objektive Entscheidung anstreben Konsens sicherstellen Übersichtliche Darstellung erarbeiten und präsentieren Ziel: Das Projekt in s Leben zu rufen und informal zu beginnen. So gewinnen wir die Überzeugung, das Wohlwollen, und die Motivation aller beteiligter Rollen (Team, Projektträger, Kunde usw.) Grundlagen Projektmgmt. - Prof. A. Müller Page 10

11 Initiale Stakeholder Analyse Matrix Stakeholder: Rolle oder Funktion Bezug zum / Art des Interesses am Projekt Vermag / ist motiviert um welche Probleme zu lösen Seine primären Ziele Positiver Einfluß auf Projekt Negativer Einfluß auf Projekt Grundlagen Projektmgmt. - Prof. A. Müller Page 11

12 Vergleich mehrerer Projekte (a): Sample Weighted Scoring Model for Project Selection Grundlagen Projektmgmt. - Prof. A. Müller Page 12

13 Vergleich mehrerer Projekte (b): Mehrdimensionale Darstellung 380 von 700 Punkten 575 von 700 Punkten Grundlagen Projektmgmt. - Prof. A. Müller Page 13

14 Die detaillierte Projektanalyse eindeutige und strukturierte Projektziele formulieren Einbeziehung Kunde, Projektorganisation, Team Methoden: strukturierte Interviews, Kreativtechniken, passende Techniken aus Anwendungsgebiet fachliche, wirtschaftliche und personelle Durchführbarkeit des Projekts erarbeiten Randbedingung (Termine, Kosten, Personen) präzisieren alle Stakeholder beachten Initiale Risikoanalyse unter Beachtung aller relevanten (maßgeblich beteiligten) Gruppen und Funktionen Risiken in verschiedenen Kategorien suchen (Zeit, Abstimmungen und Kommunikation, Recht, Stakeholder und menschliche Faktoren, Vorwissen und Erkenntnisgewinn während des Projektes, Entscheidungszwang und Nicht-Wiederholbarkeit usw usw.) Hinweis: die beiden üblichen Verdächtigen (a) Ausfall Hardware, (b) Ausfall/Krankheit im Team haben noch bei keinem Projekt ausgereicht! Grundlagen Projektmgmt. - Prof. A. Müller Page 14

15 Inhalte eines Projektantrages 1/2 Ein erfolgreicher Projektantrag enthält mehrere, verständlich ausformulierte Ziele zu allen wichtigen Aspekten im Projekt Machbarkeit, Aufwand, Priorisierung Ziele Zeitrahmen, Abschnitte der Projektdurchführung Planbarkeit (Vorschläge zu Vorgehensmodell, Steuerung, Zwischenziele) Identifikation der Stakeholder, Präzisierung Rollen Einbeziehung weiterer Teilprojekte und Funktionen Grundlagen Projektmgmt. - Prof. A. Müller Page 15

16 Darstellung eines Projektantrages 2/2 Initiale Risikoanalyse Abschätzen Projektrisiko Bedeutende Risiken rechzeitig eingrenzen / aktiv in Planung einbeziehen Im Antrag zusammenfassend darstellen Endkontrolle der Zielerreichung sicherstellen Ziele müssen SMART sein (vgl. Meilensteíne) High-Level Feststellung der Zielerreichung Hinweise: Planung Projektabnahme beginnt ab Tag 0 Objektivierbarkeit reduziert das spätere Konfliktpotential Grundlagen Projektmgmt. - Prof. A. Müller Page 16

17 Und nach dem Projektantrag... Die nächsten Schritte (1) Projektrahmen festlegen Sofern nicht bereits vom Kunden, oder einem anderem Stakeholder vorgegeben: Vorgehensmodell festlegen, Zeitrahmen verifizieren offene Punkte aus der Besprechung des Antrags klären ( comebacks ) Optional: Vorstudie, Explorationsphasen (2) Projektauftrag schriftlich und rechtlich verbindlich darstellen: (3) Lastenheft... (s. nächste Seite), Project Charter (4) Projekt organisatorisch initiieren ( kick-off ) (5) Projektplanung (s. Pflichtenheft, optional mit WBS) finalisieren Deutschsprachiger Raum: Pflichtenheft kann auf weitere Planungsdokumente verweisen / Englischer Raum: verwendet project charter, diese integriert alle Information (6) Projektablauf (project execution) umfasst: Feinplanung (Projektplan, Gantt-View u.ä.) und Kontrolle Kommunikation, Berichtswesen, Kostenplanung Transparenz und Steuerung sicherstellen Change Management und anderes mehr Grundlagen Projektmgmt. - Prof. A. Müller Page 17

18 Klassische Form der Projektbeschreibung: das Lastenheft Das Lastenheft ist die Aufgabenbeschreibung, umfasst somit das Soll aller Anforderungen (das was? ) Das Dokument präzisiert die Vorgaben des Auftraggebers (Kunde) / des project clients: Zielbestimmung Produkteinsatz Übersicht der Produktfunktionen i.a. ohne Details s. Pflichtenheft Nicht-Funktionale Anforderungen Kommunikation (Team-intern, mit Kunde, mit Sponsor, usw.) Beistellungspflichten Testziele Berichtswesen Qualitätsvorgaben Meilensteine Sind: besondere Ereignisse im Projekt (Abschluss einer Phase, Genehmigung etc.) Können: an Ziele gekoppelt sein Methode: Meilensteinsitzung U.v.a.m Wichtige Aspekte zum Lastenheft Grundlagen Projektmgmt. - Prof. A. Müller Page 18 Grad der Detaillierung kann abweichen (je nach Expertise Auftraggeber) Inkrementelle, gemeinsame Redaktion kann verabredet werden Überarbeitung sind möglich, bedürfen aber typischerweise des Konsens Stichtag für die Finalisierung (baseline) festlegen Details, Beispiele zum Pflichtenheft: nächste Vorlesung

19 Zusammenfassung: Checkliste zum Pflichtenheft Angebotsgegenstand Aufgabenstellung Lieferumfang Vertragsbestandteile Dokumentations- und Entwicklungsrichtlinien Qualitätssicherungsplan einschl. Testplan Vorgehensweise des Auftragnehmers / zu erbringende Leistungen Erweiterte Produktbeschreibung, Szenarien, Use-Cases usw. Architektur, GUI, DB-Schema usw. Codestruktur, Guidelines Testplanung Resourcen, Einsatzplanung U.v.a.m Beistellungen des Auftraggebers Mitwirkungspflichten des Auftraggebers Termine (alle Termine sind relative Zeitangaben!) Abnahme Meilensteintermine Teillieferungen (alpha/beta/gamma) und Testkriterien (Verweis auf) Netzplan Dauer der Abnahmeprüfung Mitwirkung des Auftragnehmers Inhaltliche Vereinbarungen der Abnahmeprüfung Vergütung (s. Vertragsrecht) Nutzungsrechte am Werk (s. Vertragsrecht) Sonstige Leistungen

20 Was gehört wohin? 1. Erfolgskriterien des Projekts im Detail 2. Ziele und allgemeine Vorgaben 3. Team (Fähigkeiten) 4. Inhaltliche Vorgaben, Anforderungen und Wünsche 5. Geplantes Vorgehensmodell 6. Team (welche Personen) 7. Durchführung der Bewertung des Projekts 8. Meilensteine 9. Produktbeschreibung (Übersicht der geplanten Funktionen) 10. Indikatoren (wie #Code, #Tests) 11. Detaillierte Analyse des zu erstellenden Produktes (eg Use Cases, GUI Skizzen, DB-Eigenschaften) 12. Fortschrittskontrolle 13. Durchführung der Kommunikation 14. Testplanung 15. Machbarkeit, Planbarkeit belegen 16. Stakeholder identifizieren a) Projektantrag b) Lastenheft c) Pflichtenheft Grundlagen Projektmgmt. - Prof. A. Müller Page 20

21 Beispiele und vertiefende Hinweise, Wiederholungen zur Vorlesung Software Engineering

22 Kick-off Sitzung Ziele Die Bedeutung des Projekts ist allen Mitarbeitern klar Die Teilnehmer kennen sich Die Projektziele sind bekannt Die Regeln der Zusammenarbeit sind definiert und von allen akzeptiert Jeder kennt seine Rolle im Projekt Die weitere Vorgehensweise ist definiert Eine gemeinsame Projektsicht ist entwickelt Teilnehmer Projektleiter Projektteam Ggf. Auftraggeber (evtl. nur zu Beginn) Quelle: Tiemeyer, Handbuch IT-Management

23 Kick-off Sitzung Mögliche Agenda Einleitung Vorstellungsrunde Rollenklärung Vorstellung der Ziele (Inhalte / Termine / Kosten) Vereinbaren der Spielregeln Weitere Vorgehensweise im Projekt 23

24 Gliederung einer Anforderungsspezifikation ( requirement specs ); typisch in USA, GB und anderen Ländern; s.a. project charter Titel, Autor, Empfänger, Identifizierung, Änderungshistorie, Inhaltsverzeichnis 1 Einführung 1.1 Zweck (d.h. Darstellung der Vision) 1.2 Markt (z. B. Marktsegmente, Bedarf, Design, Alleinstellungsmerkmale) 1.3 Glossar (d. h. Definitionen, Akronyme, Abkürzungen) 1.4 Referenzen 1.5 Systemübersicht (d. h. System- und Kontextabgrenzung) 2 Beschreibung 2.1 Produktsicht (z. B. Systemschnittstellen, Benutzung, HW-/SW-Schnittstellen) 2.2 Funktionen (z. B. als Use Cases oder Feature-Baum) 2.3 Benutzer (z. B. verschiedene Benutzergruppen, Profile, Szenarien) 2.4 Einschränkungen (externe Vorgaben, z. B. Protokolle, Hardware, Algorithmen) 2.5 Qualitätsanforderungen (externe Vorgaben, z. B. Zuverlässigkeit, Sicherheit) 2.6 Annahmen (d. h. nicht durch den Kunden definierte spezifische Annahmen) 3 Spezifische Anforderungen 3.1 Funktionale Anforderungen (z. B. Gültigkeitsprüfungen, Use Cases, Abnahme) 3.2 Architektur (z. B. Datenmodelle, Systemmodelle, Evolution des Systems) 3.3 Einschränkungen (intern und extern, messbar, ggf. Abnahmekriterien) 3.4 Qualitätsanforderungen (intern und extern, messbar, ggf. Abnahmekriterien) 3.5 Standards Anhänge, Index Entspricht Lastenheft Entspricht Pflichtenheft Gemäß IEEE-Standard 830, Quelle: Ebert

25 Vgl. Vorlesung Software Engineering: Beispiele für Lasten- und Pflichtenhefte S. Wiki, s. dropbox zur Vorlesung Firma Vector ct=templates Balzert, Lehrbuch Softwaretechnik. Basiskonzepte und Requirements Engineering Kapitel III.7 Fallstudie Seminarorganisation Kapitel III.8 Fallstudie Fensterheber 25

26 Vgl. Vorlesung Software Engineering: Qualitätsmerkmale für Software (ISO 9126) 26

27 Vgl. Vorlesung Software Engineering: Formulierung von Qualitätsanforderungen Beispiel: Qualitätsziele für eine Schach-Engine Qualitätsmerkmal Analysierbarkeit Änderbarkeit Interoperabilität Attraktivität Effizienz Ziel Messbarkeit? Überprüfbarkeit? Da DokChess in erster Linie als Anschauungsmaterial für Architekten und Entwickler dient, erschließen sich Entwurf und Implementierung schnell. Alternative Algorithmen und Strategien, etwa zur Bewertung einer Schachstellung, können leicht implementiert und in die Lösung integriert werden. Die Engine kann mit angemessenem Aufwand in bestehende grafische Schach-Frontends eingebunden werden. Die Engine spielt stark genug, um schwache Gegner sicher zu schlagen und Gelegenheitsspieler zumindest zu fordern. Da die Engine in Seminaren und Vorträgen live demonstriert wird, erfolgt die Berechnung der Spielzüge rasch. Quelle: Konkretisierung durch Qualitätsszenarien 27

28 Vgl. Vorlesung Software Engineering: Qualitätsszenarien Präzisieren Qualitätsziele Beziehen sich auf Qualitätsmerkmale Sind am fertigen System überprüfbar Zwingen einen dazu, nachzudenken, was ein bestimmtes Qualitätsmerkmal in einem bestimmten Fall für konkrete Konsequenzen hätte 28

29 Vgl. Vorlesung Software Engineering: Qualitätsszenarien Qualitätsszenarien für eine Schach-Engine (Auszüge) Nr. Szenario Qualitätsmerkmal 1 Ein Interessierter mit Grundkenntnissen in UML und Schach möchte einen Einstieg in Analysierbarkeit die Architektur von DokChess finden. Lösungsstrategie und Entwurf erschließen sich ihm innerhalb von 15 Minuten. 4 Ein Entwickler implementiert eine neue Stellungsbewertung. Er kann sie ohne Änderbarkeit Änderung und ohne Übersetzung vorhandenen Codes in bestehende Strategien integrieren. 5 Ein Entwickler implementiert eine figurenzentrierte Bitboard-Repräsentation der Änderbarkeit Spielsituation. Der Aufwand dazu beträgt inklusive des Austauschs der bestehenden, feldzentrierten Darstellung durch die neue maximal eine Woche. 10 Während einer Partie antwortet die Engine auf gegnerische Züge innerhalb von 5 Zeitverhalten Sekunden mit einem Zug. 12 Ein Benutzer will DokChess mit einem Schachfrontend verwenden, das ein von der Interoperabilität Lösung implementiertes Kommunikationsprotokoll unterstützt. Das Einbinden erfordert keinerlei Programmieraufwand, die Konfiguration innerhalb des Frontends ist innerhalb von 10 Minuten durchgeführt und getestet. 13 Ein Java-Programmierer will DokChess mit einem Schachfrontend verwenden, das Anpassbarkeit das Einbinden von Engines erlaubt, aber keines der implementierten Protokolle unterstützt. Das neue Protokoll kann ohne Änderung am bestehenden Code implementiert und die Engine anschließend wie gewohnt eingebunden werden. 14 Der Engine wird im Spielverlauf ein unzulässiger Gegenzug präsentiert. Die Engine Fehlertoleranz lehnt den Zug ab, erlaubt im Anschluss die Eingabe eines anderen Zuges und spielt fehlerfrei Quelle: weiter. 29

30 Anhang: Kreativitätstechniken Brainstorming Methode 635 Mind-Maps Grundlagen Projektmgmt. - Prof. A. Müller Page 30

31 Brainstorming Stimulates people to develop alternatives during the planning and decision-making process Main focus is on identifying alternatives Brainstorming Ground Rules Do not evaluate ideas Be free-wheeling Produce as many ideas as possible Hitchhike Pro: Cons Reduces dependence on one authority figure open sharing of ideas Maximizes output for a short period of time non-evaluative climate Tends to be enjoyable and stimulating feeling of lack of closure May cause dissatisfaction Even in a relaxed atmosphere, presence of group members may inhibit creativity among some participants Grundlagen Projektmgmt. - Prof. A. Müller Page 31

32 Method 635 Why: Idea identification similarly to brainstorming here however brainwriting, load or rhetorically superior group members can develop no dominance Proceed (group work) define problem 6 persons write on a sheet Afterwards the sheet is passed on in the clockwise direction per person 3 ideas should be formulated 5 minutes are available Grundlagen Projektmgmt. - Prof. A. Müller Page 32

33 Mind-Maps Left side of the brain rational thinking logic speech number analysis Right side of brain 3d orientation fantasy color rythm pattern Why? structuring and visualization of complex problems. Proceeding (individually or group work) Identification of the problem/topic = the center From the center run the main branches, which develop the problem/topic in individual ranges/topic fields. As many as desired branches are assigned to these main branches; each branch stands thereby for a specific idea this is written as keyword on the branch.hint: with complex Mind maps different colors can facilitate the structuring Grundlagen Projektmgmt. - Prof. A. Müller Page 33

34 Mind Map - Example Grundlagen Projektmgmt. - Prof. A. Müller Page 34

35 Hintergrundinfo: Kreativ- und Designdiskussion Weitere Hinweise für Kreative Diskussionsformen Brainstorming: Metaplan: Methode 6-3-5: All links checked: 10/2011 Grundlagen Projektmgmt. - Prof. A. Müller Page 35