IT-Projektmanagement im Kontext der Industrialisierung und Internationalisierung

Transkript

1 Accenture Technology Consulting IT-Projektmanagement im Kontext der Industrialisierung und Internationalisierung Sascha Lüdecke, November 2011 Copyright 2011 Accenture All Rights Reserved. Accenture, its logo, and High Performance Delivered are trademarks of Accenture.

2 Hinweise zur Prüfungsrelevanz und Umfang der Präsentation Einige Folien wurden im Vortrag nicht gezeigt. Aus Gründen der Vollständigkeit sind diese im Foliensatz aber enthalten. Der Teil Detail: Projektsteuerung und kontrolle ist prüfungsrelevant. Die entsprechenden Folien sind rechts oben markiert als: Prüfungsrelevant 2

3 Ziel der Vorlesung ist, ein Verständnis für die Problemfelder und den Beratungsansatz im Großprojektmanagement aufzubauen. Überblick, Definition & Abgrenzung Verstehen, was unter IT-Großprojektmanagement verstanden wird und wo die Probleme im Management von IT-Projekten liegen Erfolgsfaktoren Verstehen, welche Faktoren für den Erfolg und das Scheitern von IT-Großprojekten verantwortlich sind Methoden, Prozesse & Tools Kennen lernen der wichtigsten Prozesse, Rollen und Verantwortlichkeiten sowie Werkzeuge zum Management von IT-Großprojekten Besonderheiten für Großprojekte Darstellung von Besonderheiten im Management von IT-Großprojekten im Kontext der Industrialisierung und Internationalisierung 3

4 '96 '97 '98 '99 '00 '01 '02 '03 '04 '05 '06 '07 '08 '09 '10 '11 Die beste Adresse für außergewöhnliche Absolventen Unternehmensprofil Einer der weltweit führenden Managementberatungs-, Technologie- und Outsourcing-Dienstleister Jahresumsatz per 31. August 2011: 25,5 Milliarden USD Erneut und in Folge Top-100-Employer Platz 45 auf der Best Global Brands 2011 Rangliste 25,5 23,39 Umsatz weltweit (in Mrd. US$, per 31. August 2011) 15,55 16,65 19,7 21,58 21,6 11,44 11,57 11,82 13,67 8,22 9,55 9,75 4,94 6, Accenture All Rights Reserved. 4

5 Die beste Adresse für außergewöhnliche Absolventen Unsere Kunden: 28 der DAX-30-Unternehmen 94 der Fortune-Global-100- Unternehmen Mehr als drei Viertel der Fortune- Global-500-Unternehmen Über öffentliche und privatwirtschaftliche Organisationen Sind in über 120 Ländern der Erde vertreten Umsatz weltweit nach Branchen (in Mrd. US$, per 31. August 2011) Resources Products 5,93 4,88 5,43 3,86 5,38 Communications, Media &Technology Financial Services Health & Public Service 2011 Accenture All Rights Reserved. 5

6 Die beste Adresse für außergewöhnliche Absolventen Geographische Einheit ASG Österreich (A) Schweiz (S) Deutschland (G) Mitarbeiter rund Mitarbeiter Kunden Unsere Kunden sind die jeweils führenden Unternehmen in ihren Industrien z.b.: - Daimler - Land Hessen - Deutsche Bank - Siemens - Die Bahn - Swisscom 2011 Accenture All Rights Reserved. 6

7 Wir bieten unseren Mitarbeitern viel Ideales Arbeitsumfeld Tätigkeit in einem dynamischen und professionellen Umfeld, in dem die Leistung jedes Einzelnen anerkannt wird Stabilität Renommierter, internationaler und innovativer Arbeitgeber mit zukunftsorientierter Marktausrichtung und starker Marke Herausforderung Herausfordernde und abwechslungsreiche Aufgaben und Arbeitsinhalte Kollegialität Arbeit in internationalen Teams mit engagierten und hilfsbereiten Kollegen, die Experten auf ihrem Gebiet sind Entwicklung Gezielte und kontinuierliche Förderung der persönlichen Entwicklung und individuellen Karriere 2011 Accenture All Rights Reserved. 7

8 Sascha Lüdecke Manager Technology Consulting im Bereich IT Strategy & Transformation Fokus: IT Service Management Enterprise Architekturen Projekt Management Dipl. Inform an der TU Dortmund Verheiratet Ein Sohn (22 Monate)

9 Agenda Einleitung Was ist ein IT-Projekt? Faktoren für den Projekterfolg Übersicht: Projektmanagement-Methodiken Detail: Detail: Projektplanung Detail: Detail: Projektsteuerung und kontrolle Detail: Projektabschluss Besonderheiten im internationalen Kontext 9

10 Prominente Beispiele illustrieren das häufige Auftreten von Problemen im Management von IT-Großprojekten Allgemeine Probleme im Großprojektmanagement Typische Schlagzeilen aus der Vergangenheit 10

11 In 2008 wurde nahezu jedes vierte IT-Großprojekt vorzeitig abgebrochen. Erfolgsquote von Projekten Chaosreport 2009 (Standish Group) Ergebnisse der Umfrage nur 32% der Projekte waren erfolgreich (gegenüber 35% im Jahre 2006), 44% überzogen Zeit und Budget so beträchtlich, dass man nicht mehr von Erfolg sprechen kann (46% im Jahre 2006) 24% aller Projekte wurden sogar abgebrochen (2006 waren es 19%), was stets ein finanzielles Fiasko bedeutet. Typ 1 - Projekt erfolgreich abgeschlossen: Das Projekt wurde rechtzeitig, ohne Kostenüberschreitung und mit dem ursprünglich geforderten Funktionsumfang abgeschlossen. Typ 2 - Projekt teilweise erfolgreich: Das Projekt wurde abgeschlossen, es kam jedoch zu Kosten- und/oder Zeitüberschreitungen oder es wurde nicht der vollständige geplante Funktionsumfang erreicht. Typ 3 - Projekt nicht erfolgreich: Das Projekt wurde abgebrochen. Source; Chaosreport, Standish Group

12 Wenn IT-Projekte fehlschlagen, liegt das oft an Missverständnissen zwischen den Beteiligten durch unzureichende Kommunikation. Fehlschlagen von Projekten Warum Projekte fehlschlagen 12

13 Außerdem können die meisten IT-Projekte die Zeit-, Kosten- und Qualitätsvorgaben nicht erfüllen. Übersicht Problemfelder Gründe für das Fehlschlagen von IT-Projekten Zeit Nichteinhalten des gesetzten Zeitrahmens durch: Unrealistische/ fehlende Planung Fehlende Fortschrittskontrolle im Projekt Übersehen von Abhängigkeiten zwischen Arbeitspaketen und Meilensteinen Fehlende Ressourcen Qualität Nichterreichen der Qualitätsziele durch: Zu enges Zeitbudget Mangelhafte Einbeziehung der Fachbereiche Unzureichende Reviews auf Ergebnisse Zu kurze Testzeiträume Kosten Nichterreichen der Kostenziele durch: Ungenaue Leistungsplanung Fehlende Kostenkontrolle Aufwandsmehrung durch nachträgliche Konzeptänderungen (Change Requests) 13

15 Die Entwicklung betrieblicher Anwendungssysteme und Produkte mit Soft- und Hardwarekomponenten (IT-Systeme) erfolgt zumeist in Form von Projekten. Was ist ein Projekt? Allgemeine Definition Der lateinische Ursprung für den Projektbegriff ist "proiectum", was "das voraus Geworfene" bedeutet. Laut DIN ist ein Projekt ein "Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, z.b. Zielvorgabe, zeitliche, finanzielle, personelle und andere Begrenzungen, Abgrenzung gegenüber anderen Vorhaben, projektspezifische Organisation". (DIN 69901) Eigenschaften von Projekten Einmaliges Vorhaben Zeitlich begrenzt mit Start- und Endtermin Klare Ziele, definierter Auftraggeber aber für jedes Projekt verschieden Komplexe, interdisziplinäre Vorhaben mit verschiedenen Techniken und Methoden Neuartige, außergewöhnliche Probleme sind zu lösen komplexe Aufgabenstellung Vorhaben mit besonderem Risiko Eigenes begrenztes Budget Begrenzte Ressourcen (finanziell, personell, sachlich) Mitarbeiter aus Linienorganisation herausgenommen messbare Ziele & Ergebnisse Teamarbeit notwendig Wertgenierung (Value Creation) Zweck eines Projektes? Entweder oder Beitrag zur Wertgenierung des Unternehmens Beispiele: Konsolidierungsprojekt CRM-Einführung Wertsicherung (Value Protection) Beitrag zur Erbringung der Geschäftstätigkeit Beispiele: Buchhaltungssystem Monitoring-Lösung

16 Neben dem Projektleiter als zentrale Rolle für die Planung, Durchführung und Überwachung aller Projektaufgaben sind weitere wichtige Rollen im Projekt zu definieren und zu besetzen Projektrollen (1/2) Wichtige Rollen, Aufgaben und Verantwortlichkeiten in Projekten (Auszug) Rollen Verantwortlichkeit Aufgaben Projektleiter (PL) Verantwortlich für die Planung, Durchführung und Überwachung aller Aufgaben im Rahmen des Projektes hinsichtlich inhaltlicher Umsetzung (Qualität), Kosten- sowie Termineinhaltung zu erbringen sind. Plant, koordiniert und überwacht alle IT- Aktivitäten (und Ergebnisse) des Projektes Verteilt Aufgaben auf das IT-Projektteam Überwacht Aufwand (Bugdet), Ressourcen, Risiko und Termine Teilprojektleiter (TPL) Projekt- Mitarbeiter (PMA) Verantwortlich für die Planung, Durchführung und Überwachung aller Aufgaben die im Rahmen des Teil-projektes hinsichtlich inhaltlicher Umsetzung sowie Termineinhaltung zu erbringen sind. Verantwortlich für die Durchführung aller im Projekt zugewiesenen Aufgaben hinsichtlich inhaltlicher Umsetzung sowie Termineinhaltung Plant, koordiniert und überwacht alle Aktivitäten (und Ergebnisse) des Teilprojektes Führt die Kommunikation in Richtung Teilprojektteam und berichtet and PL Überwacht Aufwand und Termine Bearbeitet die zugewiesenen Aufgaben und meldet die Ergebnisse an den PL/TPL zurück Meldet größere Probleme oder Verzögerungen umgehend an den PL/TP Meldet das verbrauchte Budget zurück 16

17 Neben dem Projektleiter als zentrale Rolle für die Planung, Durchführung und Überwachung aller Projektaufgaben sind weitere wichtige Rollen im Projekt zu definieren und zu besetzen Projektrollen (2/2) Wichtige Rollen, Aufgaben und Verantwortlichkeiten in Projekten (Auszug) Rollen Verantwortlichkeit Aufgaben Berater (C) Einbringung fachlicher Expertise in das MN-I Entwicklungsprojekt Know-How Träger Punktuelle Unterstützung des Projektes für spezielle fachliche Themen Teilkoordination von fachspezifischen Aufgabenstellungen im Rahmen des Projektes Qualitätsbeauftragter (QB) Organisiert und verantwortet Audits und den Status zu prüfender Prozesse, Produkte und Projekte in Abstimmung mit dem Qualitätsmanager Nimmt die Quality Gates vom Projektleiter ab Moderiert und führt die qualitätssichernden Maßnahmen im Projekt Coach für Projektleiter; erstellt auf Anforderung Projekt QM Plan und führt Qualitätssicherung in Projekten auf Basis von Quality-Gates durch 17

19 Die allgemein bekannten Probleme in IT-Projekten sind umgekehrt gleichzeitig wichtige Erfolgsfaktoren für ein erfolgreiches Projektmanagement. Erfolgsfaktoren Allgemeine Erfolgsfaktoren für die erfolgreiche Wichtige Schlüsselfaktoren: Klare Ziele, Klare Anforderungen Unterstützung durch das Management Etablierung einer bewährten Projektmanagementmethodik und technik Team nach fachlichen und sozialen Aspekten auswählen; Mitarbeiter qualifizieren Bereitstellung von ausreichend Ressourcen und deren Zusicherung Hohe Qualifikationen, Flexibilität sowie Engagement Einbeziehung der Stakeholder und Endbenutzer Regelmäßiges Projektcontrolling Risiko einschätzen und im Verlauf prüfen (Risiko-Management); Etc. Hinzu kommen weitere Faktoren unter Einbeziehung der Anwender/Nutzer Standardisierte Software-Infrastruktur Angemessenes Vorgehensmodell einschließlich Qualitätssicherung für den gesamten Software-Life-Cycle Projektumfang - mit der Projektgröße sinkt die Termintreue Etc. 19

20 Die 5 Dimensionen des sog. SQERT Modells: Umfang, Qualität, Aufwand, Risiko und Zeit sind wichtige Schlüsselfaktoren für eine erfolgreiche. Erfolgsfaktoren SQERT Modell Wichtige Erfolgsfaktoren gemäß SQERT-Modell Qualitätsmanagement Quality Ressourcen Management / Controlling Effort Time Projekt- Controlling Project Scope Risk Erwartungen der Auftraggeber Issue- / Risk- Management 20

21 Für die erfolgreiche Durchführung eines Projektes müssen Management- Prozesse installiert werden, die dem Projektmanager alle Informationen zur Verfügung stellen, die im Projektverlauf benötigt werden. Erfolgsfaktoren - Projektmanagement-Prozesse (1/2) Wichtige PM-Prozesse Teil 1 Ressourcen-Management Definition der notwendigen Personen und Ressourcen (z.b. Computerausstattung) die während des Projektverlaufs oder nach der Einführung benötigt werden. Im Normalfall stehen die Ressourcen nicht auf Abruf zur Verfügung, sondern müssen geplant werden (z.b. Lieferzeiten bei Bestellungen, Verfügbarkeit von Personen). Management externer Dienstleister, Lieferanten Während eines Projektes müssen oftmals externe Beteiligte (Lieferanten, Berater, Experten) hinzugezogen werden. Die vertraglichen als auch projektspezifischen Vereinbarungen müssen an zentraler Stelle koordiniert und kontrolliert werden. Qualitätsmanagement Die Erwartungen der Auftraggeber enthalten meist Kriterien an die Qualität des Projektergebnisses. Diese Qualitätsansprüche müssen bei der Durchführung des Projektes ständig berücksichtigt werden und dürfen nicht erst zum Ende des Projektes hin gemessen und verifiziert werden (z.b. Antwortzeiten bei Anwendungssystemen, Qualität der Dokumentation). Konfigurationsmanagement Das Konfigurationsmanagement umfasst die Identifikation, Kontrolle und Überwachung von Dokumenten, dem Code, dem Business Case und allen anderen wichtigen Dokumenten oder Deliverables im Projekt. Hierbei wird darauf geachtet, dass Änderungen an diesen Elementen dokumentiert und kontrolliert werden. Bei Entwicklungsprojekten umfasst dies zum Beispiel die Versionskontrolle. 21

22 Für die erfolgreiche Durchführung eines Projektes müssen Management- Prozesse installiert werden, die dem Projektmanager alle Informationen zur Verfügung stellen, die im Projektverlauf benötigt werden. Erfolgsfaktoren - Projektmanagement-Prozesse (2/2) Wichtige PM-Prozesse Teil 2 Issue- / Risk- Management Alle Probleme, offenen Punkte und Entscheidungen, die einen Einfluss auf das gesamte Projekt haben müssen gesammelt und nachverfolgt werden. Oftmals entstehen aus diesen Issues Change Requests, die zu einer Veränderung des Projektumfangs führen. Fehler-Management Alle Abweichungen vom erwarteten Ergebnis werden erfasst und nachverfolgt. Der Status des Fehlers wird beginnend bei der Erfassung, bis zum Retest verfolgt. Das Fehler Management wird vor allem in der Projektphase Test benötigt. Financial-Management Im Rahmen des Financial Management müssen die Budgets verwaltet werden, die für das Projekt zur Verfügung stehen. Die Kosten umfassen sowohl die Arbeitskosten für die Mitarbeiter, als auch die Kosten für externe Dienstleistungen oder Materialien. Das Financial Management ist unter anderem auch dafür verantwortlich, dass der Business Case umgesetzt werden kann. Contingency-Management Bei Projekten wird sowohl ein Zeit als auch ein Budgetpuffer benötigt, um Risiken im Projektverlauf abzudecken. Dieses freie Budget wird an zentraler Stelle verwaltet und im Projektverlauf entsprechend der Notwendigkeit zwischen den verschiedenen Projekten und Teilprojekten verteilt. Beim freien Budget kann es sich um Geld, um Manntage und um Zeit handeln. 22

24 Projekt Management / Programm Management Die allgemeinen Phasen im Überblick Allgemeines Phasenmodell des Projektmanagement Allgemeines Phasemodell für das IT-Projektmanagement Projektplanung Die Projektplanung muss während des Projektverlaufs ständig überprüft, kontrolliert und erweitert werden. Die Informationen hierzu stammen aus dem Controlling und Reporting. Projektabschluss Projektsteuerung und -kontrolle 24

25 Vorgehensmodelle der Software-Entwicklung können grundsätzlich in a) lineare, b) iterative und c) agile Modelle unterschieden werden. Vorgehensmodelle der Softwareentwicklung Arten von SW-Entwicklung Linear Archetype: Iterative Archetype: Agile Archetype: Projects/ programs consist of stages (or: phases) which have to be completed one after another Moving to a previous phase is uncommon Projects/ programs are broken up into modules which are developed at different times or rates and are integrated as they are completed Projects/ programs are broken up into many smaller sub-projects These are frequently inspected and adapted to changing circumstances Waterfall Accenture Delivery Methodologies (ADM) Spiral Rapid Application Development (RAD) Feature Driven Development Extreme Programming (XP) 25

26 Agenda Einleitung IT-Projektmanagement Was ist ein IT-Projekt? Faktoren für den Projekterfolg Übersicht: Projektmanagement-Methodiken Detail: Detail: Projektplanung Detail: Detail: Projektsteuerung und kontrolle Detail: Projektabschluss Besonderheiten im internationalen Kontext 26

27 Die beschreibt alle zur Durchführung eines Projektes notwendigen Aktivitäten von der Projektidee/-anfrage, dem Projektantrag, der Projektfreigabe bis zum Start der Projektplanung. Beschreibung der (1/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Allgemeines Phasemodell für das IT-Projektmanagement Projektauftrag Aktivitäten Erstellung eines Projektantrags Benennung eines Projektleiters Identifizierung der Auftraggeber (intern/ extern) Verständnis der Stakeholder Erwartungen an das Vorhaben Festlegung der Projektdefinition und ziele Grobe Schätzung der geplanten Aufwendungen und Erstellung erste grobe Projektplanung Durchführung einer Wirtschaftlichkeitsbetrachtung (Business Case) Genehmigung/ Freigabe des Projektauftrags einholen Projektplanung Projektsteuerung und -kontrolle Projektabschluss 27

28 Die beschreibt alle zur Durchführung eines Projektes notwendigen Aktivitäten von der Projektidee/-anfrage, dem Projektantrag, der Projektfreigabe bis zum Start der Projektplanung. Beschreibung der (2/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Inputs (Voraussetzungen) / Outputs (Ergebnisse) Inputs: Projektantrag/-auftrag Liste der Projektauftraggeber Stakeholder (intern/extern) Vorstudie/ Grobkonzept Outputs: Genehmigter Projektauftrag einschließlich Verständnis der Stakeholder Erwartungen Business Case (Bewertung Wirtschaftlichkeit) Typische Problemfelder/ Herausforderungen Schnelles Starten des Projektes noch bevor der Projektumfang vollständig definiert wurde Quantifizierung und Qualifizierung des Nutzens zur Beurteilung der Wirtschaftlichkeit eines Vorhabens bereit vor den Projektleitern vor allem in Großprojekten oft Schwierigkeiten Ressourcen können nicht wie gewünscht an das Projekt gebunden werden Werkzeuge (Tools) Formular Projektantrag ExPECT Model Formular Business Case Lessons Learned/ Erfolgsfaktoren Ein formaler Projektantrag ist obligatorisch für alle durchzuführenden Vorhaben Alle mittleren oder größeren Projekte bedürfen der zwingenden Freigabe durch das Management dabei sollte weder zu restriktiv noch zu großzügig mit Genehmigungen verfahren werden Schlüsselrollen und Verantwortlichkeiten sollten bereits in der klar benannt und zugesichert sein 28

29 Vor der Projektplanung, ist es wichtig die Erwartungen des Auftraggebers (intern oder extern) zu verstehen, um einen vollständigen und zum Projektauftrag passenden Plan zu entwickeln. - Stakeholder Erwartungen (1/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Methodik zur Ermittlung von Stakeholder-Erwartungen 1. Welche Parteien sind in das Projekt involviert? 2. Erwartungen aller Beteiligten analysieren und verstehen. 3. Dokumentation der Erwartungen, Abstimmung mit Auftraggeber. 4. Änderung des Projektumfangs (Scope) durch Change Requests Beispiele für mögliche Erwartungen Die Anwendung besitzt eine Verfügbarkeit von 99% Es können 50 Transaktionen pro Minute bearbeitet werden Der Auftraggeber definiert die Geschäftsprozesse für die Systemkomponente A Das Projekt umfasst auch die Definition neuer Geschäftsprozesse im Bereich B Typische Problemfelder Fehler durch Doppelarbeit Leistungsumfang vor Beginn der Projektarbeit noch nicht vollständig bekannt Es wird notwendig wieder einen Schritt zurück zu gehen, um den Umfang zu klären, bevor die Arbeit am Projekt weitergeht kann. Dadurch können wertvolle Ressourcen (Personen) nicht genutzt werden, obwohl diese bereits für das Projekt geplant sind. Fehler im Design Wenn beim Design nicht alle Rahmenbedingungen bekannt sind werden Entscheidungen getroffen, die später häufig revidiert werden müssen. Die Kosten und der Zeitaufwand für die Integration neuer Funktionalitäten steigen mit der Dauer des Projektes überproportional an. Ein Änderung in der Mitte des Projektes kostet oft ein Vielfaches dessen, was diese Funktion zu Beginn gekostet hätte. 29

30 Die Erwartungen der Auftraggeber (Stakeholder) sollten grundsätzlich in drei Dimensionen eingeholt werden. - Stakeholder Erwartungen (2/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Das ExPECT Model Expectations Planning Execution Checking Tailoring Die Vorgehensweise und die Deliverables (Qualität) Zeitplan Budget Vorgehensweise Kultur Planen Die Ergebnisse und die erwarteten Vorteile Flexibilität Wartbarkeit Anpassen Erwartungen Ausführen Verfügbarkeit Wissenstransfer Beziehungen Den Beitrag zum Geschäft (Wertschöpfung) Spezifische Messgrößen Überprüfen Messbare Kriterien Erfolg des Teams, des Auftraggebers 30

31 Ein Business Case zeigt die wirtschaftliche Vorteilhaftigkeit und strategische Konformität des Gesamtprojektes auf für eine abschließende Management-Entscheidung über die Ausführung. - Business Case Projektplanu ng Projektabschlu ss Projektsteuerung und -kontrolle Was ist ein Business Case? Szenario zur betriebswirtschaftlichen Beurteilung einer Investition und aller entscheidungsrelevanter Aspekte eines geplanten Vorhabens durch Aufzeigen des erwarteten Gegenwertes ( Returns ) Ziel: Wirtschaftliche Vorteilhaftigkeit und strategische Konformität des Gesamtprojekts aufzuzeigen Business Case Elemente Strategie: Einklang des Projektes mit der Unternehmensstrategie Risiken: Abwägung hinsichtlich der möglichen Projektrisiken Kosten: Erhebung und Dokumentation aller Kostenfaktoren Nutzen: Erhebung und Dokumentation aller Nutzenfaktoren Kapital Projektkosten Kosten Nutzen Maßgebende Faktoren für die Wirtschaftlichkeit Nutzen Investitionsvarianten Projektdauer Betriebskosten Nutzungsdauer Zeit Risiken Strategie Maßgebende Faktoren für den Variantenentwurf Einführung Ablösung 31

32 Agenda Einleitung IT-Projektmanagement Was ist ein IT-Projekt? Faktoren für den Projekterfolg Übersicht: Projektmanagement-Methodiken Detail: Detail: Projektplanung Detail: Detail: Projektsteuerung und kontrolle Detail: Projektabschluss Besonderheiten im internationalen Kontext 32

33 In der Projektplanung steht die Identifikation der Arbeitspakete, die Erstellung des Projektstruktur, Projektablauf- und Terminplans sowie die Kapazitäts- und Ressourcenplanung im Vordergrund. Beschreibung der Projektplanung (1/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Allgemeines Phasemodell für das IT-Projektmanagement Aktivitäten Planung der Projektstruktur Projektplanung Projektplan Terminierung der Projektaufgaben und Meilensteine Feststellung des Projektaufwandes (Aufwandsschätzung) Sicherstellung der Verfügbarkeit geeigneter Ressourcen Risikoanalyse durchführen Projektabschluss Durchführung einer Kick-off Veranstaltung mit den Teammitgliedern Projektsteuerung und -kontrolle 33

34 In der Projektplanung steht die Identifikation der Arbeitspakete, die Erstellung des Projektstruktur, Projektablauf- und Terminplans sowie die Kapazitäts- und Ressourcenplanung im Vordergrund. Beschreibung der Projektplanung (2/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Inputs (Voraussetzungen) / Outputs (Ergebnisse) Inputs: Projektauftrag einschließlich Aufwandsschätzung Business Case Outputs: Projektplan (einschl. Ressourcenplan, Investitions- /Kostenplan, Risikoplan/-log, Issueplan/-log, Qualitätsplan, Traceability Matrix) Kick-off Meeting Typische Problemfelder/ Herausforderungen Projektstrukturierung, die inhaltlich, zeitlich und budgetär verfolgbar ist Abhängigkeiten ausreichend dargestellt Auslastungsoptimale Ressourcenzuordnung Werkzeuge (Tools) Projektplanungswerkzeuge (z.b. MS Project, Primavera, CA Clarity, etc.) Template Ressourcenplan Template Risiko/Issueplan Template Qualitätsplan Template Anforderungsmatrix (Tracebility Matrix) Template für Kick-Meeting Lessons Learned/ Erfolgsfaktoren Planungswerkzeug sollte auch als Steuerungswerkzeuge genutzt werden Auswahl eines geeigneten Aufwandsschätzung-Modells Automatisierungsgrad sollte möglichst hoch sein 34

35 Die Work Breakdown Structure soll hauptsächlich die Deliverables (keine Aktivitäten) enthalten, die von dem Projekt geliefert werden müssen. Projektplanung Work Breakdown (WBS) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Aufbau einer Projekt WBS-Struktur Jedes Elemente im WBS ist die Summe aller Elemente, die auf der nächsten Ebene liegen. Auf den obersten Ebenen finden sich oftmals die gleichen Elemente bei verschiedenen Projekten (z.b. Anforderungen, Design,...). Oftmals ist zu diesem Zeitpunkt noch nicht bekannt, wie die Deliverables erreicht werden können, aber es ist klar, dass es diese Deliverables geben muss. In der Detailplanung wird definiert, wie die in der Work Breakdown Structure definierten Deliverables erreicht werden können. 35

36 Der Aufwand für ein Projekt kann mit den zwei Ansätzen Top Down oder Bottom Up geschätzt werden. Der Projektaufwand wird aus dem Abgleich zwischen der Top Down und der Bottom Up Schätzung ermittelt. Projektplanung Aufwandsschätzung (1/2) Projektplanu ng Projektabschlu ss Projektsteuerung und -kontrolle Vorgehensweise - Top Down Schätzung Der Top-Down Ansatz wird normalerweise verwendet, um am Anfang eines Projektes eine grobe Abschätzung über den notwendigen Aufwand zu erhalten. Dieser Ansatz ist sinnvoll für den Projektantrag, da sehr schnell eine grobe Schätzung vorliegen muss Für das Management eines Projektes und das Controlling der Aufwände ist der Top Down Ansatz nicht geeignet, da Informationen nicht detailliert genug vorliegen. Vorgehensweise - Bottom Up Schätzung Dieser Ansatz wird verwendet, um den Aufwand ausgehend von einzelnen Aufgaben zu schätzen. Es werden Regeln verwendet, um die einzelnen Aufgaben besser abschätzen zu können und eine Vergleichbarkeit der Ergebnisse zu gewährleisten. Diese Planung kann für das Projektmanagement verwendet werden, da alle Informationen auf Aufgabenebene vorhanden sind. Top Down und Bottom Up Planung Top Down Schätzung Einflussfaktoren Kurzanalyse der zu erbringenden Leistungen Schätzmodelle mit wenigen Einflussfaktoren Erfahrungen aus früheren Projekten Aufschlag für Schätzgenauigkeit und Risiko Projektaufwand Bottom Up Schätzung Einflussfaktoren Analyse aller zu erbringenden Leistungen Detaillierte Schätzmodelle mit Regeln zur Berechnung der Aufwände pro Aufgabenpaket Geringere Schätzgenauigkeit und Risiko 36

37 Die Werte der Faktoren ergeben sich aus der Analyse der Elemente, dem Expertenwissen und den Erfahrungen aus früheren Projekten und bei Bedarf aus dem Prototyping zum Projekt. Projektplanung Aufwandsschätzung (2/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Regeln zur Aufwandsschätzung bei einer Bottom Up Betrachtung Mengen- Faktor z.b. Aufwand pro Objekt x Anzahl der Objekte Schwierigkeit / Komplexität WBS Element z.b. der Aufwand für das Design, die Implementierung und des Tests sind abhängig von der Komplexität Fester Aufwand z.b. die Durchführung einer Schulung zusätzlich Risikoaufschlag (Schätzgenauigkeit) zusätzlich Contingency (externe Faktoren) Prozentsatz z.b. Aufwand für Projektman agement als Prozentsatz vom Gesamtauf wand Anmerkungen zur Aufwandsschätzung + Erhöht die Transparenz der Berechnungen und die Nachvollziehbarkeit der Ergebnisse Objektive Basis zur Diskussion mit dem Programm- Management Die Ermittlung des Aufwandes über eine Bottom Up Schätzung und die Validierung der Ergebnisse über eine Top Down Betrachtung tragen wesentlich zum Projekterfolg bei.! Unterschiede bei den Kenntnissen und Fähigkeiten der Mitarbeiter wirken sich in unterschiedlicher Produktivität aus. Dies könnte zum Beispiel über einen Produktivitätsfaktor ausgeglichen werden. Bei neuen Technologien oder unbekannten Aufgaben bestehen keine Erfahrungen. In einem solchen Fall muss die Schätzgenauigkeit mit berücksichtigt werden. Die rechnerische Vorgehensweise garantiert nicht die Richtigkeit der Ergebnisse. 37

38 Die anschließende Verfeinerung der Ergebnisse aus der Work Breakdown Structure, ermöglicht ein Detaillevel, das für die Projektarbeit und das Projektmanagement verwendet werden kann. Projektplanung Projektplan (1/3) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Definition eines Projektplans Definition der Aufgabenpakete und Aufwandsschätzung Definition der Abhängigkeiten und zeitlichen Reihenfolge Abgleich mit dem Master Plan Dokumentation der Annahmen Anforderungen an ein Aufgabenpaket Aufgabe, an der wirklich gearbeitet wird (im Vergleich zu einem Deliverable) Klare Abgrenzung zu den anderen Aufgaben im gleichen Bereich Besitzt ein Start und ein End Datum Verfügt über ein Budget (Tage) Aufwandsschätzung erfolgt analog zu WBS Aufwand sollte kleiner als 10 Tage sein (abhängig von der Art der Tätigkeit) 38

39 Darauf basierend lässt sich jetzt die zeitliche Reihenfolge der Aufgabenpakete planen und eine Baseline für den geplanten Aufwand bilden. Projektplanung Projektplan (2/3) Projektplanu ng Projektabschlu ss Projektsteuerung und -kontrolle Aufgabe Ergebnis Start Datum End Datum Aufgabe 1 Ergebnis Aufgabe 2 Ergebnis Aufgabe 3 Ergebnis Aufgabe 4 Ergebnis Aufgabe 5 Ergebnis Total 1. Zeitliche Reihenfolge der Aufgabenpakete Aus der Definition der Aufgabenpakete und dem geschätzten Aufwand ergibt sich unter Berücksichtigung der Abhängigkeiten die zeitliche Verteilung der Aufgaben. Aufgabe Ergebnis 2. Definition der Baseline Die Baseline des Projektes definiert den zu erbringenden Leistungsumfang, die hierzu notwendigen Aufwände und die Verteilung dieser Aufwände im Zeitplan. Die Baseline ist die Ausgangsbasis für den Beginn der Projektarbeit. Budget Start Datum End Datum kum. Budget Aufgabe 1 Ergebnis Aufgabe 2 Ergebnis Aufgabe 3 Ergebnis Aufgabe 4 Ergebnis Aufgabe 5 Ergebnis Total Durch die Baseline müssen die folgenden Fragen beantwortet und festgelegt werden: Welche Aktivitäten müssen durchgeführt, welche Deliverables erreicht werden? Wie hoch ist der Aufwand? In welchem Zeitraum kann die Leistung erbracht werden? 39

40 Um den Projektplan fertig zu stellen müssen noch den Aufgabenpaketen einzelne Teams oder Teammitglieder zugewiesen werden. Projektplanung Projektplan (3/3) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss 3. Organisation des Projektteams und Zuweisung der Personen zu den Aufgabenpaketen Auswahl der benötigten Kenntnisse, Erfahrungen und Fähigkeiten sowie Selektion entsprechender Mitarbeiter Organisation des Projektteams Einführung und Training der Teammitglieder Management der Teams während des Projektverlaufs und Umverteilung der Teamstärken je nach Projektphase und Situation Anzahl Mitarbeiter Programmer Senior Programmer Teilprojektleiter Projektleiter Dauer 40

42 Während dieser Phase werden alle Projektergebnisse konzipiert, gebaut, getestet und implementiert. Der Projektleiter ist verantwortlich für die Lieferung der im Projektplan spezifizierten Projektergebnisse in Zeit, Budget & Qualität. Beschreibung der (1/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Allgemeines Phasemodell für das IT-Projektmanagement Projektergebnisse Aktivitäten Ausführung der Projektplanungen/ Arbeitspakete Meldung und Überwachung von Problemen bei der Umsetzung/ Steuerung bei Abweichungen Analyse und Freigabe von Anforderungen Kommunikation zwischen den Arbeitsgruppen Reporting des aktuellen Projektstatus in Richtung interne/ externe Stakeholder Projektplanung Projektsteuerung und -kontrolle Projektabschluss 42

43 Während dieser Phase werden alle Projektergebnisse konzipiert, gebaut, getestet und implementiert. Der Projektleiter ist verantwortlich für die Lieferung der im Projektplan spezifizierten Projektergebnisse in Zeit, Budget & Qualität. Beschreibung der (2/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Inputs (Voraussetzungen) / Outputs (Ergebnisse) Inputs: Projektplan Business Case Outputs: Projekt/-lieferergebnisse (z.b. Fachkonzept, DV-Konzept) Projektplan (aktualisiert) Testplan, Testprotokoll, Rollout Plan, Rollout Protokoll, Betriebsübergabeprotokoll, Schulungskonzept/-plan Typische Problemfelder/ Herausforderungen Häufige Änderungen des Projektumfangs Ressourcen stehen nicht ausreichend zur Verfügung Projektkosten übersteigen das vorab definierte Budget Werkzeuge (Tools) Projektplanungswerkzeuge (z.b. MS Project, Primavera, CA Clarity, etc.) Implementierungswerkzeuge (z.b. Rational, CA etc.) Template Fachkonzeption Template DV-Konzeption Template Testplan Template Rollouplan Template Betriebsübergabeprotokoll Template Schulungsplan Lessons Learned/ Erfolgsfaktoren Einführung eines klar geregelten Anforderungsmanagements (Change Management) Kontinuierliche Überwachung aller Projekttätigkeiten während der Durchführung 43

44 Basierend auf einem jeweils spezifisch gewählten Vorgehensmodell werden in der die Projektergebnisse konzipiert, erstellt, getestet, implementiert und abgenommen. - Implementierung Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Die wichtigsten Implementierungsphasen in einem IT-Projekt 1. Durchführung und Abnahme der fachlichen Konzeption (Fachkonzept) 2. Durchführung und Abnahme technischer Konzeption (DV-Konzept) Accenture V-Modell zur 3. Abnahme technischen Umsetzung (Realisierung) 4. Abnahme Funktions- und Integrationstest 5. Abnahme Rollout und Go- Live durch den Informatikund Fachbereich 6. Steuerung von Projektänderungen und Erweiterungen 7. Durchführung von Schulungen 44

46 Diese Phase stellt Verfahren für das Überwachen und Messen von Tätigkeiten, Leistungen und Ergebnissen bereit. Durch den Vergleich der Sollwerte mit den Istwerten kann der genaue Projektfortschritt ermittelt werden. Prüfungsrelevant Beschreibung der Projektsteuerung (1/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Allgemeines Phasemodell für das IT-Projektmanagement Projektstatus Aktivitäten Überwachung von Scope, Time, Budget, Qualität und Risiko Feststellung des Projektstatus Feststellung von Planabweichungen Durchführung von Korrektivmaßnahmen Update der Planung bezüglich Zeit, Kosten, Risiko und Qualität Treffen von Durchführungsentscheidungen Durchführung von Chance Management Maßnahmen Projektplanung Projektsteuerung und -kontrolle Projektabschluss 46

47 Diese Phase stellt Verfahren für das Überwachen und Messen von Tätigkeiten, Leistungen und Ergebnissen bereit. Durch den Vergleich der Sollwerte mit den Istwerten kann der genaue Projektfortschritt ermittelt werden. Prüfungsrelevant Beschreibung der Projektsteuerung (2/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Inputs (Voraussetzungen) / Outputs (Ergebnisse) Inputs: Projektplan, Aufwandsschätzung einschl. Anforderungsmatrix Investitions-/Kostenplan (Business Case) Risikoplan/-log Qualitätsplan/-log, Outputs: Projektstatusbericht Aktualisierter Business Case Typische Problemfelder/ Herausforderungen Zeitnahe Auswertungen und Erfassung des Projektstatus Saubere Zuordnung der Tätigkeiten auf Buchungsnummern Umfang und Inhalte des Projektstatusberichts nicht mit den Auftraggebern ausreichend abgestimmt Werkzeuge (Tools) Projektsteuerungswerkzeuge (z.b. MS Project, Primavera, CA Clarity, SAP, etc.) Template Projektstatusbericht Template Meilensteintrendanalyse Template Investitions-/Kostenplan Template Anforderungsmatrix Template Business Case Lessons Learned/ Erfolgsfaktoren Weitestgehende Automatisierung des Prozesse Projektstruktur (Aufgabenpakete) und Budgetstruktur (Buchungsnummern) sollten sich entsprechen Aufgabenpakete sollten klar auf Teilprojekte verteilt sein, damit keine "unter den Tisch fallen Verwendung der einer Earned Value Analyse für Großprojekte Reporting muss mit Empfängern abgestimmt werden 47

48 Das Projektreporting in einem Projekt dient dazu den aktuellen Projektstatus, notwendige Entscheidungen und die nächsten Projektschritte zu kommunizieren. Prüfungsrelevant Projektcontrolling Projektreporting (1/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Beschreibung Risikomanagement Definition Collect and distribute project/program performance information to project/program stakeholders to determine the operational performance of a project/program when compared to baseline data Ziele Provide reporting that is accurate, timely, compliant, and contains the appropriate level of detail suited for the designated audience Supply the information necessary to direct, manage, monitor, and control the execution of the project/program Make available incremental and overall status information indicating how the project/program is operating Provide an early warning of potential project/program execution issues Inhalte The scope of Performance Reporting includes the data inputs, tools, and techniques used in the reporting process for information gathering, compilation, and presentation Prozess Includes status reports, program-level reports; issues, risks, schedule, milestones, deliverables, and quality requirements Gather Data Analyze Data Publish Report Evaluate Results Implement Corrective Actions Request Project Data Check Data for Validity and Completeness Examine Project Data Against Baseline Identify Areas of Concern Prepare Report Distribute to Audiences Review Report Recognize Areas of Concern Determine Solutions Execute Corrective Actions 48

49 Der Status Report in einem Projekt dient dazu den aktuellen Projektstatus, notwendige Entscheidungen und die nächsten Projektschritte zu kommunizieren. Prüfungsrelevant Projektcontrolling Projektreporting (2/2) Projektplanu ng Projektabschlu ss Projektsteuerung und -kontrolle Level des Statusreportings Der Detaillierungsgrad eines Status Reports variiert zwischen den Leveln eines Projektteams. Status Teamleiter Status Teilprojektleiter Projektmanager Status Inhalte Statusreporting Auszug für typische Inhalte eines Projektreports: Inhalt Projekt / Projektleiter Beschreibung Verantwortlicher Projektleiter Berichtsdatum Datum des Statusberichts (z.b. KW11) Projektfortschritt Allgemeine Kommentierung des Projektstandes. Wie stehen wir terminlich und mit dem Verbrauch der Ressourcen. Wie weit ist das Projekt fortgeschritten und warum wurde die entsprechende Ampelschaltung gewählt. Problemfelder Was sieht das Projektteam als Ursache von Abweichungen bzw. als mögliches Gefahrenpotential in der Zukunft. Maßnahmen / Termin Entscheidungsbedarf Welche Maßnahmen sind aus Sicht des Projektteams bis wann einzuleiten. Welche Entscheidungen müssen von wem getroffen werden. (Lenkungsausschuss, Steuergremium) Auswirkung Verbale Beschreibung dieser Auswirkungen auf Laufzeit, Kosten und/oder Nutzen Terminverfolgung Bestätigung oder Korrektur des geplanten Endtermins Soll/Ist Budget Aktualisierung des verbrauchten Budgets 49

50 Alle für eine erfolgreiche Projektsteuerung erforderlichen Kennziffern lassen sich aus den tatsächlichen Aufwänden und den Schätzungen der Restaufwände ableiten. Prüfungsrelevant Projektcontrolling Fortschrittskontrolle (1/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Vorgehen zur Fortschrittskontrolle ( Earned Value Analyse ) Erfassen des Verbrauchs pro Aufgabenpaket (ACWP) Schätzung des Restaufwandes (ETC) Berechnung des Restaufwandes Gesamtprojekt (EAC) Berechung der erreichten Wertschöpfung (BCWP) Darstellung der Fortschrittskontrolle Aufwand Verbrauch Baseline EAC Wertschöpfung Voraussetzung: Die periodengerechte korrekte Erfassung der Aufwände, korrekte Schätzung der Restaufwände ist von zentraler Bedeutung für den Erfolg des Projektmanagements. Berechnung: Gesamtaufwand (BCAC) Baseline (BCWS) Wertschöpfung (BCWP) Verbrauch (ACWP) Restaufwand (ETC) Restaufwand Gesamtprojekt (EAC) Zeit 50

51 Die folgenden Kennzahlen werden verwendet, um den aktuellen Status eines Projektes darzustellen und dienen als Basis für die Bewertung und Analyse. Prüfungsrelevant Projektcontrolling Fortschrittskontrolle (2/2) Projektplanu ng Projektabschlu ss Projektsteuerung und -kontrolle Kennzahlen (KPI) zur Darstellung der Kosten / Zeitsituation Kennzahl Englischer Begriff Abkürzung Erklärung Gesamtaufwand Budgeted Cost at Completion Baseline Budgeted Cost of Work Scheduled Wertschöpfung Budgeted Cost of Work Performed Verbrauch Actual Cost of Work Performed BCAC BCWS BCWP ACWP Dieser Indikator beziffert das geplante Projektbudget bei Fertigstellung Dieser Indikator beziffert das Budget von Tasks, die laut Planung zu einem gegebenen Zeitpunkt fertiggestellt sein sollten und ergibt sich aus der Summe der BCACs der jeweiligen Tasks. Dieser Indikator beziffert das Budget fertiggestellter Tasks (Soll), die zu einem bestimmten Zeitpunkt fertig gestellt wurden und ergibt sich aus der Summe der BCACs der jeweiligen Tasks. Dieser Wert wird auch Earned Budget genannt. Dieser Indikator beziffert den aktuell angefallenen Aufwand fertiggestellter Tasks (Ist), die zu einem bestimmten Zeitpunkt fertiggestellt wurden und ergibt sich aus der Summe der tatsächlich angefallenen Einzelaufwandspositionen für die jeweiligen Tasks. Dieser Wert wird auch Burned Budget genannt. Restaufwand Estimate to Complete ETC Schätzung der Teams, wie viel Aufwand benötigt wird um das Aufgabenpaket vollständig abzuschließen Restaufwand Gesamtprojekt Estimate at Completion EAC Abschätzung über den Gesamtaufwand der benötigt wurde um ein Aufgabenpaket abzuschließen. EAC = ACWP + ETC 51

52 Projekte lassen sich auf Basis des wertschöpfungs-orientierten ( earned value ) Projektmanagement-Ansatzes steuern. Prüfungsrelevant Analyse des Projektverlaufs Earned Value (1/6) Projektplanu ng Projektabschlu ss Projektsteuerung und -kontrolle Erfolgreiches Projekt Obwohl weniger verbraucht wurde als geplant (Verbrauch < Wert) sind sogar mehr Leistungen erbracht worden (Wert > Baseline) Problematisches Projekt: Obwohl mehr verbraucht wurde als geplant (Verbrauch > Baseline) sind nicht alle Leistungen erbracht worden (Wert < Baseline) Aufwand Aufwand Geschaffene Wertschöpfung 3 Verbrauch Geschaffene Wertschöpfung Verbrauch Zeit Zeit Abweichung bei: 1 Zeit: Schedule Variance 2 Produktivität: Cost Variance 3 Zeitabweichung: Time Variance 52

53 Kennzahlen zur Darstellung des aktuellen Status Prüfungsrelevant Analyse des Projektverlaufs Earned Value (2/6) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Cost Variance (CV) - Darstellung Cost Variance (CV) - Eigenschaften Berechnung: Aufwand CV = Wertschöpfung Verbrauch = BCWP ACWP Beschreibung: Beziffert die Abweichung des aktuellen verbrauchten Aufwands vom budgetierten / geplanten Aufwand. Verbrauch CV Wertschöpfung Analyse: CV > 0 Das Projekt verbraucht weniger Budget als geplant (Gutfall) CV < 0 Das Projekt verbraucht mehr Budget als geplant (Schlechtfall)

54 Kennzahlen zur Darstellung des aktuellen Status Prüfungsrelevant Analyse des Projektverlaufs Earned Value (3/6) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Cost Performance Indicator (CPI) - Darstellung Cost Performance Indicator (CPI) - Eigenschaften Berechnung: 2 CPI Wertschöpfung CPI = Verbrauch = BCWP ACWP 1,47 1,34 Beschreibung: Der CPI hilft dem Projektmanager bei der Analyse des Budgetverbrauchs und stellt die Produktivität des Teams dar. 1 0,71 0,96 Analyse: CPI > 1 Es wird weniger Budget verbraucht als geplant war. CPI < 1 Es wird mehr Budget verbraucht als geplant war Zeit 54

55 Kennzahlen zur Darstellung des aktuellen Status Prüfungsrelevant Analyse des Projektverlaufs Earned Value (4/6) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Schedule Variance (SV) - Darstellung Schedule Variance (SV) - Eigenschaften Berechnung: Aufwand SV SV = Wertschöpfung - Baseline = BCWP BCWS Beschreibung: Beziffert die Abweichung des Budgets, dass laut Planung zu einem bestimmten Zeitpunkt verdient sein soll (planned earned) von dem tatsächlich verdienten Budget (earned). Verbrauch Wertschöpfung Baseline Analyse: SV > 0 Das Projekt liegt vor dem Zeitplan. SV < 0 Das Projekt liegt hinter dem Zeitplan

56 Kennzahlen zur Darstellung des aktuellen Status Prüfungsrelevant Analyse des Projektverlaufs Earned Value (5/6) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Schedule Performance Indicator (SPI) - Darstellung Schedule Performance Indicator (SPI) - Eigenschaften Berechnung: 2 1 SPI 0,96 1,24 0,86 SPI = Wertschöpfung Baseline BCWS Beschreibung: Das Verhältnis der beiden Werte lässt einen Rückschluss auf die zukünftige Entwicklung des Projektes zu. Analyse: SPI > 1 Das Projekt liegt vor dem Zeitplan. SPI < 1 Das Projekt liegt hinter dem Zeitplan. = BCWP 0, Zeit 56

57 Auswirkung Risikomanagement ist ein iterativer Prozess der fortlaufend während der Planung, Durchführung und Steuerung von Projekten angewendet wird, um ungeplante Auswirkungen auf das Projekt, frühzeitig sichtbar zu machen. Prüfungsrelevant Projektcontrolling Risikomanagement Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Analyse von Projektrisiken Erfassung und Dokumentation Analyse und Bewertung Reduzierung, Verfolgung & Reporting Zeitliche Risiken Risiken, die eine Gefährdung des zeitlich spezifizierten Nutzens oder der Projektlaufzeit darstellen (Beispiele: Change Requests, Nichtverfügbarkeit von Ressourcen oder Zeitüberschreitungen durch die Reduzierung anderer Risiken entstehen) Berechnung Risikofaktor = Auswirkung x Wahrscheinlichkeit Eintrittswahrscheinlichkeit Finanzielle Risiken Risiken, die eine Gefährdung des finanziell spezifizierten Nutzens oder des Projektbudgets darstellen (Beispiele: Kosten für ein geändertes Design, zusätzliche Anwendungsprogramme oder operationale Probleme bei der Realisierung, etc.) 4 75%-100% Nahe zu sicher 3 50%-75% Hohe Wahrscheinlichkeit 2 25%-50% Mittlere Wahrscheinlichkeit 1 0%-25% Geringe Wahrscineinlichkeit Risikomatrix sehr kritisch 4 kritisch 3 Eintrittswahrscheinlichkeit nahezu hoch mittel sicher gering Qualitätsrisiken Risiken, die eine Gefährdung des qualitative spezifizierten Nutzen/ Produkt darstellen. (Beispiele: Fachkonzept nicht abgenommen oder geprüft, Verwendung eines instabilen, nicht erprobten Technologie, Erweiterung des Projektumfangs etc.) Auswirkung 4 Sehr kritisch 3 Kritisch 2 Moderate 1 Unkritisch moderat 2 unkritisch

59 Die Hauptaufgabe der Abschlussphase ist die Einführung und Verwendung der Projektergebnisse. Dazu muss festgestellt werden, inwieweit die Ziele erreicht wurden und welche Abweichungen bei z.b. Kosten, Terminen aufgetreten sind. Beschreibung des Projektabschlusses (1/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Allgemeines Phasemodell für das IT-Projektmanagement Projektabschluss -bericht Aktivitäten Zusammenstellung und Präsentation der Projektergebnisse Abnahme der Projektergebnisse Sicherung von Wissen und Erfahrungen (Lessons Learned) Dokumentation und Ablage der Projektergebnisse Aufsetzen und Überwachen der Nutzenrealisierung Auflösung des Projektes und Entlastung der Projektressourcen Projektplanung Projektsteuerung und -kontrolle Projektabschluss 59

60 Die Hauptaufgabe der Abschlussphase ist die Einführung und Verwendung der Projektergebnisse. Dazu muss festgestellt werden, inwieweit die Ziele erreicht wurden und welche Abweichungen bei z.b. Kosten, Terminen aufgetreten sind. Beschreibung des Projektabschlusses (2/2) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Inputs (Voraussetzungen) / Outputs (Ergebnisse) Inputs: Projektergebnisse Abnahmeprotokolle Outputs: Projektabschlussbericht Lessons Learned Nutzenrealiserung Typische Problemfelder/ Herausforderungen Neutrale und objektive Kommunikation der Projektergebnisse Vermeidung von "Überraschungseffekten Nachverfolgung des geplanten Nutzen (Nutzenrealisierung) Formaler Abschluss des Projektes und reibungslose Übergabe in den Betrieb verursachen oft zusätzlichen Aufwand der nicht ausreichend budgetiert wurde Wissen aus der Projektarbeit wird nicht ermittelt sowie abgespeichert für eine zukünftige Nutzung Werkzeuge (Tools) Vorlage Projektabschlussbereicht Vorlage Lessons Learned Vorlage zur Nutzenrealisierung Business Case Lessons Learned/ Erfolgsfaktoren Durchführung eines Lessons Learned Worktshops Bereitstellung eines formalen Projektabschlussbereicht Zeitplan für Übergabe vereinbaren Zeitnahe Kommunikation des Arbeitsstandes Definition Wording/ Glossar Vereinbarung des zu liefernden Arbeitspakets/Ergebnisse 60

62 Offsite / Offshore On Site Um Lohndifferenzen zu Nutzen, werden große IT Projekte mittlerweile mit einem signifikanten Off-Shore Anteil geliefert Typischer On-Shore / Off-Shore Split im V-Modell 5% Fachliches Grobkonzept V-Modell Abnahmetest 5% Arbeitsanteil Offshore 0 % Anteil Phase am Gesamtaufwand 10 % 20% Fachliches Feinkonzept System- & Integrationstest 20% 0 % 40 % 10% DV-Technische Feinkonzept Modulgruppen- & technischer Systemtest 10% 100 % 20 % 5% Modul Design Modultest 5% 100 % 10 % 20% Programmierung 100 % 20 % Gesamtanteil Offshore: 50 % 62

63 Die physische Entfernung der Projektteilnehmer beim Off-shoring erfordert formalisierte Übergabepunkte Onsite Project Team Delivery Centre (Off-shore) Onsite Project Team Development Strategy Entry/Exit Criteria Development, Component, Assist with Assembly Test Entry/Exit Criteria Sign Off Functional Designs Technical Design Specs Checkpoint Test Plan Design Review Ongoing Quality Assurance Defect Fixes Acceptance Test Defects

64 Die Status/ Q-Gate Architektur definiert verschiedene Kontroll- und Informationspunkte an denen der weitere Projektverlauf bewertet, genehmigt und kommuniziert wird. Besonderheiten von IT-Großprojekten Quality Gates (1/3) Beispiel einer Quality Gate Architektur Feinplanung & Umsetzung Integration Rollout Projektplanung Projektabschluss Projektcontrolling 64

65 Der Status eines Q-Gates wird durch die Bedingungen/ Ergebnisse der beendeten Projektphase und den Anforderungen/ Zielen der nächsten Projektphase bestimmt. Besonderheiten von IT-Großprojekten Quality Gates (2/3) Beispiel eines Quality Gate Management Prozesses Quality Gate Status Beendete Projektphase Nächste Projektphase Bedingungen, Ergebnisse Quality Gate Meeting Anforderungen, Ziele Entscheidung Go (mit oder ohne Bedingungen) No Go 65

66 Während der Qualitätsprüfung müssen mehrere Teilaspekte des Projekts bewertet werden Besonderheiten von IT-Großprojekten Quality Gates (3/3) Beispiel einer Quality Gate Prüfung und Auswertung Scope Steuerung von Auftrag und Strategie Beschreibung und Konformität mit dem I-Auftrag Ausrichtung und Konformität mit der I-Strategie Scope Time Qualität der Planung und Termine Qualität der Terminplanung/-beschreibung Zeitliche Konformität bezüglich Termine und Meilensteine Financials Resources QG Time Process Financials Steuerung von Budget und Risiko Finanzielle Konformität und Kontrolle bezüglich Budgetplanung Auswirkung, Steuerung und Kontrolle von Risiken Resources Qualität der Ressourcen Ressourcenmanagement in bezug auf Planung und Forecast Ressourcenqualität in bezug auf geforderte Skillprofile Product Process Qualität des Prozesses Benutzung von standardisierten und/oder geplanten Prozessen Einhaltung von Prozessdokumentationen/-beschreibungen Product Qualität des Produktes Sicherung der Produktreife über den Produktentwicklungszyklus Freigabe von geprüften und abgenommen Produkten 66

67 Die Definition einer Projekt Governance ist die Voraussetzung um das Projekt erfolgreich vom Projektstart bis zum Projektziel zu führen Besonderheiten von IT-Großprojekten Projekt Governance Definition und Beispiel einer Projekt Governance Die Definition einer Projekt Governance erfolgt durch eine klare Aufgaben- und Verantwortungsverteilung mit Hilfe von hierarchischen Strukturen, die allen Projektbeteiligten ein Höchstmaß an Transparenz vermitteln. Projekt Governance sichert damit den Projekterfolg und orientiert sich dabei an vier wesentlichen Faktoren: BEISPIEL 1. Accountability: Rechenschaftspflicht, z.b. hinsichtlich quantifizierbarer Ziele 2. Responsibility: Verantwortlichkeit, wenn es um die Lösung einer Aufgabe geht 3. Transparency: Offenheit und Transparenz bei allen Abläufen und Strukturen 4. Fairness: zwischen allen Projektbeteiligten, untereinander und auf allen Ebenen 67

68 Backup 68

69 Kennzahlen zur Darstellung des aktuellen Status Analyse des Projektverlaufs Earned Value (6/6) Projektplanu ng Projektsteuerung und -kontrolle Projektabschlu ss Statistical Estimate to Complete (Stat ETC) Berechnung: Berechnung: To-Complete Productivity Index (TCPI) Stat. ETC = (BCAC BCWP) CPI TCPI = (BCAC BCWP) (EAC ACWP) Beschreibung: Dieser Wert gibt einen Hinweis auf das Budget, welches noch benötigt wird um das Projekt zu beenden. Diese Zahl stellt einen Vergleichswert zur subjektiven ETC Schätzung dar, die von den Mitarbeitern erstellt wird (Proj. ETC). Analyse: Stat. ETC > Proj. ETC Die Schätzung des Teams ist zu optimistisch. Stat. ETC < Proj. ETC Die Schätzung des Team ist zu vorsichtig. Beschreibung: Dieser Quotient beschreibt die Produktivität, die notwendig ist, damit der Proj. EAC erreicht werden kann. Analyse: TCPI = CPI Der ETC entspricht der verbleibenden Arbeit. TCPI!= CPI Der geschätzte ETC entspricht nicht den Erfahrungen aus dem bisherigen Projektverlauf. 69

70 Projektergebnisse/-lieferungen für Großprojekte Besonderheiten von IT-Großprojekten Projektergebnisse Wichtige Projektergebnisse in IT-Großprojekten Projektplanung Projektabschluss 1.1 I-Projektantrag 1.2 Grobe Aufwandsschätzung 2.1 Projektplan (Entwurf) 2.2 LA 3 Präsentation 3.1 Projektplan (Aktuell) 3.2 DV-Konzept 3.3 Testplan/- protokoll 4.1 Abschlussbericht 4.2 Lessons Learned 1.3 I-Angebot/ EV I-Projekt (LSS/Augeo) 2.3 Ressourcenplan 2.4 Investitions-/ Kostenplan 3.4 Rolloutplan/- protokoll 3.5 Übergabe/- Abnahmeprotokoll 3.6 Benutzer dokumentation 1.5 GPA Change Request Antrag 2.5 Kick-off Präsentation 2.6 Fachkonzept/- checkliste 3.7 Betriebs-dokumentation 3.8 Schulungskonzept/-plan 3.9 Anforderungsmatrix 2.7 Make or Buy Checkliste 2.8 SKM 4 -Plan 5. Projektsteuerung und -kontrolle 5.1 Projektkennzahlenbericht 5.2 Projektstatusbericht 5.3 Soll-Ist Bericht 5.4 Meilensteintrendbericht 5.5 Risikobericht 5.6 Offene Punkte Bericht 5.7 Qualitätsbericht 70

71 Vor der Projektauflösung und der Entlassung der Projektressourcen sollte jedes Projekt einen Abschlussbericht dokumentieren. Dieser sollte in komprimierter Form die Ergebnisse und einen Projektrückblick enthalten. Projektabschlussbericht Projektplanu ng Projektabschlu ss Projektsteuerung und -kontrolle Projektabschlussbericht Der Abschlussbericht fasst alle gewonnen Erkenntnisse des Projekts zusammen insbes. die Projektergebnisse, Offenen, Punkte, Erfahrungen und Lessons Learned Darüber hinaus dokumentiert der Abschlussbericht die Abnahme der Projektergebnisse bzw. Entlastung der Projektleitung. Welche typische Inhalte hat ein Abschlussbericht? Inhalt Beschreibung Kurze Zusammenfassung des ausführlichen Abschlussberichtes. Ergebnisse Welche Ziele wurden erreicht und wie war die Entwicklung der Kennzahlen. Verlief das Projekt wie erwartet? Offen geblieben Lessons learned Wichtige Erkenntnisse aus dem Projektablauf, die zukünftige Projekte beeinflussen sollten. Welche Ziele wurden nicht erreicht und warum? Welche Lehren sind aus dem Projektablauf und den erzielten Ergebnissen für weitere Projekte zu ziehen? Was lief gut und was muss bei zukünftigen Projekten anders laufen? Zusammenfassung Erfahrungsbericht Soll-Ist- Abgleich Projektabnahme Was wurde geplant und wie war der tatsächliche Verbrauch? Durch Unterschriften der Key Stakeholder wird die offizielle Abnahme des Projektes bestätigt.. Ausblick Offene Punkte, die noch eingearbeitet werden müssen und/oder eventuell notwendige oder gewünschte Nachfolgeprojekte. 71