Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Projektmanagement 5. Frameworks und Normen im IT- Projektmanagement 1 © Prof. Dr. Walter Ruf.

Ähnliche Präsentationen


Präsentation zum Thema: "Projektmanagement 5. Frameworks und Normen im IT- Projektmanagement 1 © Prof. Dr. Walter Ruf."—  Präsentation transkript:

1 Projektmanagement 5. Frameworks und Normen im IT- Projektmanagement 1 © Prof. Dr. Walter Ruf

2 5. Frameworks und Normen im IT-Projektmanagement 5.1 V-Modell XT 5.2 PRINCE Die 7 Grundprinzipien Themen Überblick: Prozesse von PRINCE Merkmale und Besonderheiten 5.3 PMBOK Guide Grundstruktur und Aufbau Areas of Knowledge Überblick Projektprozesse Prozesse Phase 1: Vorbereitungsphase Prozesse Phase 2: Planungsphase Prozesse Phase 3: Durchführung Prozesse Phase 4: Einführung Prozesse Phase 5: Abschlussphase 2© Prof. Dr. Walter Ruf

3 5.1 V-Modell XT Das V-Modell XT beinhaltet konkrete, standardisierte Vorgehensweisen. In den einzelnen Vorgehensschritten werden zu erstellende Ergebnisse definiert und hierfür Verantwortlichkeiten zugeordnet. Im Mittelpunkt stehen die Fragen „Wer“ muss „Was“, „Wann“ in einem IT-Projekt machen (vgl. V-Modell XT, Version S. 1-3). 3© Prof. Dr. Walter Ruf

4 Ziele vom V-Modell XT Minimierung der Projektrisiken Qualitätsverbesserungen transparente Kostendarstellung Kommunikation zwischen allen Beteiligten offen gegenüber Modelländerungen 4© Prof. Dr. Walter Ruf

5 Grundkonzeption des V-Modells XT Systementwicklungsprojekt eines Auftraggebers Systementwicklungsprojekt eines Auftragnehmers Einführung und Pflege eines organisatorischen Veränderungsmodells 5 Den Kern des V-Modells XT bilden die Vorgehensbausteine. Hierbei handelt es sich um selbständig entwickelbare und änderbare Einheiten. Sie bestehen aus Aktivitäten, die sich aus Teilaktivitäten zusammensetzen lassen, aus Produkten, die aus mehreren Themen bestehen können und aus Rollen, die die Verantwortung für einen Entwicklungsteil tragen. © Prof. Dr. Walter Ruf

6 Bestandteile von Vorgehensbausteinen 6© Prof. Dr. Walter Ruf

7 Produktgliederung 7© Prof. Dr. Walter Ruf

8 Vorgehensbaustein Landkarte Beim Zuschnitt des V-Modells XT auf genau ein IT- Projekt hin erfolgt eine spezifische Auswahl von Vorgehensbausteinen. 8© Prof. Dr. Walter Ruf

9 Projektdurchführungsstrategie Das V-Modell XT ist so flexibel ausgelegt, dass u.a. sowohl das Grundmodell für sequentielle als auch inkrementelle oder evaluative Vorgehensmodelle unterstützt werden können. 9© Prof. Dr. Walter Ruf

10 10© Prof. Dr. Walter Ruf

11 Entscheidungspunkte für die Projektdurchführungsstrategie 11© Prof. Dr. Walter Ruf

12 Anwendungsbeispiel (Strukturierung der Entscheidungspunkte) 12© Prof. Dr. Walter Ruf

13 Projektplanung (projektspez. Durchführungsstrategie) 13© Prof. Dr. Walter Ruf

14 V-Modell XT Projektassistent 14© Prof. Dr. Walter Ruf

15 Tailoring 15© Prof. Dr. Walter Ruf

16 Festlegung der Entscheidungspunkte 16© Prof. Dr. Walter Ruf

17 Datenübernahme nach MS-Project 17© Prof. Dr. Walter Ruf

18 V-Modell XT Das V-Modell XT Bund ist eine auf die Bedürfnisse der Behörden angepasste Erweiterung des flexiblen Vorgehensmodell V-Modell XT. 18© Prof. Dr. Walter Ruf

19  Erfolgsfaktoren – Fallstricke - Praxistipp Beginnen Sie kein IT-Projekt ohne Festlegung eines Vorgehensmodells. Wählen Sie ein Vorgehensmodell nach den folgenden Kriterien Vollständigkeit, Systematik, Modularität, Allgemeingültigkeit und Anpassbarkeit aus (vgl. Bunse, C.; Knethen, A.: (2002), S. 101). Passen Sie das Vorgehensmodell auf das konkrete Projektvorhaben an. Sorgen Sie dafür, dass alle Projektbeteiligten (Kunden, Partner, Anwender, Entwickler, …) Kenntnis über das Vorgehensmodell erhalten. Das Vorgehensmodell stellt eine wichtige Komponente in der Projektdokumentation dar und kann für spätere IT-Projekte verwendet werden. Die Erfahrungen mit einem bestimmten Vorgehensmodell bei einer konkreten Projektumsetzung sind von erheblichem Wert für Folgeprojekte. 19© Prof. Dr. Walter Ruf

20 5.2 PRINCE2 PRINCE = Projects in Controlled Environments Bei PRINCE2 handelt es sich um ein „Vorgehensmodell für das Projektmanagement, das aus Prozessen, Komponenten, Techniken und einem Phasenmodell besteht.“ Linssen, O.; Rachmann, A.: P.: PRINCE2 – ein prozessorientierter Projektmanagementansatz, i n: HMD Heft 2008; S. 69. basiert auf Erfahrungen (Best Practices) Copyright-Inhaber: Office of Government Commerce (OGC). –Entwicklung beginnt bereits im Jahr 1989 (Central Compuer and Telecommunications Agency) –mehrere Überarbeitungen (letzter Refresh: 2009) Offizielle Seite: –stärkste Verbreitung in Großbritannien 20© Prof. Dr. Walter Ruf

21 PRINCE2 basiert auf: 1.Grundprinzipien Durch die Grundprinzipien wird die grundsätzliche Philosophie der Methode festgelegt. 2.Themen Themen stellen die Bereiche (Aspekte) dar, die während der Projektumsetzung fortlaufend betrachtet werden. 3.Prozessen Mit den Prozessen werden Aktivitäten, Produkte und Verantwortlichkeiten definiert. 21© Prof. Dr. Walter Ruf

22 5.2.1 Die 7 Grundprinzipien 1.Fortlaufende geschäftliche Rechtfertigung (Business Case) Jedes Projekt braucht eine wirtschaftliche Rechtfertigung. Diese sollte am Anfang beschrieben werden – kann sich jedoch während des Projektablaufs ändern. 2.Lernen aus Erfahrung –positive und negative Erkenntnisse dokumentieren. –PRINCE2 fordert die Konservierung der Erkenntnisse –Nutzung von gesammelten Erkenntnissen aus abgeschlossenen Projekten 3.Definierte Rollen und Verantwortlichkeiten –Unternehmensvertreter („Projekt als Investition“) –Benutzervertreter („Nutzbarkeit der Projektergebnisse“) –Lieferantenvertreter („Bereitstellung von Know-how für die Umsetzung“) 22© Prof. Dr. Walter Ruf

23 Die 7 Grundprinzipien (Fortsetzung) 4. Steuern über Managementphasen –Anzahl Phasen kann frei gewählt werden (mindestens 2 Phasen) –Phasenende stellt einen Entscheidungszeitpunkt dar, in dem dargestellt wird: aktueller Projektstatus Business Case für das Projekt Pläne für die Weiterentwicklung 5. Steuern nach dem Ausnahmeprinzip –„Management by Exception“ 6. Produktorientierung –Projektergebnisse nennt man Produkte –jedes Produkt gilt es am Anfang klar zu definieren –zu jedem Produkt soll festgelegt werden, wie dessen Vollständigkeit geprüft werden kann 23© Prof. Dr. Walter Ruf

24 Die 7 Grundprinzipien (Fortsetzung) 7. Anpassung an die Projektumgebung –Tailoring –Anpassung der Prozesse an die Projekterfordernisse Anpassung an Projektumfang Anpassung an Projektgröße / Ausgestaltung  Das Tailoring verhindert eine Projektumsetzung nach einer einzigen Lehrbuchvorlage. 24© Prof. Dr. Walter Ruf

25 5.2.2 Themen Durch 7 Themen sollen die Grundprinzipien „befriedigt“ werden. –Grundprinzipien werden aufgegriffen und konkretisiert. –Themen stellen die Vorstufe für Prozesse dar. 1.Business Case Konkretisierung des Prinzips „Fortlaufende geschäftliche Rechtfertigung“ –Gegenüberstellung von Kosten dem Nutzen –Risikobetrachtung. –Bei Projektänderungen muss der Business Case ggf. neu angepasst werden. 2.Organisation –Konkretisierung des Prinzips „Definierte Rollen und Verantwortlichkeiten –Festlegung der Zuständigkeiten der Projektbeteiligten –Festlegung von Verantwortlichkeiten –Festlegung von klaren Kommunikationsstrukturen 25© Prof. Dr. Walter Ruf

26 Themen (Fortsetzung) 3.Qualität –Konkretisierung des Prinzips „Produktorientierung“ und „Lernen aus Erfahrung“ –Festlegung von Qualitätskriterien in Prduktbeschreibungen diese können die Voraussetzung für die Abnahme bilden –Qualitätsmanagement Qualitätsplanung, - steuerung, - sicherung –Integration regelmäßiger Retrospektiven 4. Pläne –die Steuerung eines Projektes basiert auf Plänen –Pläne beschreiben „wie, wann und von wem ein oder mehrere Ziele erreicht werden.“ –Plan = Simulation der Zukunft 5.Risiken –jedes Projekt birgt Risiken –Risikobetrachtung ist essenziell für jedes Projekt durchzuführen 26© Prof. Dr. Walter Ruf

27 Themen (Fortsetzung) 6. Änderungen –Änderungen sollen weder ignoriert noch durchgewunken noch verloren gehen. –Änderungen sind im Hinblick auf den Business Case zu beurteilen. 7. Fortschritt –regelmäßiger Vergleich der erbrachten Leistungen im Projekt mit den Planzielen –dient der geschäftlichen Rechtfertigung 27© Prof. Dr. Walter Ruf

28 Prozesse PRINCE2 unterscheidet 7 Prozesse, die projektspezifisch anzupassen sind. Prozessmodell von PRINCE2 28 Wagner, A.; Ziller, C.: IT-Projektmanagement: klassisch-agil, in: Kammerer, S.; Lang, M.; Amberg, M.: IT-Projektmanagmeent Metnoden – Best Practices von Scrum bis PRINCE2, 2012; S. 178 © Prof. Dr. Walter Ruf

29 5.2.3 Überblick: Prozesse von PRINCE2 1.Vorbereiten eines Projektes –Soll das Projekt überhaupt gestartet werden? Erste Kosten- / Nutzenschätzungen vorläufiger Business Case Klärung von Verantwortlichkeiten 2.Initiieren eines Projektes –Konkretisierung des Vorbereitungsprozesses Wie soll das Projekt gesteuert werden? Welche Projektergebnisse können erwartet werden? Tailoring (Anpassung der Prozesse) 3.Lenken eines Projektes –Unterstützung für den Lenkungsausschuss durch Bereitstellung von Informationen –Freigabe von Phasenplänen für Folgephase 29© Prof. Dr. Walter Ruf

30 Überblick Prozesse von PRINCE2 (Fortsetzung) Steuern der Phase –„Tagesgeschäft“ eines Projektmanagers –Koordination von Arbeiten –Verwaltung von Risiken und offenen Punkten –Erfassung Projektfortschritt Managen eines Phasenüberganges –Arbeiten nach jeder Phase / Verantwortung: Projektmanager –Informationsversorgung für den Lenkungsausschuss –Retrospektive der vorhergehenden Phase Managen der Produktlieferung –Erstellung der Projektergebnisse –Maßnahmen zur Qualitätsprüfung –Abnahmedokumentation 30© Prof. Dr. Walter Ruf

31 5.2.4 Merkmale und Besonderheiten Projektmanager trägt die Verantwortung für eine Phase die Gesamtverantwortung trägt der Lenkungsausschuss die Verantwortung für die Nutzung trägt der Benutzervertreter 31© Prof. Dr. Walter Ruf

32 Ablauf eines PRINCE2: 2009 Projekts 32 %C3%9Cbersichtsgrafik/dp/ /ref=pd_cp_eb_0 © Prof. Dr. Walter Ruf

33 33© Prof. Dr. Walter Ruf

34 5.3 PMBOK Guide PMI = Project Management Institut –Gründung 1969 USA (Atlanta) –mehr als Mitglieder –mitgliedstärkste Vereinigung im Bereich Projektmanagement PMBOK Guide = Guide to the Project Management Body of Knowledge –weit verbreiteter Projektmanagement-Standard –anerkannt durch: ANSI und IEEE PMI führt Zertifizierungen durch –CAPM Certified Associate in PM; PMP Project Management Professional In Deutschland findet man Chapter in Berlin, München, Frankfurt und Köln © Prof. Dr. Walter Ruf34

35 PMBOK Guide enthält eine Sammlung von „Best Practices“ die Empfehlungen sind generisch aufgebaut und eignen sich für eine Vielzahl von Projekten –Industrieanlagenbau, Organisationsprojekte  PMBOK Guide kann auch für Softwareentwicklungsprojekte verwendet werden! „Mit dem PMBOK Guide lassen sich theoretisch auch Softwareprojekte durchführen; ohne eine spezifische Anpassung fällt eine pragmatische, effiziente und effektive Umsetzung jedoch sehr schwer.“ von Brisinski, N.; Vollmer, G.: Pragmatisches IT- Projektmanagement; 2010, S. 16  Frameworks gilt es unternehmens- und projektspezifisch anzupassen! 35© Prof. Dr. Walter Ruf

36 5.3.1 Grundstruktur und Aufbau PMBOK Guide PMBOK-Guide kommt ohne Phasenmodell aus 36© Prof. Dr. Walter Ruf

37 PITPM auf der Basis vom PMBOK-Guide PITPM = Praktisches IT- Projektmanagement –Adaption des PMBOK-Guide für die Softwareentwicklung von N. Spitczok; G. Vollmer: Pragmatisches IT_Projektmanagement; Softwareentwicklungsprojekte auf Basis des PMBOK Guide führen; dpunkt.verlag 2010 © Prof. Dr. Walter Ruf37

38 5.3.1 Grundstruktur und Aufbau © Prof. Dr. Walter Ruf38 Projekte werden in 5 Phasen und 9 Areas of Knowledge eingeteilt

39 5.3.2 Areas of Knowledge (1) 1.Integrationsmanagement (Project Integration Management) –Integration aller Knowledge Areas (Anforderungen, Bedürfnisse usw.) –Stakeholder-Management (Koordination aller Personen, die Einfluss auf das Projekt haben) 2.Inhalts- und Umfangsmanagement (Project Scope Management) –Festlegung und Begrenzung des Projektumfanges 3.Qualitätsmanagement (Project Quality Management) –frühzeitige Integration von Qualitätsaspekten in alle Teilbereiche des Projektes 4.Kommunikationsmanagement (Project Communication Management) –Kommunikation mit Stakeholdern, Partnern und Projektbeteiligten © Prof. Dr. Walter Ruf39

40 Areas of Knowledge (2) 4.Risikomanagement (Project Risk Management) –Vermeidung / Bewältigung von Risiken 5.Zeit- und Teammanagement (Project Human Resource Management / Time Management) –Festlegung von Rollen –Erstellung eines Projektplanes 6.Beschaffungsmanagement (Project Procurement Management) –Beschaffung von externen Ressourcen und Materialien 7.Kostenmanagement (Project Cost Management) –Kostenschätzungen –Einhaltung von Projektbudgets 8.Softwareentwicklungsmanagement (gibt es im PMBOK-Guide nicht) –Einbindung der Prozesse der Softwareentwicklung in das PM © Prof. Dr. Walter Ruf40

41 PITPM-Projektphasen (1) 1.Vorbereitungsphase –Projektauftrag –Definition Projektumfang –erste Risikoeinschätzung –… 2.Planungsphase –Konfiguration des Projektes (Managementplan) –Detailplanung des Projektes (Umsetzung der Anforderungen in einen realen Plan) –Iterationsplanung –… 3.Durchführungsphase –Umsetzung des Projektes –Steuerung der Prozesse © Prof. Dr. Walter Ruf41 vgl. Spitczok, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; S. 30

42 PITPM-Projektphasen (2) 4.Einführung –Planungen für den Produktivbetrieb –Rollout des Produktes 5.Abschlussphase –formeller Projektabschluss –Abschluss der Verträge –Dokumentation der Erkenntnisse © Prof. Dr. Walter Ruf42 vgl. Spitczok, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; S. 31

43 PITPM-Projektkontrollpunkte Kontrolle wird als ein eigener Prozess verstanden K1: Projektauftrag erteilt K2: Projekt konfiguriert K3: Projektplanung abgenommen K4: Planung der Iterationen abgenommen K5: Bereitstellung zur Abnahme K6: Abnahme erteilt K7: Produktionsstart K8: Projektende © Prof. Dr. Walter Ruf43

44 5.3.3 Überblick Projektprozesse © Prof. Dr. Walter Ruf44 Abruf am

45 Zuordnung von Artefakten zu Prozessen und Phasen © Prof. Dr. Walter Ruf45 Abruf am

46 5.3.4 Prozesse Phase 1: Vorbereitungsphase V.1 Projektumfang bestimmen V.1.1 Leistungsumfang bestimmen –Projekt- und Produktziele festlegen –Produktabnahmekriterien festlegen –… –Eingangsartefakte Vom Auftraggeber bereitgestellte Dokumente –Methoden, Techniken, Werkzeuge Erhebungsmethoden; Workshop; –Ergebnisartefakte Projektumfangsbeschreibung (Projektumfangsbeschreibung.docx) (Projektumfangsbeschreibung.docx V.1.2 Risiken identifizieren –Eingangsartefakt: Projektumfangsbeschr. –Ergebnisartefakt: RisikoregisterRisikoregister © Prof. Dr. Walter Ruf46

47 Prozess V1: Projektumfang bestimmen (2) © Prof. Dr. Walter Ruf47

48 Prozess V2: Projekt beantragen Prozessüberblick © Prof. Dr. Walter Ruf48 Spitczok, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; S. 52

49 Prozess V.2.1: Projektauftrag entwickeln Festlegung einer Directorystruktur Checkliste zur Projektinitialisierung Ergebnisartefakt: Projektauftrag (Weiterentwicklung)Projektauftrag © Prof. Dr. Walter Ruf49

50 5.3.5 Prozess Phase 2: Planungsphase Spezifikation des Endproduktes Erstellung Projekthandbuch Entwicklung PSP (Projektstrukturplan) Verfeinerung der Risikoanalyse © Prof. Dr. Walter Ruf50

51 Prozess P.1.1 Projektorganisation festlegen Klärung Projektmitglieder und Organisationsstruktur © Prof. Dr. Walter Ruf51

52 Prozess P.1.2 Kick-off-Veranstaltung Treffen mit allen Projektteilnehmern –Projektteam, Linienstellen, Serviceorganisation, … Zwecke –Klärung Projektziel /-zeitraum –Meilensteine –Sponsoren –Vorstellung Projektteilnehmer –… Ergebnisartefakt: Protokoll Kick-off-Workshop © Prof. Dr. Walter Ruf52

53 Prozess: P1.3 Projektmanagementplan entwickeln Scope Management Plan Requirement Management Plan Schedule Management Plan (PSP) Cost Management Plan Human Resource Plan Ergebnisartefakte Projektmanagementplan © Prof. Dr. Walter Ruf53

54 Prozess P.2 Anforderungsmanagement konfigurieren Ziel: Festlegung von Vorgaben für die Durchführung der Anforderungsanalyse Festlegung der Infrastruktur für die Entwicklung Prozess: P 2.1 Anforderungsanalyse planen –Beschreibung von Anwendungsfällen (Use Cases) Anwendungsfälle beinhalten eine Sammlung von Aktionen  oft ist es schwierig in einer frühen Projektphase die Anwendungsfälle vollständig zu beschreiben © Prof. Dr. Walter Ruf54 Prototypingmodell Spitczok, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; S. 68

55 Prozess P.2.2 – 3.2 P 2.2: Änderungsanforderungen definieren –Wie geht man mit Änderungsanforderungen um? Bereitstellung von Rechner, Betriebssystem, Netzwerk, Zugänge P 3: Qualitätsplanung konfigurieren –P.3.1 Qualitätsplan erstellen Festlegung von konkreten Qualitätsstandards und deren Umsetzung Ergänzung des Projektplanes um das Kapitel „Qualitätsplanung“ –P.3.2 Testkonzept erstellen Im Testkonzept wird beschrieben, welche Systembestandteile zu welchem Zeitpunkt wie zu testen sind. Basis ist das Anfoderungsdokument Das Ergebnis wird in einem Testkonzept festgehalten.Anfoderungsdokument © Prof. Dr. Walter Ruf55

56 Prozess P.4 – P.6 P.4 Kommunikationsplanung –„Wie soll mit den Stakeholdern kommuniziert werden?“ Das Ergebnis wird im Projektmanagementplan festgehalten.Projektmanagementplan P.5 Risikoplanung konfigurieren –Klärung von Prinzipien und Regeln für das Risikomanagement –Reporting festlegen Das Ergebnis wird im Projektmanagementplan festgehalten.Projektmanagementplan P.6 Beschaffungsplanung konfigurieren –Planung von Waren- und Dienstleistungsbeschaffung Das Ergebnis wird im Projektmanagementplan festgehalten.Projektmanagementplan © Prof. Dr. Walter Ruf56

57 Prozesse P.7 – 7.2 P.7 Softwareentwicklung konfigurieren P. 7.1 Auswahl des Prozessmodells für die Entwicklung reine phasenorientierte Vorgehensmodelle sind problematisch –iterative Vorgehensmodelle –agile Vorgehensmodelle  Auswahl eines Prozessmodells und Festlegung der dazu notwendigen Aktivitäten  Das Ergebnis ist ein projektspezifisches Vorgehensmodell! P.7.2 Bereitstellung der Softwareentwicklungswerkzeuge –Identifikation, Beschaffung, Installation und Bereitstellung von allen für die Entwicklung erforderlichen Tools DBMS, Testwerkzeuge, SES © Prof. Dr. Walter Ruf57

58 Prozess P.8: Anforderungen spezifizieren Erhebung – Bestimmung und Beschreibung von Anforderungen ist die Basis für eine erfolgreiche Entwicklung! P.8.1 Fragebogen für die schriftliche Befragung –Was wollen die „Kunden“ Wer ehrliche Antworten will, sollte Vertraulichkeit zusichern übersichtlich gestaltete Fragebogen Fortschrittskennzeichnung Raum für individuelle Hinweise P.8.2 Qualitätssicherung des Fragebogens –Verständlichkeit der Fragen –„Test“ eines Fragebogens –Ergebnis: Fragebogen für eine schriftliche BefragungFragebogen für eine schriftliche Befragung An Stelle einer schriftlichen Befragung können auch Interviews durchgeführt werden. P.8.3 Schriftliche Befragung durchführen P.8.4 Interviewleitfasen erstellen P.8.5 Qualitätssicherung des Interviewleitfadens durchführen P.8.6 Interviews durchführen / protokollieren © Prof. Dr. Walter Ruf58

59 Prozess P.8: Anforderungen spezifizieren (2) P.8.7 Analyse unternehmensspezifischer Arbeits- und Geschäftsprozesse –Darstellung der vorhandenen Abläufe und der neuen, geplanten Abläufe (z.B. mit eEPK-Diagrammen) P.8.8 Anforderungsdokument erstellen –man unterscheidet: funktionale Anforderungen (z.B. Stammdatenerfassung) nicht funktionale Anforderungen (z.B. Aussehen und Handhabung, Antwortzeitverhalten, Erweiterbarkeit, …) –GUI-Entwürfe Entwürfe zur grafischen Benutzeroberfläche sollten frühzeitig den späteren Usern vorgestellt werden. P.8.9 Qualitätssicherung des Anforderungsdokuments P.8.10 Testfälle erstellen P.8.11 Abnahmetestfälle erstellen © Prof. Dr. Walter Ruf59

60 Prozess P.8: Anforderungen spezifizieren (3) P.8.12 Erster Projektstrukturplan –PSP = Projektstrukturplan (work breakdown structure) –PSP ist die Basis für Kostenermittlung im Projekt erforderlicher Arbeitseinsatz Liefergegenstände … –PSP kann iterativ entwickelt werden –Hierarchische Gliederung ist ratsam –PSP enthält die Arbeitspakete aus der Anforderungsdefinition (Anforderungskokument)  Werkzeug Projectmanagement Software (z.B. MS-Project) P.8.13 Anforderungsdokumentation abnehmen © Prof. Dr. Walter Ruf60

61 P.9 Risikobewältigung starten P.9.1 Risiken identifizieren P.9.2 Risiken bewerten und priorisieren –Ergebnisartefakt: Ergänzung Risikoregister Risikoregister P.9.3 Maßnahmen zur Risikobewältigung –Strategie: Vermeidung – Übertragung – Minderung - Annahme © Prof. Dr. Walter Ruf61

62 Prozess: 10 Projektplan erstellen Plan für das Gesamtprojekt Meilensteine (für Releasestände; Präsentationen; Iterationen) P.10.1 Aufgaben aufstellen und in PSP eingliedern P.10.2 Ressourcen planen –jedes Arbeitspaket wird später von einem MA verantwortet –Ermittlung der Vorgangszeiten (frühester Anfang/Ende; spätester Anfang/Ende) –Ermittlung vom kritischen Pfad © Prof. Dr. Walter Ruf62

63 Prozess: 10 Projektplan erstellen P10.3 Projektplan umsetzen –Empfehlungen sprechende Namen für die Arbeitsgänge realistische Zeitschätzungen Übersichtlichkeit Granularität (auf der untersten Ebene sollten Arbeitspakete gebildet werden) –Vorschlag: Dauer für ein Arbeitspaket ca. 2 – 7 Tage –Vorschlag: keine Überstundenplanung / keine Wochenendarbeit –Ergebnis: Ganzheitlicher ProjektplanProjektplan © Prof. Dr. Walter Ruf63

64 Prozess: P.10.4 – P.13 P.10.4 Projektteam aufstellen P.10.5 Projektteam formen und entwickeln –ggf. Schulungsmaßnahmen planen P.11 Beschaffung planen –Zuordnung von Beschaffungsmaßnahmen (wie externer Berater; Lizenzen, Versicherungen) zu Vorgängen und deren zeitliche Festlegung P.12 Kostenplanung initialisieren –Voraussichtliche Projektkosten ermitteln Kostenverlaufsplan erstellen P.13 Iterationen planen –Anforderungen an Iterationen festlegen Festlegung der Iterationsinhalte mehrere Iterationen führen zu einem auslieferbaren Release © Prof. Dr. Walter Ruf64

65 Prozess P.14 Softwareentwicklung für aktuelle Iteration planen Voraussetzung für iterative / agile Softwareentwicklung –P.14.1 Spezifikation erstellen Ergebnisartefakt: Spezifikationsdokument GUI-Modell –P.14.2 Qualitätssicherung der Spezifikation –P.14.3 Spezifikation abnehmen und freigeben –P.14.4 Entwurf erstellen –P.14.5 Qualitätssicherung des Entwurfsdokuments durchführen –P.14.6 Entwurf abnehmen und freigeben © Prof. Dr. Walter Ruf65

66 5.3.6 Prozesse Phase 3: Durchführung © Prof. Dr. Walter Ruf66 Spitczok, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; S. 152

67 Prozess: D.1- D.2 D1 Projekt steuern –D.1.1 Projekt führen Durchführung von Iterationen stehen im Mittelpunkt Projektmanager hält die für den Kunden wichtigen Ereignisse im Projektlogbuch fest –D. 1.2 Projektverlauf überwachen und steuern Vergleich der Istwerte mit dem Projektplan Führung der Liste „Offene Punkte“ D.2 Projektumfang kontrollieren und anpassen –D.2.1 Projektumfang verifizieren Die einzelnen gelieferten Teilergebnisse sollen vom Kunden abgenommen werden Ergebnisartefakt: Erkannter Änderungsbedarf –D.2.2 Change Request verfassen anerkannte Änderungsbedarfe führen zu einer Änderungsanforderung einem „Change Request“ (CR) (nur wenn dadurch zusätzliche Kosten und Entwicklungszeitänderungen entstehen) Änderungsanforderung © Prof. Dr. Walter Ruf67

68 Prozess D.3 Produktqualität kontrollieren zu jedem Iterationsschritt gehören abschließende Tests D.3.1 Testplan erstellen –Beispiele: Komponententest; Integrationstest; Schnittstellentest; Lasttest, Systemtest, Abnahmetest D.3.2 Tests durchführen –Ergebnisartefakt: Testprotokoll D.3.3 Test dokumentieren © Prof. Dr. Walter Ruf68

69 Prozess D.4 Projektkommunikation D.4.1 Stakeholder einbeziehen und informieren –Stakeholder haben maßgeblichen Einfluss auf das Projekt –Tipp: Transparenz schaffen – Vertrauen gewinnen Probleme nicht verschleppen oder verschleiern! D.4.2 Projektstatusbericht erstellen –Inhalt: erledigte / offene Punkte; Risiken; Ressourcenverbrauch; erreichte Meilensteine; –Ergebnisartefakt: StatusberichtStatusbericht © Prof. Dr. Walter Ruf69

70 Prozess D.5 Risiken überwachen D.5.1 Bestehendes Risikoregister abgleichen und ergänzen –ggf. Risikoworkshop durchführen –Ergebnisartefakt: aktualisiertes Risikoregister D.5.2 Maßnahmen zur Risikobewältigung planen © Prof. Dr. Walter Ruf70

71 Prozess D.6: Projektteam steuern Erstellung dedizierter Arbeitsauftrage für jedes Teammitglied –Integration von jungen Projektmitgliedern ins Team –Rücksicht auf unterschiedliche Charaktere D.6.1 Zusammenstellung von Entwicklungsteams D.6.2 Teammitglieder ein uns ausplanen –Vorsicht bei der Speicherung personenbezogener Daten! (ggf. Abstimmung mit Mitarbeitervertretung) D.6.3 Arbeitsaufträge für Teammitglieder erstellen –Arbeitsaufträge können z.B. aus MS-Project heraus generiert werden. –Inhalt von Arbeitsaufträgen: Bezeichnung; Abgrenzung; Voraussetzung; Besondere Risiken; ArbeitsunterlagenArbeitsaufträgen © Prof. Dr. Walter Ruf71

72 Prozess D.7 Externe Leistungen kontrollieren in vielen Projekten benötigt man externe Leistungen –z.B. Formulierung von Allg. Geschäftsbedingungen durch einen Juristen; Installation von Glasfaserkabel durch Elektriker D.7.1 Externe Leistungen kontrollieren D.7.2 Externe Leistungen abrechnen D.7.3 Vertrag kündigen –sofern die Leistung des externen Dienstleisters nicht mehr benötigt wird D.7.4 Dienstleister bewerten © Prof. Dr. Walter Ruf72

73 Prozess D.8 Projektkosten kontrollieren Kostenkontrolle ist eine zentrale Aufgabe des PM D.8.1 Projektkosten erfassen –Nur mit den erfassten Kosten ergibt sich noch keine Projektkontrolle! –Zur Projektbewertung benötigt man noch den Fertigstellungsgrad. –Soll-/ Istvergleich erfolgt über den Projektplan D.8.2 Projektkosten aktualisieren © Prof. Dr. Walter Ruf73

74 Prozess: D.9 Softwareprodukt entwickeln D.9.1 Software implementieren –Quellcode wird erzeugt D.9.2 Softwarekomponenten testen D.9.3 Softwarekomponenten integrieren D.9.4 Softwareprodukt testen © Prof. Dr. Walter Ruf74 Spitczok, N.; Vollmer, G.: Pragmatisches IT-Projektmanagement; S. 188

75 Prozess D.10 Abnahmetest durchführen vertragliche Regelungen zur Abnahme vorsehen! D.10.1 Abnahmebereitschaft erklären –PM muss dem Auftraggeber gegenüber die Abnahmebereitschaft erklären Abnahmebereitschaft erklären –Teilabnahmen, Ersatz für nicht durchgeführte Abnahmen usw. D.10.2 Abnahmetest koordinieren D.10.3 Abnahmetest durchführen D.10.4 Abnahme erklären D.10.5 Liefergegenstand nachbessern © Prof. Dr. Walter Ruf75

76 5.3.7 Prozesse Phase 4: Einführung Die Einführung eines neuen Softwaresystems muss gut geplant werden. –Parallelbetrieb zur bestehenden Lösung –sukzessive Einführung Rollout Zeitfenster festlegen –Umstellung zu einem Zeitpunkt Planung der Schulung für Key-User E.2 Produkt einführen –Übernahme der Verantwortung geht auf den Kunden über © Prof. Dr. Walter Ruf76

77 Prozess E.2 Produkt einführen E.2.1 Produkt einführen –Übernahme der Verantwortung geht auf den Kunden über E.2.2 Produktverantwortung abgeben © Prof. Dr. Walter Ruf77

78 5.3.8 Prozesse Phase 5: Abschlussphase Formelle Beendigung des Projektes Projektabschlussberichte / Zusammenfassung der Dokumente A.1 Projekt abschließen A.2 Risikoregister schließen A.3 Teammitglieder ausplanen –Teammitglieder in neue Organisationsform überführen –Projektabschlussworkshop durchführen –Verträge beenden –Projektkostenrechnung abschließen –Abschlussbericht und Feedback erstellen –Entwicklungsprozess bewerten © Prof. Dr. Walter Ruf78

79 Bewertung PMBOK-Guide Vorteile –umfassender, weit verbreiteter Standard –regelmäßige Anpassung und Überarbeitung –gut nachvollziehbare Umsetzung von Projekten –hohe Granularität der Prozesse –anerkannter Standard (IEEE; ANSI) Nachteile –durch die breite Anwendbarkeit besteht ein hoher Tailoringaufwand für die konkrete Projektanpassung –beinhaltet keine PM-Methodik –geringe Flexibilität im Vergleich z.B. zu PRINCE2 –hoher Administrationsaufwand –Phasenmodell muss zusätzlich erstellt werden –keine Dokumentenvorlagen vom PMI © Prof. Dr. Walter Ruf79

80 IPMA IMPA International Project Management Association © Prof. Dr. Walter Ruf80

81 Interessante Links Deutsche Gesellschaft für Projektmanagement (GPM) –http://www.gpm-ipma.de/startseite.htmlhttp://www.gpm-ipma.de/startseite.html GPM-Blog –http://gpm-blog.de/http://gpm-blog.de/ OpenPM (Verein für Projektmanagement) –https://www.openpm.info/dashboard.actionhttps://www.openpm.info/dashboard.action PMI Deutschland –http://www.pmigc.de/http://www.pmigc.de/ Projektmanagement Blog –http://www.pm-handbuch.com/http://www.pm-handbuch.com/ © Prof. Dr. Walter Ruf81


Herunterladen ppt "Projektmanagement 5. Frameworks und Normen im IT- Projektmanagement 1 © Prof. Dr. Walter Ruf."

Ähnliche Präsentationen


Google-Anzeigen