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

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

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

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

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

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] 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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

Ü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 28.03.2017 © 2009 - Christian Gütl

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) 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 !!! 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 ! 28.03.2017 © 2009 - Christian Gütl

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) 28.03.2017 © 2009 - Christian Gütl

Abschnitt 3 Prelaunch Stage Sollen wir oder sollen wir nicht? 28.03.2017 © 2009 - Christian Gütl

Ü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 28.03.2017 © 2009 - Christian Gütl

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) 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 … 28.03.2017 © 2009 - Christian Gütl

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] 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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“ 28.03.2017 © 2009 - Christian Gütl

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 ! 28.03.2017 © 2009 - Christian Gütl

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

Ü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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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

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

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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] 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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) 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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

Ü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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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) 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

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 !!! 28.03.2017 © 2009 - Christian Gütl

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

Ü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 28.03.2017 © 2009 - Christian Gütl

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 28.03.2017 © 2009 - Christian Gütl

Fragen und Anmerkungen! Danke! Thanx! 28.03.2017 © 2009 - Christian Gütl

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