Projektmanagement - Block 2 Projektmanagementprozess

Präsentation zum Thema: "Projektmanagement - Block 2 Projektmanagementprozess"—  Präsentation transkript:

1 Projektmanagement - Block 2 Projektmanagementprozess
Institut für Informationssysteme und Computer Medien (IICM) Fakultät für Informatik - Technische Universität Graz, Austria Christian Gütl Version 1.00 block3_ss2009.ppt

2 Agenda Einführung in Project Process Architecture Idea Stage
Prelaunch Stage Launch Stage Execute Stage Implementation & Operation Stage © Christian Gütl

3 Ziele Einen Projektmanagementprozess kennenlernen
Die wichtigen Phasen verstehen Die wichtigsten Aktivitäten/Prozesse der Phasen kennenlernen In Projekten zur Anwendung bringen © Christian Gütl

4 Literaturhinweis Project Management for Information, Technology, Business and Certification Gopal K. Kapur ISBN-10: Publisher: Prentice Hall Copyright: 2005 Format: Cloth; 528 pp ca. $98.80 © Christian Gütl

5 Abschnitt 1 Einführung in Project Process Architecture (PPA)
© Christian Gütl

6 Project Process Architecture (PPA)
… entwickelt von „Center for Project Management“, Gopal K. Kapur … 6 Phasen mit STOP/GO, max. 33 Prozessschritte … anpassbare Projektmanagementmethode … für IT und Business Projekte Nach [Kapur 2005] © Christian Gütl

7 Hinweise Zwischen Phasen Entscheidungspunkte
Projektleiter bespricht mit Projektsponsor die erarbeiteten Ergebnisse Projektsponsor entscheidet Überarbeitung GO STOP Verschiedene zuständige Personen für verschiedene Projektphasen (Stages) möglich Für verschiedene Stages verschiedene Personengruppen Projektleiter und Projektsponsor können sich über die Phasen ändern © Christian Gütl

8 Abschnitt 2 Idea Stage Ist die Idee brauchbar? © 2009 - Christian Gütl
© Christian Gütl

9 Überblick Zielsetzung Schritte dieses Abschnittes
„Halbgebackene Ideen“ von guten Ideen zu trennen Filterfunktion Gute Ideen in einen Projektvorschlag überzuführen Ideen strukturiert darstellen Entscheidungshilfe für Entscheidungsträger Schritte dieses Abschnittes Projektidee-Beschreibung (Idea Statement) Zwischenüberprüfung Projektvorschlag (Project Request) Go / No Go Entscheidung © Christian Gütl

10 Idea Statement 1 Zuständigkeit Dient zur … Idea Statement Formular
Wird von Person/Abteilung ausgefüllt woher Idee stammt, wird in Datenbank gespeichert Dient zur … Strukturierung der Idee Gemeinsames Verständnis zu schaffen Ideen zu erfassen und zu verwalten Identifizierung ähnlicher Ideen Erste Filterwirkung durch Idea DB Manager  kann dann in Projektvorschlag übergehen Idea Statement Formular Idea ID Name vom Ideenurheber Datum Suchwörter (Keywords) © Christian Gütl

11 Idea Statement 2 Idea Statement Formular (ff) Situationsanalyse
Beschreibung der Vergangenheit und gegenwärtigen Situation Fokus auf Problem oder Bedürfnis Zweck des Projektes Rechtfertigung des Projektes Beschreibung was mit Projekt erreicht wird Achtung: Nicht das WIE vorwegnehmen !!! Wer nutzt es? Wo wird es eingesetzt? Benutzerkreise definieren Abteilungen oder Standorte definierten Welche Strategien werden unterstützt? Unterstützende Unternehmensstrategien darstellen © Christian Gütl

12 Idea Statement 3 Idea Statement Formular (ff)
Nutzen für die Unternehmung Gibt an zu welchen Grad bestimmte Ziel/Strategien der Unternehmung erreicht werden Kritische Erfolgsfaktoren Helfen den Erfolg des Projektes zu evaluieren Man unterscheidet 2 Kategorien Produkt bezogene: z.B. Usability, Qualität, Performance … Prozess bezogene: z.B. Wissenstransfer (Kunden und Team) Müssen messbare Kennwerte sein: 99,9% Uptime, 20 % weniger Hotline-Anfragen Fertigstellungstermin Kunden definieren häufig Endtermine … … noch bevor Problemlösung gefunden wird … … und damit kommt Projektmanager unter Druck !!! Termine hinterfragen !!! © Christian Gütl

13 Idea Statement 4  Idea DB Manger prüft die Idee
Zeitfenster einer guten Gelegenheit Projekte müssen oft in einem bestimmten Zeitfenster fertig gestellt werden Nur dann werden Strategien unterstützt Z.B. Demoversion für die CeBIT Projektauswirkungen auf die Unternehmung Wie und wo wirkt sich das Projekt aus  Existierende Systeme  Existierende Prozesse  Existierende Projekte Konsequenzen wenn Projekt nicht umgesetzt wird Was passiert wenn wir nichts tun? Z.B. Schwindenten Marktanteile Überlastung der Hotline  Idea DB Manger prüft die Idee © Christian Gütl

14 Der Projektvorschlag 1 Zuständigkeit Dient zur … Entscheidungspunkt 1
Wird von einem Projektmanager gemeinsam mit dem Ideenurheber und Fachexperten erarbeitet Dient zur … Verfeinerung der Projektidee Dient der Entscheidungsvorbereitung Entscheidungspunkt 1 Go / No Go Entscheidung der Ideen Phase Projektmanager und Team beurteilen gemeinsam Qualität der einzelnen Felder  internes Review  bei Bedarf wird nachgebessert Projektmanager und Sponsor besprechen die Idee Sponsor entscheidet © Christian Gütl

15 Der Projektvorschlag 2 Zusätzliche Einträge für Projektvorschlag
Key Stakeholder (Hauptanspruchsgruppen) An dieser Stelle identifizieren und festhalten Man unterscheidet Policy Level Stakeholder haben auf das Projekt Einfluss (interne u. externe) Implementation Level Stakeholder (interne u. externe) werden durch das Projekt beeinflusst Wichtige Annahmen Annahmen werden festgeschrieben, von denen man ausgeht Die Annahmen sollten verifiziert werden Achtung: oft werden offene Fragen/Problem (Issues) mit Annahmen verwechselt ! © Christian Gütl

16 Der Projektvorschlag 3 Zusätzliche Einträge für Projektvorschlag (ff)
Organisatorische Änderungen durch das Projekt Änderungen sind sensibel im Unternehmen Aufzeigen von Änderungen in den Bereichen Unternehmenskultur u. –politik, Technik Limit der Projektkosten Schwierig zu diesem Zeitpunkt festzulegen Hilfreicher Anhaltspunkt für weiteren Projektverlauf Finanzierende Stelle Woher kommt das Geld/Ressourcen für das Projekt Project Ownership Zuständigkeit/Verantwortung nach Projektende Ähnliche Projekte Darstellung von ähnlichen oder überlappenden Projekten (beantragt, laufend, abgeschlossen) © Christian Gütl

17 Abschnitt 3 Prelaunch Stage Sollen wir oder sollen wir nicht?
© Christian Gütl

18 Überblick Zielsetzung Wichtige Schritte dieses Abschnittes
Projektvorschlag wird systematisch analysiert In bis zu 13 Schritten (Größe & Komplexität) Strukturierter Projektantrag durch Projektmanager Projektsponsor entscheidet am Ende der Phase Wichtige Schritte dieses Abschnittes Detailliertere Projektbeschreibung Intra-Projekt Prioritätsanalyse Stakeholderanalyse Komplexitätsanalyse Issue & Risk Management Preliminary Scope Statement Project Size Estimation Project Charter Go / No Go Entscheidung © Christian Gütl

19 Projekt Beschreibung und Priorität
Detailliertere Projektbeschreibung Input von den vorherigen Schritten überprüfen Wird erweitert u.a. um Projektziele und Seiteneffekte Abbruchbedingung Intra-Projekt Prioritätsanalyse P. Erfolg = Schedule + Scope + Budget + Quality Wichtigkeit der 4 Dimensionen festlegen durch Kunden o. wichtigste Projektbeteiligte Am besten eine Reihung der 4 Dim. vornehmen Für Rang 1: legt „Must Have“ Punkte fest Für Rang 2 – 4: Verhandelbare Punkte festlegen Achtung: Reihung kann sich im Projektverlauf verändern (z.B. Aktionen von Mitbewerber) © Christian Gütl

20 Stakeholder Analyse Stakeholder Analyse
Wurden bereits in Ideen-Phase identifiziert Wichtig ist Einfluss und Ausmaß der Stakeholder auf das Projekt zu bestimmen Damit kann man Hauptakteure und ihre Einstellung identifizieren und darauf reagieren Mögliche Rollen der Stakeholder Champion: Unterstützen das Vorhaben Neutral: sehen keinen Vorteil  überzeugen  Champion Nemesis: wirken gegen das Projekt Comatose: hätten Projektvorteil, bringen sich jedoch nicht ein (andere Arbeit, …) Ignored: sind ausgegrenzt oder werden übersehen © Christian Gütl

21 Komplexitätsanalyse 1 Komplexitätsanalyse
… ist sehr wichtiger Punkt !!! Ermittlung bereits in dieser Phase Information wird benötigt Projektmanagementprozess zu adaptieren Umfang der einzelnen Schritte anzupassen Einfluss auf Projekt-Team Zusammensetzung Komplexität hängt ab von Zielsetzungen und „int. & ext. Umwelt“ Wichtigste Einflussbereiche sind Technische Dimension Wirtschaftliche Dimension Bestimmung durch Bewertung von Attributen: „low“ (0) bis „high“ (4) Mittelwertbildung je Dimension © Christian Gütl

22 Komplexitätsanalyse 2 Wirtschaftliche Attribute
Changing Business Rules Unfamiliar Markets Geographic Extent Mulitple Issues Vague Objectives Inexperienced Team Tight Time Scale High Financial Exposure … Technische Attribute Global Communication New Delivery Mechanism New Hardware New Software New Technology High Level of Integration No Standard Methods Inexperienced Team … © Christian Gütl

23 Komplexitätsanalyse 3 Hinweise
Attribute werden im Team gewertet und gemittelt Für beide Dimensionen den Mittelwert bestimmen Ergebnis zeigt den Komplexitätsbereich (I bis IV) Genauer Punkt im Diagramm nicht notwendig  nur der Bereich ist wichtig Nach [Kapur 2005] © Christian Gütl

24 Issue Management Issues … Issue Management …
Sind offene Fragen o. Meinungsverschiedenheiten Issues sind wie Schlaglöcher auf der Straße  zu viele Issues verhindern den ruhigen Projektvorgang Issue Management … Ist die Verwaltung und Lösung von Issues Verdrängte Issues  Risikokandidaten Vorgang soll umfassen Aufnehmen von Issues in Liste Zuordnen von Issues einem Bearbeiter Festlegen bis wann Issue gelöst sein muss Issue einer Lösung zuführen © Christian Gütl

25 Risk Management 1 Risiko Risikomanagement bzw. Risk Management
… ist ein Maß für die Wahrscheinlichkeit das Projektziel nicht zu erreich Risikomanagement bzw. Risk Management … ist die Art mit Risiko umzugehen … umfasst Risikoerkennung: Welche Risken gibt es? Bereiche: Technologie, Unternehmen, Personen, Tools, Anforderungen, Abschätzung Risikoanalyse: Wie wirkt sich das Risiko aus? Beurteilung v. Wahrscheinlichkeit u. Konsequenzen Risikoplanung: Wie gehe ich mit Risiko um? Anwendung verschiedener Strategien entsprechend Beurteilung der Risikoanalyse Risikoüberwachung: Gibt es Änderungen Ständige Überprüfung der Situation, Anpassung © Christian Gütl

26 Risk Management 2 Risikoanalyse Strategien im Umgang mit Risken
Beurteilung von Wahrscheinlichkeit, Stärke u. Bereich d. Auswirkung Besonderes Augenmerk auf Hohe Wahrscheinlichkeit und Starke Auswirkung Strategien im Umgang mit Risken Ignorieren (Geringe Wahrscheinlichkeit u. Stärke) Vermeiden (z.B. andere Technologie nutzen) Risiko auslagern (z.B. Subauftragnehmer) Minimierung (z.B. unterstützende Aktivitäten) Notfallplan Strategien und Handlungen vorbereiten, wenn der Fall eintritt (z.B. Ersatzlieferanten) Risikopläne führen und aktualisieren © Christian Gütl

27 Preliminary Scope Statement 1
Preliminary Scope Statement bzw. vorläufiger Projektumfang Dient dazu, gemeinsam mit dem Kunden den erwarteten Projektumfang zu definieren Ermöglicht Abschätzung d. Projektgröße Dazu beschreibt man Deliverables: „Konkretes Ding“ das Funktion zur Verfügung stellt Funktionen: Zweck eines Objektes Features: Eigenschaften, Attribute d. Deliverables Z.B. Deliverable: Modem Funktion: Internet Zugang Feature: Telefon od. ADSL od. Wireless WICHTIG: auch „out of scope“ darstellen Verhindert falsche Kundenerwartungen © Christian Gütl

28 Preliminary Scope Statement 2
Vorgehensweise Deliverables, Functions und Features aus Stakeholder-Anforderungen identifizieren Wertung bzw. Einteilung im Team vornehmen „must have“, „should have“, „nice to have“, „fluff“ Fluff Einträge aussortieren Mit Kunden die Wertung von „nice to have“ und „should have“ durchgehen Daraus ableiten Current Scope Future Opportunities mit jeweils Begründung Out of Scope mit jeweils Begründung Scope Issues Noch nicht entschiedene Punkte Anzahl gibt Maß d. Meinungsverschiedenheit © Christian Gütl

29 Project Size Estimation
Project Size Estimation bzw. grobe Aufwandsabschätzung Spannungsfeld zwischen Ungenügend Informationen für eine genaue Aufwandsbestimmung Möglichst gute Einschätzung über Ressourcenaufwand und Projektdauer für die Go / No Go Entscheidung  siehe Block 6 „Aufwands- und Ressourcenplanung“ © Christian Gütl

30 Anmerkungen Project Charter (Projektauftrag) Go / No Go Entscheidung
Dient zur Durchsicht und als Entscheidungsgrundlage für den Projektsponsor Länge abhängig von Wichtigkeit u. Projektumfang Deckt in etwa die aufgezeigten Punkte ab Hier wieder internes Review durch das Team  bei Bedarf nachbessern Go / No Go Entscheidung Projektsponsor entscheidet Bei größeren Projekten mit oberem Management Einzelne vorgestellte Prozesse über Projektdauer verfolgen und aktualisieren  ggf. reagieren und Projekt anpassen ! © Christian Gütl

31 Abschnitt 4 Launch Stage Wie werden wir das Projekt abwickeln?
© Christian Gütl

32 Überblick Zielsetzung Wichtige Schritte dieses Abschnittes
Planung der Projektabwicklung In bis zu 11 Schritten (Größe & Komplexität) … wird durch Kernprojektteam abgewickelt Projektsponsor entscheidet am Ende der Phase Wichtige Schritte dieses Abschnittes Project Staging Project Organization Task und Prototyping Plan Staffing Plan Detailed Estimates Kommunikationsplan Go / No Go Entscheidung © Christian Gütl

33 Project Staging Project Staging Aktivitäten
Vorbereitung vom Projektstart Notwendige Informationen und Dokumente sammeln und bereit stellen Aktivitäten Vorliegende Informationen des Projektes prüfen In Thematik einarbeiten Treffen mit dem Projektsponsor Kickoff Meetings planen Kickoff Meeting mit Key Stakeholder Projektsponsor soll leiten Projektziele und erwartetes Ergebnis darstellen Kickoff Meeting mit Projektteam Projektsponsor Meeting eröffnen Projektmanager leiten Vorstellungen und Organisation besprechen © Christian Gütl

34 Project Organisation 1 Project Organisation
Häufiger Fehler: existierende Teamstruktur wird für Projekt übernommen  Unzureichende Kontrolle und Einflussnahme Starke Einflussnahme durch Linienmanager Festlegung der geeigneten Organisationsform Einflussgrößen: Komplexität u. Wichtigkeit Anmerkungen: Projekt Team und deren Struktur sollen für das jeweilige Projekt maßgeschneidert sein Projektorganisation ersetzt (teilweise) dauerhafte Unternehmensorganisation  Stellenbeziehungen Vollzeit Teammitarbeiter sind im Projekt effizienter Projektmanager benötigt mehr Verhandlungsgeschick als Macht im Team © Christian Gütl

35 Project Organisation 2 Projektorganisation Matrixorganisation
Projektkomplexität vs. Projektorganisation Projektorganisation Matrixorganisation Linienorganisation © Christian Gütl

36 Project Organisation 3 Praktischer Vorschlag „Project Organisation“
Allgemeine Hinweise Guter Startpunkt für eigene Projekte Kann gemäß den Erfahrungen angepasst werden nach [Kapur 2005] © Christian Gütl

37 Project Organisation 4 Das Projektteam Projektsponsor Steering Board
Notwendigen Kompetenzen um Projektteam bei Projektzielerreichung zu unterstützen Es sollte je Projekt nur einen Sponsor geben Steering Board Bei hoher Komplexität (I, ausgewählte in II und III) Bespricht und Trifft Entscheidungen NUR der Sponsor kommuniziert mit Projektmanager Projekt Manager Es soll nur einen Projektmanager geben Berichtet an Sponsor, u.U. auch an Linienmanager Projektmitarbeiter Je Aufgabe voll oder teilweise im Team Kunden Müssen nicht Teil der Organisation sein u.U. beispielhaft Vertreter von Abteilungen Fachexperten bei Bedarf für Fachprobleme © Christian Gütl

38 Task und Prototyping Plan
Task Plan = Projekt Strukturplan + Netzplan Legt fest wie die Aufgaben abgearbeitet werden Hat NICHT Ressourcenabschätzungen zum Inhalt Grundlage für die Erstellung Wissensbasis (Erfahrungen der Vergangenheit) Erfahrungen der Vergangenheit (nicht formalisiert) Vermutungen und Inspiration (NICHT gut) Achtung: Taskplan mit Riskplan verknüpfen !!!  Siehe Block 1 Prototyping Plan In IT und Business Projekten werden Prototypen häufig genutzt Unklare Punkte zu klären Besseres Verständnis zu bekommen  Siehe Block 4 und 5 © Christian Gütl

39 Staffing Plan 1 Staffing Plan Steering Board
Staffing bzw. Team Design abhängig von Projektziel Stakeholder Analyse Projektkomplexität Risk Analyse Projektumfang und Taskplan Steering Board Nur notwendig bei Projekttype I im oberen Bereich von Projekttype II und III Aus den notwendigen Fachbereichen Mit notwendiger Autorität Fach-, Methoden- u. Organisationswissen © Christian Gütl

40 Staffing Plan 2 Sponsor Anspruch vs. Projektkomplexität
Muss notwendige Kompetenzen haben (80 % der Geschäftsfälle im Projekt selbst entscheiden !!!) Notwendige Autorität CEO Senior Business Executive Senior IT Managers IT Managers Senior Business Managers Business Managers Future Managers nach [Kapur 2005] © Christian Gütl

41 Staffing Plan 3 Projektmanager Muss Aufgaben im Projekt gerecht werden
Projektziele zu erreichen Probleme behandeln und lenkend eingreifen Projekt und Team unterstützen und managen Motivieren und „Wir“-Gefühl vermitteln Projekt-Planung, -Durchführung und -Kontrolle Hinweis: Teilweise Überschneidungen mit Sponsor  hat anderer Blickpunkt, abstrakterer Sichtweise Wie viele Projekte gleichzeitig zu managen? Zone I Projekt: 1 Sehr komplexe Zone II und III Projekte: 2 Wenige komplexe Zone II und III Projekte: 3 Zone IV Projekte: 4 © Christian Gütl

42 Staffing Plan 4 Administrative Support (PM Assistent)
Für Zone I Projekte bis zu Ganztagesstelle Für Zone II u. III Projekte etwa ½ Tages-Job Projektmitarbeiter Anforderungen für Stellen gemäß Task Plan, Komplexitäts- und Risk Assesment Teambesetzung gemeinsam mit Linienmanager, u.U. auch mit Sponsor Hinweise: Engagement bei Teambesetzung zahlt sich aus Nicht immer sind die Besten verfügbar Wichtig sind menschliche u. fachliche Eigenschaften Die Stärken identifizieren und nutzen Gruppenleiter (für große Projekte) © Christian Gütl

43 Detaillierte Abschätzungen
Detaillierte Abschätzungen von Projektaufwand Projektlaufdauer Projektkosten  Projektbudget Berücksichtigt Individuelle Leistungsfähigkeit der Projektmitarbeiter Grad von Unterbrechung und parallele Aktivitäten Produktivitätsbeeinflussende Faktoren Z.B. Projektwiderstand, Verteiltheit des Teams, …  Siehe Block 6 © Christian Gütl

44 Kommunikationsplan u. Review
Insbesondere in Umsetzungsphase klare Kommunikationskanäle notwendig Hinweis: für unterschiedliche Adressaten in unterschiedlichem Umfang und Häufigkeit Z.B. Projektmanager u. Mitarbeiter: täglich, wöchentlich Projektmanager u. Sponsor: 14-tägig Steering Board: alle 2 Monate oder 1/4-jährlich Go / No Go Entscheidung Ergebnis sind die diversen Planungsdokumente Internes Review durch Projektmanager u. Team Vorlage an den Projektsponsor Projektsponsor entscheidet © Christian Gütl

45 Abschnitt 5 Execute Stage
Wie bringen wir das geplante Projekt zum Laufen bzw. wie halten wir es am Laufen? © Christian Gütl

46 Überblick Zielsetzung Schritte dieser Phase
2 Schritte für 60 bis 70 % der Projektlaufdauer Konkrete Umsetzung der Planung Überwachung und Steuerung Aufgabe des Projektmanagers Projektsponsor  läßt berichten/greift ein Schritte dieser Phase Task- und Projektterminplanung Fortschrittskontrolle und –korrekturen Bei Projektproblemen Anpassung oder Abbruch Go / No Go Entscheidung © Christian Gütl

47 Projektterminplanung
Durchführung Ausgangspunkt: Taskplan Verfügbarkeiten der Projektmitarbeiter Zuordnung Ressourcen zu Tasks Mitarbeiterbeurteilung  Stärke nach den Projekterfolgsfaktoren  Angepassten Aufwandsabschätzungen Konkreter Starttermin (und Endtermin)  Terminplan Erstellung mit Start der Durchführungsphase Hinweise Terminpläne und Taskpläne aktuell halten (Softwareunterstützung sinnvoll) Nicht vergessen: Reserven einplanen !!! Überarbeitung, Fehler, Umfangvergrößerung  Siehe auch Block 6 © Christian Gütl

48 Fortschrittskontrolle u. Steuerung
Soll-Ist-Vergleich  Abweichungen Abweichungen vom ursprünglicher Plan  Reaktion + Anpassung d. Pläne Fortschrittkontrolle umfasst Fortschrittskontrolle der Projektmitarbeiter Project Vital Signs (Gegenwärtiger Projektstatus) Look-ahead Window (Vorausblickender Projektstatus) © Christian Gütl

49 Fortschrittskontrolle 1
Fortschrittskontrolle der Projektmitarbeiter In regelmäßigen Intervallen und pünktlich Täglich, wöchentlich Auf jeweiligen Task bezogen geleisteter Umfang Status in % (geleistet und noch offen) Probleme Aktivitäten in der nächsten Kontrollperiode Wichtig Ist die Basis für Projektstatus Report bzw. Reports an Projektsponsor und Steering Board!!!! Aktivitätenreport sollte für Projektmitarbeiter selbstverständlich sein © Christian Gütl

50 Fortschrittskontrolle 2
Project Vital Signs (Gegenwärtiger Projektstatus) Lebenszeichen überwachen (analog zu Medizin, Auto, …) Strategische Signale Veränderung der Voraussetzungen für Projektdurchführung? Z.B. Technische Sinnhaftigkeit, Strategieänderungen, usw. Taktische Signale Wie gut erreichen wir die angestrebten Ziele? Z.B. Kritischer Pfad, Open Issues Projektumgebung Unterstützt die Projektumgebung des Projekt? Z.B. Effektiver Teameinsatz, Störung durch andere Projekte © Christian Gütl

51 Fortschrittskontrolle 3
Look-ahead Window (Vorausblickender Projektstatus) Kurzzeitvorausschau Je Mitarbeiter über ein Zeitfenster von etwa 4 Wochen Tasks, Deliverables, mögliche Probleme Langzeitvorausschau Geschätzter Endtermin und Gesamtkosten Sind geplante Ressourcen verfügbar?  Gibt dem Projektleiter die Möglichkeit zu agieren anstatt nur zu reagieren !!! © Christian Gütl

52 Abschnitt 6 Implementation Stage
Wie bringen wir die Projektergebnisse in die operative Phase? © Christian Gütl

53 Überblick Zielsetzung Schritte dieser Phase
Vorbereitung der operativen Phase Bis zu 2 Schritte Aufgabe des Projektteams Schritte dieser Phase Project Implementation & Closure (Process Assessment) Go / No Go Entscheidung © Christian Gütl

54 Project Implementation
Vorbereitung der Operation Group Voraussetzungen für Produkteinsatz (Hard u. Software) Schulung Administrator Guide Administrative Support Help Desk Vorbereitung der Kunden bzw. Endanwender User Guide Einführungsphasen Gruppen- od. abteilungsweise Je Gruppe od. Abteilung erste Anwender Project Closure Projektorganisation auflösen Feedback f. weitere Projekte  Projektdatenbank © Christian Gütl

55 Fragen und Anmerkungen!
Danke! Thanx! © Christian Gütl

56 Quellen 1 [Kapur 2005] Kapur, G.K.: Project management for information, technology, business, and certification; Pearson Prentics Hall, Ohio, USA, 2005. © Christian Gütl