Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version 3.0 - 07/2004Modul: Projektsteuerung Modul Projektsteuerung (-controlling) Literatur:

Ähnliche Präsentationen


Präsentation zum Thema: "Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version 3.0 - 07/2004Modul: Projektsteuerung Modul Projektsteuerung (-controlling) Literatur:"—  Präsentation transkript:

1 Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Modul Projektsteuerung (-controlling) Literatur: Informationen finden sich in allen Büchern über Projektmanagement, hier wurden insbesondere die folgenden Quellen benutzt: Walter Gruber, Arbeitsbuch Projektmanagement, WEKA 2003) Gerda Süß, Die wichtigsten Methoden im Projektmanagement, WEKA 2002 Walder, Franz-Peter, Patzak, Gerold, Qualitätsmanagement und Projektmanagement, Vieweg 1997 Dr. G. Angermeier, Meilenstein-Trendanalyse (MTA): Hausmittel gegen Terminrisiken, Projektmagazin 18/2003 Dr. G. Angermeier, Plan und Realität effizient vergleichen: Projektcontrolling mit Earned Value Management, Projektmagazin 24/2003 Thomas Walenta, Messbarer Projekterfolg mit der Earned Value Analyse, Projektmagazin 04/2001 Dr. M. Kärner, Projektcontrolling I, II, III, Projektmagazin 06/2004, 10/2004, 15/2004 Tilo Linz, Reviews – der erste Schritt zur projektbegleitenden Qualitätssicherung, Projektmagazin 19/2000

2 Copyright: Dr. Klaus Röber 2 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Was ist Projektsteuerung (-controlling) und wozu dient sie? Unter Projektsteuerung (Projektcontrolling) versteht man alle Maßnahmen, die dazu dienen, den tatsächlichen Projektverlauf mit der ursprünglichen bzw. der überarbeiteten Planung in Einklang zu bringen. Der Projektleiter muss agieren und nicht reagieren. Er ist gefordert, das Projekt aktiv zu beeinflussen und damit zu steuern. Je mehr Zeit der Projektleiter bei der Projektsteuerung darauf verwendet, notwendige Maßnahmen zu treffen und gemeinsam mit seinem Projektteam umzusetzen, desto höher ist die Qualität der einzelnen Steuerungsmaßnahmen und desto mehr Möglichkeiten gibt es, auf Abweichungen zu reagieren. Ziel des Projektcontrollings ist es deshalb, ein Frühwarnsystem aufzubauen, das dem Projektleiter möglichst bald und möglichst deutlich aufzeigt, wann eine Reaktion auf Planabweichungen notwendig ist.

3 Copyright: Dr. Klaus Röber 3 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Kernprozesse der Projektsteuerung Überwachen des Projektfortschritts Die Basis für jedes Projektcontrolling sind Informationen darüber, wie die Abarbeitung der einzelnen Arbeitspakete läuft. Dazu müssen die Ist-Daten erfasst und analysiert werden. Im zweiten Schritt sind die erhobenen Ist-Daten in Bezug zur Planung zu setzen. Wichtig ist, die Auswirkungen der derzeitigen Situation auf den weiteren Projektverlauf festzustellen. Definition von Steuerungsmaßnahmen bei Planabweichungen Ist bei der Auswertung der Ist-Daten klar geworden, dass die Erreichung des Projektziels gefährdet ist, müssen entsprechende Gegenmaßnahmen getroffen werden, um das Projekt wieder in den Plan zu bringen bzw. den Plan anzupassen. BerichtswesenEin funktionierendes Berichtswesen ist die Grundlage für die Ist-Datenerfassung sowie für die adäquate Information aller Betroffenen (s. Modul Projektberichtswesen). Integriertes Änderungsmanagement Aufgabe des integrierten Änderungsmanagements ist die Steuerung der Änderungen, die im Projektverlauf auftreten.

4 Copyright: Dr. Klaus Röber 4 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Unterstützungsprozesse der Projektsteuerung QualitätslenkungAls unterstützender Prozess wird die Qualitätslenkung während der gesamten Projektsteuerung durchgeführt. Qualitätslenkung ist die Überwachung der Projektergebnisse, um festzustellen, ob die postulierten Standards eingehalten werden, und um herauszufinden, wie die Ursachen unzureichender Ergebnisse beseitigt werden können. RisikoverfolgungDie Risikoverfolgung ist die Voraussetzung, um im Laufe des Projekts auf Risikoereignisse reagieren zu können. Die in der Risikoanalyse erfassten Risiken müssen beim Eintritt erkannt werden, damit ihnen mit den erarbeiteten Maßnahmen schnell entgegen getreten werden kann. Daneben werden im Rahmen der Risikoverfolgung zuvor nicht erkannte Risikoquellen aufgedeckt.

5 Copyright: Dr. Klaus Röber 5 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Rahmenbedingungen der Projektsteuerung Arbeitspakete werden durch den Projektleiter entsprechend der Planung freigegeben. Alle Projekt-Mitarbeiter (IS, Fachbereich und Externe) dokumentieren ihre Projektleistungen mit Aufwand und Datum (wöchentliche Projektzeitberichte). Der Projektfortschritt wird durch den Projektleiter überwacht. Dazu gehören –die laufenden Arbeitspakete innerhalb des Projektes –die externen Leistungen Offene Punkte werden vom Projektleiter in einer Offene-Punkte-Liste dokumentiert und deren Klärung verfolgt und koordiniert. Die Projektleistungen der einzelnen Mitarbeiter werden vom Projektleiter monatlich zusammengefaßt ( Aufwand, Termine, Verfügbarkeit ), die Abweichungen festgestellt und eingeschätzt, sowie Maßnahmen zur Korrektur initialisiert. Wesentliches Element der Projektsteuerung ist die Herstellung der Akzeptanz der Projekt-Zwischenergebnisse durch die Projektgremien. Dies ist durch den Projektleiter zu planen und zu organisieren und findet im Rahmen eines Abnahme- Reviews statt. Ergebnis ist ein Abnahmeprotokoll. Change Requests im Projektverlauf werden dokumentiert und im Lenkungsausschuss behandelt (genehmigt oder abgelehnt).

6 Copyright: Dr. Klaus Röber 6 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Offene Punkte-Liste: Beispiel

7 Copyright: Dr. Klaus Röber 7 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Projektsteuerung – Regelkreis (1) Quelle: F.P. Walder-G. Patzak, Qualitätsmanagement und Projektmanagement, Vieweg 1997

8 Copyright: Dr. Klaus Röber 8 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Projektsteuerung – Regelkreis (2) Folgende Schritte werden dem Regelkreis zufolge sinnvoll methodisch unterstützt: Vorgaben Projektauftrag, Projektabgrenzung, Projektumfeld (Methoden der Definition und Abgrenzung) Planen Planung von Leistung, Qualität, Terminen, Ressourcen, Kosten (Methoden der Planung) Entscheiden Auswahl von Handlungsalternativen und von Korrekturmaßnahmen, folgend aus der Soll/Ist-Abweichung Einwirken Intervention zur Zielerreichung Grundsätzlich gibt es folgende Möglichkeiten für korrektive Maßnahmen: - Heranführen des Ist an das Soll/Plan: Regelung/Steuerung - Anpassung des Soll/Plan an das Ist: Planänderungen Ist-Ermittlung Daten in quantitativer und qualitativer Hinsicht; Zielkriterien sind: inhaltliche und formale Richtigkeit, Zuverlässigkeit, Nachvollziehbarkeit Soll/Ist Vergleich Basis für Abweichungs-, Ursachen- und Konsequenzenanalysen Abweichungen Analyse nach Ausmaß, Ursache und Konsequenz analysieren Projektinforma- Information der Projektaustraggeber über den Projektstatus (aktives tionsberichte Projektmarketing)

9 Copyright: Dr. Klaus Röber 9 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Gegenstände der Projektsteuerung Gegenstände der Projektsteuerung sind: –Aufgaben, Leistungen (Mengen) –Qualität –Termine –Ressourcen/Kosten Termine und Ressourceneinsatz/Kosten sind nur mit Bezug auf die Aufgabenerfüllung (Mengen und Qualität) sinnvoll zu behandeln. Die integrierte Betrachtung von Leistung, Zeit und Kosten ermöglicht es im Fall von Abweichungen, in einer der genannten Dimensionen die Auswirkungen auf die jeweils anderen Größen darzustellen und frühzeitig optimale Steuerungsmaßnahmen zu setzen.

10 Copyright: Dr. Klaus Röber 10 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Überwachen des Projektfortschritts In dieser Aktivität wird der Fortschritt der Arbeiten ( Arbeitspakete ) im Projektteam überwacht. Das Überwachen der Arbeitspakete beinhaltet die Prüfung, inwieweit der Fortschritt vom Plan abweicht und die Arbeit effektiv durchgeführt wird. Die Überwachung ermöglicht eine frühzeitige Erkennung von Problemen und damit ein frühzeitiges Einleiten von korrigierenden Maßnahmen, bevor die Probleme ernsthafte Auswirkungen haben. Die Überwachung muss sich auf die erreichten Ergebnisse fokussieren (siehe definierte Ergebnisse im Projektauftrag), nicht darauf, wie fleißig das Projektteam arbeitet. Die Überwachung ist die Schlüssel-Aktivität zwischen der Planung und dem Berichten des Projektstatus! Darüberhinaus werden u.a. auch die Zahlungen an externe Lieferanten und Dienstleister überprüft und angewiesen.

11 Copyright: Dr. Klaus Röber 11 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Zwei Aspekte bei der Ist-Datenerfassung Vergangenheitsbezogene Ist-Daten –Dies sind die klassischen Ist-Daten, die in vielen Betrieben schon aus betriebswirtschaftlichen Gründen erfasst werden. Aus ihnen lassen sich interessante Schlüsse ziehen, z. B. hinsichtlich der Aufteilung des gesamten Abteilungsaufwands auf Neuentwicklungen, Fehlerbehebung, Produktbetreuung, Administration usw. Außerdem dient die Ist-Datenerfassung der Leistungsabrechnung mit externen Projektmitarbeitern. Beispiele sind: Ist-Anfangs- und Endtermin eines Vorgangs Bereits angefallene Kosten (Ist-Kosten) Bereits geleistete Aufwände (Ist-Aufwand) Zukunftsbezogene Ist-Daten –Diese zukunftsbezogenen Informationen sind keine Ist-Daten im betriebswirtschaftlichen Sinne – vielmehr sind es aktualisierte Schätzungen. Diese Angaben (z. B. über einen voraussichtlichen Fertigstellungstermin) sind die Basis, um ein Frühwarnsystem aufzubauen – das Hauptziel der Projektsteuerung! Beispiele sind: Voraussichtlicher Fertigstellungstermin eines Arbeitspakets Voraussichtlicher Restaufwand Voraussichtlich noch anfallende Kosten.

12 Copyright: Dr. Klaus Röber 12 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Leistungskontrolle Der erste und wichtigste Schritt im Plan-Ist Vergleich ist die Feststellung, welche Leistung bisher erbracht wurde. Damit kann nicht nur ermittelt werden, ob der Leistungsfortschritt im Plan liegt, sie ist zudem die Grundlage für jede wirklich aussagekräftige Termin- und Kostenkontrolle. Die Feststellung der bisher im Projekt erbrachten Leistung erfolgt mit Hilfe des Fertigstellungsgrads. Dieser bezeichnet das Verhältnis der zu einem Stichtag erbrachten Leistung zur Gesamtleistung eines Vorgangs, Arbeitspakets oder Projekts (DIN 69903) Der Fertigstellungsgrad bezeichnet also den Prozentsatz, zu dem das Projekt oder Teile davon fertig gestellt sind, d. h. welcher Anteil am gesamten Arbeitsvolumen bereits erledigt ist. Die Feststellung des Fertigstellungsgrads ist nicht unproblematisch, denn auf die direkte Frage danach beim Arbeitspaketverantwortlichen erhält man häufig die Antwort: Ich bin zu 90% fertig. Spätestens wenn bei der dritten Abfrage der Fertigstellungsgrad immer noch scheinbar bei 90% stagniert, dämmert es dem Projektleiter, dass er dem berüchtigtem 90%-Syndrom aufgesessen ist.

13 Copyright: Dr. Klaus Röber 13 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Das 90% Syndrom Woher kommt es, dass ein Arbeitspaketverantwortlicher die Antwort zu 90% fertig gibt? Schließlich wird kaum jemand den Projektleiter bewusst belügen wollen! Gründe dafür sind: –Der Aufwand für noch zu erledigende Arbeiten wird weit unterschätzt. –Die bisher erbrachte Leistung wird überschätzt. –Zukünftige Probleme werden nicht erkannt. –Noch nicht eingetretene aber bereits absehbare Probleme werden unterschätzt. –Der Fertigstellungsgrad wird nur grob überschlagen (die Frage im Vorbeigehen lässt auch kaum eine sorgfältige Berechnung zu) – mit zu 90% fertig will der Arbeitspaketverantwortliche ausdrücken, dass er schon weit fortgeschritten ist, aber noch ein gewisser Teil zu erledigen bleibt. Die direkte Frage ist deshalb meist nicht die Lösung des Problems, weshalb der Fertigstellungsgrad mit Hilfe anderer Methoden berechnet werden muss.

14 Copyright: Dr. Klaus Röber 14 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Ermittlung des Fertigstellungsgrads Um den Fertigstellungsgrad feststellen zu können, werden benötigt: –Die bis zum Stichtag erbrachte Leistung (Aufwand) –Die Gesamtleistung (gesamter Aufwand) Die bis zum Stichtag erbrachte Leistung (Ist-Leistung) kann relativ einfach über Stundenaufschreibungen der Mitarbeiter ermittelt werden. Problematischer ist die Ermittlung der erforderlichen Gesamtleistung. Einfach die ursprünglichen Planwerte zugrunde zu legen, verbietet sich. Es soll ja gerade kontrolliert werden, ob der Leistungsfortschritt im Plan ist. Ist das Projekt leistungsmäßig im Verzug, könnten bei der Verwendung der Plandaten rechnerische Fertigstellungsgrade von weit über 100% resultieren, die real dennoch weit unter 100% liegen. Deshalb muss an jedem Stichtag jeweils eine neue Schätzung des noch verbleibenden Aufwands (Restaufwand) durchgeführt werden. Die Gesamtleistung ergibt sich dann aus der Addition von Ist-Aufwand und Restaufwand. Methoden zur Ermittlung des Fertigstellungsgrads sind: –0/100 Methode –50/50 Methode –Step-to-Step Methode –Relative Methode

15 Copyright: Dr. Klaus Röber 15 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Die 0/100 Methode Es werden nur bereits beendete Arbeitspakete und noch nicht angefangene Arbeitspakete unterschieden: –Bei bereits beendeten Arbeitspaketen ist der Fertigstellungsgrad 100%. –Bei noch nicht beendeten Arbeitspaketen wird unabhängig vom tatsächlichen Arbeitsfortschritt ein Fertigstellungsgrad von 0 angenommen. –Durch Aggregation über alle Arbeitspakte wird dann der Fertigstellungsgrad des gesamten Projekts ermittelt.

16 Copyright: Dr. Klaus Röber 16 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung 1. Beispiel für die 0/100 Methode ArbeitspaketGeplanter Aufwand Bisheriger Aufwand Restlicher Aufwand FG lt. 0/100 Methode Kumulierter FG A10 PT 0 PT100 %9,5 % B20 PT15 PT5 PT0 % C15 PT10 PT 0 % D10 PT0 PT10 PT0 % E30 PT15 PT 0 % F10 PT0 PT10 PT0 % G5 PT0 PT5 PT0 % Total100 PT50 PT55 PT9,5 % Dies Beispiel zeigt deutlich, dass der mit der 0/100 Methode ermittelte FG dramatisch vom realen FG (47,6 %) abweicht. In diesen ist diese Methode nicht zur Ermittlung des FG geeignet.

17 Copyright: Dr. Klaus Röber 17 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung 2. Beispiel für die 0/100 Methode ArbeitspaketGeplanter Aufwand Bisheriger Aufwand Restlicher Aufwand FG lt. 0/100 Methode Kumulierter FG A10 PT 0 PT100 %10 % B10 PT 0 PT100 %20 % C15 PT5 PT10 PT0 % D10 PT2 PT8 PT0 % E20 PT0 PT20 PT0 % F10 PT0 PT10 PT0 % G10 PT0 PT10 PT0 % H10 PT0 PT10 PT0 % I5 PT0 PT5 PT0 % Total100 PT27 PT73 PT20 % Im zweiten Beispiel kommt man mit der 0/100 Methode zu einem FG von 20 %. Zwar wird auch hier der reale Leistungsfortschritt (27 %) noch immer unterschätzt, dafür ist die Datengewinnung aber sehr einfach.

18 Copyright: Dr. Klaus Röber 18 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Wann ist die 0/100 Methode sinnvoll? Wie die Beispiele zeigen, führt die 0/100 Methode in beinahe allen Fällen zur Unterschätzung der bisher erbrachten Leistung. Diese Differenz kann bei einem hohen Anteil von begonnenen aber noch nicht fertig gestellten Arbeitspaketen so groß werden, dass die ermittelten Ergebnisse unbrauchbar sind. Der Vorteil ist die hohe Objektivität und die Einfachheit der Methode. Sie vermeidet das 90 %-Syndrom – eine Überschätzung des Leistungsfortschritts ist unmöglich. Wenn es sich um ein sehr detailliert strukturiertes Projekt mit vielen Arbeitspaketen handelt, die überwiegend nacheinander (nicht parallel) abgearbeitet werden, ist der Einsatz dieser Methode ideal. Grundlage für den Einsatz ist dann eine zeitnahe Berichterstattung. Der Projektleiter muss von abgeschlossenen Arbeitspaketen sofort Kenntnis erlangen und diese in seinem Berichten umsetzen.

19 Copyright: Dr. Klaus Röber 19 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Die 50/50 Methode Bei dieser Methode zur Feststellung des Fertigstellungsgrads werden drei Zustände unterschieden: –Arbeitspaket beendet: Fertigstellungsgrad 100 % –Arbeitspaket wird bearbeitet: Fertigstellungsgrad 50 % –Arbeitspaket noch nicht begonnen: Fertigstellungsgrad 0 % Durch Aggregation über das gesamte Projekt wird dann der Fertigstellungsgrad für das gesamte Projekt bestimmt.

20 Copyright: Dr. Klaus Röber 20 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel für die 50/50 Methode ArbeitspaketGeplanter Aufwand Bisheriger Aufwand Restlicher Aufwand FG lt. 0/100 Methode Kumulierter FG A10 PT 0 PT100 %10 % B10 PT 0 PT100 %20 % C15 PT5 PT10 PT50 %27,5 % D10 PT2 PT8 PT50 %32,5 % E20 PT0 PT20 PT0 % F10 PT0 PT10 PT0 % G10 PT0 PT10 PT0 % H10 PT0 PT10 PT0 % I5 PT0 PT5 PT0 % Total100 PT27 PT73 PT32,5 % Das Beispiel zeigt, dass mit der 50/50 Methode eine bessere Annäherung an den realen Leistungsfortschritt gelingt als mit der 0/100 Methode. In diesem Falle wird der Leistungs- Fortschritt sogar überschätzt (was eigentlich nicht gut ist!).

21 Copyright: Dr. Klaus Röber 21 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Wann ist der Einsatz der 50/50 Methode sinnvoll? Die 50/50 Methode ist eine sehr objektive und einfache Methode zur Ermittlung des Fertigstellungsgrads. Sie liefert i. d. R. bessere Ergebnisse als die 0/100 Methode. Sie eignet sich für den Einsatz in mittleren bis größeren Projekten, vor allem, wenn mehrere Arbeitspakete parallel bearbeitet werden. Sie ist auch dann die ideale Methode, wenn die Rückmeldungen nicht zeitnah sind.

22 Copyright: Dr. Klaus Röber 22 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Step-to-Step Methode Das Gesamtprojekt wird in sequenzielle, zeitlich bewertete Arbeitsschritte (Steps) untergliedert. Der Fertigstellungsgrad wird dann aus dem Verhältnis von beendeten Arbeitsschritten zur Gesamtanzahl an Arbeitsschritten errechnet. Voraussetzung ist, dass zweifelsfrei festgestellt werden kann, ob ein Arbeitsschritt abgeschlossen ist, also die geforderten Ergebnisse vorliegen. Dafür eignen sich bestens Meilensteine. In der Entwicklung von Software können Prozentsatzmethoden angewendet werden, da hierfür standardisierte Aufteilungen des Aufwands auf die Projektphasen vorliegen.

23 Copyright: Dr. Klaus Röber 23 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel für die Step-to-Step Methode MeilensteinAufwandFertigstellungsgrad MS 1100 PT20 % MS 250 PT30 % MS 380 PT46 % MS 4120 PT70 % MS 5100 PT90 % MS 6 (Projektende)50 PT100 % Gesamt500 PT Bei diesem Beispiel ist beim Erreichen eines Meilensteins jeweils eine exakte Angabe des Fertigstellungsgrades möglich. Wenn eine detailliertere Skalierung des Fertigstellungs- Grades erwünscht oder erforderlich ist, müssen mehr Meilensteine definiert werden.

24 Copyright: Dr. Klaus Röber 24 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel für Softwareentwicklung ProjektphaseAufwand in %Fertigstellungsgrad Anforderungsanalyse7 % Systementwurf16 %23 % Programmentwurf23 %46 % Codierung31 %77 % Systemintegration23 %100 % Summe100 % Im Beispiel wird eine standardisierte Aufwandsverteilung für eine mittelschwere Software- Entwicklung bei mittlerer Programmgröße (32 kloc) zugrunde gelegt.

25 Copyright: Dr. Klaus Röber 25 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Wann ist der Einsatz der Step-to-Step Methode sinnvoll? Wenn es sich um ein unübersichtliches Projekt mit sehr vielen Arbeitspaketen handelt, kann an bestimmten Punkten mit geringem Aufwand der objektive Status festgestellt werden. Nicht geeignet ist die Methode, wenn häufig Messungen des Leistungsfortschritts stattfinden sollen, da bei dieser Methode nur eine begrenzte Anzahl von Messpunkten zur Verfügung steht. Sie kann allerdings zusätzlich zu anderen Methoden eingesetzt werden und liefert dann sehr gute Ergebnisse.

26 Copyright: Dr. Klaus Röber 26 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Relative Methode Die relative Methode ist diejenige, die wir bisher immer stillschweigend als Referenzmodell benutzen, um den realen Projektfortschritt zu ermitteln. –Grundlage ist die Abfrage bei den Arbeitspaketverantwortlichen, wie viel Aufwand diese bisher für ihr Arbeitspaket aufgewendet haben und wieviel Aufwand noch verbleibt. –Aus diesen beiden Angaben lässt sich der Fertigstellungsgrad für jedes Arbeitspaket ermitteln. –Die Aggregation über alle Arbeitspakete liefert schließlich den Fertigstellungsgrad für das Gesamtprojekt. Vorsicht: Fragen Sie nicht direkt nach dem Fertigstellungsgrad, sondern immer nach dem bisherigen Aufwand und dem noch verbleibenden Aufwand. Seien Sie sich immer bewusst, dass der nach der relativen Methode ermittelte Fertigstellungsgrad eine Aggregation subjektiver Schätzungen darstellt. Das heißt, auch Schätzfehler summieren sich und können ein erhebliches Ausmaß erreichen.

27 Copyright: Dr. Klaus Röber 27 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel für die relative Methode ArbeitspaketGeplanter Aufwand Bisheriger Aufwand RestaufwandFG des Arbeitspakets FG des Projekts A115 PT6 PT9 PT40 % A220 PT10 PT 50 % A315 PT3 PT15 PT17 % A415 PT5 PT15 PT25 % A525 PT0 PT25 PT0 % A610 PT0 PT10 PT0 % Gesamt100 PT24 PT84 PT22 % Im Beispiel resultiert ein FG von 22 %. Man beachte, dass die 0/100 Methode hier zu einem FG von 0 % geführt hätte! Die 50/50 Methode hätte (mit der Bezugsbasis geplanter Aufwand) dagegen zu einem FG von 32,5 % geführt.

28 Copyright: Dr. Klaus Röber 28 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Wann ist der Einsatz der relativen Methode sinnvoll? Die relative Methode bringt, wenn sie richtig durchgeführt wird, im Vergleich aller Methoden die realistischten Werte und kann im Gegensatz zur Step-to-Step Methode praktisch zu jedem beliebigen Zeitpunkt durchgeführt werden. Die Qualität der erhobenen Daten ist auch darauf zurück zu führen, dass die geschätzten Aufwandsüberschreitungen im Schätzprozess als Nebenprodukt anfallen. Die Methode stellt hohe Anforderungen an Projektleiter und Arbeitspaketverantwortliche. Diese sollten eine gewisse Erfahrung im Schätzen mitbringen.

29 Copyright: Dr. Klaus Röber 29 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung Ermitteln Sie aus den Daten der nachfolgenden Tabelle den FG nach der 0/100-, der 50/50- und der relativen Methode. Welches Problem erkennen Sie, wenn Sie die Daten betrachten? Welche Methode scheint Ihnen die angemessene zu sein und warum? ArbeitspaketGeplanter AufwandBisheriger Aufwand A110 PT A215 PT A320 PT12 PT A410 PT3 PT A525 PT10 PT A610 PT0 PT A710 PT0 PT

30 Copyright: Dr. Klaus Röber 30 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Lösung ArbeitspaketGeplanter Aufwand Bisheriger Aufwand 0/100 Methode 50/50 Methode Relative Methode A110 PT 100 % A215 PT 100 % A320 PT12 PT0 %50 %60 % A410 PT3 PT0 %50 %30 % A525 PT10 PT0 %50 %40 % A610 PT0 PT0 % A710 PT0 PT0 % Gesamt100 PT50 PT25 %52,5 %50 % Es besteht folgendes Problem: Es wird nicht angegeben, ob das Arbeitspaket beendet oder noch in Arbeit ist. Es muss unterstellt werden, dass bei einem Aufwand in Höhe des geplanten Aufwands das Arbeitspaket abgeschlossen ist. Der verbleibende Aufwand ist nicht angegeben. Dies ist auch die Ursache dafür, dass sich die Anwendung der relativen Methode verbietet! Als sinnvolle Methode verbleibt damit die 50/50 Methode. Sie ist der 0/100 Methode überlegen, wenn mehrere Arbeits- Pakete parallel bearbeitet werden.

31 Copyright: Dr. Klaus Röber 31 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung Die folgende Tabelle zeigt dasselbe Projekt mit erweiterten Daten. Ermitteln Sie nochmals den Fertigstellungsgrad und vergleichen Sie das Ergebnis mit dem vorhergehenden. Ändert sich Ihre Einschätzung bzgl. der angemessenen Methode? ArbeitspaketGeplanter AufwandBisheriger AufwandRestaufwand A110 PT 0 PT A215 PT 5 PT A320 PT12 PT10 PT A410 PT3 PT12 PT A525 PT10 PT20 PT A610 PT0 PT10 PT A710 PT0 PT10 PT

32 Copyright: Dr. Klaus Röber 32 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Lösung ArbeitspaketGeplanter Aufwand Bisheriger Aufwand Restaufwand0/100 Methode 50/50 Methode Relative Methode A110 PT 0 PT 100 % A215 PT 5 PT 0 %50 %75 % A320 PT10 PT12 PT 0 %50 %45,5 % A410 PT3 PT12 PT 0 %50 %20 % A525 PT10 PT20 PT 0 %50 %33,3 % A610 PT0 PT10 PT 0 % A710 PT0 PT10 PT 0 % Gesamt100 PT50 PT67 PT10 %45 %42,7 % Wenn der verbleibende Aufwand angegeben ist, kann die relative Methode angewandt werden. Sichtbar wird ebenfalls, dass mit einer Überschreitung des geplanten Aufwands um 17 % gerechnet werden muss. Letztlich hängt die Wahl der Methode (50/50 oder relative Methode) davon ab, ob der Projektleiter die Daten für ausreichend zuverlässig erachtet.

33 Copyright: Dr. Klaus Röber 33 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Kostensteuerung Plan-Ist bzw. Soll-Ist-Vergleich der Kosten Ursachenanalyse der Abweichungen Gegebenenfalls Anpassung der Planung (Plankosten) an veränderte Bedingungen (Sollkosten) Einleitung von Maßnahmen, um eine Übereinstimmung von Planung und tatsächlichem Kostenverlauf zu gewährleisten bzw. Abweichungen zu minimieren. Voraussetzung jeder Kostensteuerung ist somit die Kostenkontrolle (Plan-Ist- bzw. Soll-Ist-Vergleich)

34 Copyright: Dr. Klaus Röber 34 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Kostentrendanalyse Die Kostentrendanalyse ist eine Methode zur Ermittlung der Kostensituation in einem Projekt. Sie kann aber ebenso für Teilprojekte oder große Arbeitspakete verwendet werden. Der besondere Vorzug der Kostentrendanalyse (wie der aller Trendanalysen) liegt im Zukunftsbezug der Aussagen. Es werden nicht nur Plan-Ist Vergleiche durchgeführt, sondern zugleich Schätzungen über die zukünftige Entwicklung angestellt, die i. d. R. mit zunehmender Projektdauer zuverlässiger werden. Die Kostensituation wird durch Gegenüberstellung der Plan- und der Sollkosten aufgezeigt. Die Darstellung erfolgt meist grafisch in einem Koordinatensystem. Auf der Ordinate werden die Kosten eingetragen und auf der Abszisse der Zeitstrahl mit den Berichtszeitpunkte.

35 Copyright: Dr. Klaus Röber 35 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Vorgehensweise 1.Die geplanten Gesamtkosten (Plankosten) des Projekts werden waagerecht eingetragen. 2.Zu jedem Berichtszeitpunkt werden für jedes Arbeitspaket die Ist- Kosten ermittelt und die Restkosten geschätzt. 3.Die Berichtszeitpunkte sind so zu wählen, dass Abweichungen rechtzeitig erkannt werden (und durch Gegenmaßnahmen noch eine Korrektur möglich ist!). 4.Durch Addition dieser beiden Werte über alle Arbeitspakete werden die aktualisierten Plankosten (= Sollkosten) für das Projekt ermittelt. 5.Die Werte werden in das Diagramm eingetragen und begründet. So entsteht ein zweiter Polygonzug.

36 Copyright: Dr. Klaus Röber 36 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Trendaussagen Der zweite Polygonzug zeigt bei folgenden Kurvenverläufen einen Trend an: –Plankosten und Sollkosten sind identisch (im Diagramm deckungsgleich) Die Plankosten werden eingehalten –Steigender Kurvenverlauf (wachsende Differenz zwischen Plan- und Sollkosten) Anzeichen für Kosten treibende Einflussfaktoren – Maßnahmen erforderlich! –Fallender Kurvenverlauf (wachsende Differenz zwischen Plan- und Sollkosten) Anzeichen für anhaltend Kosten senkende Einflussfaktoren – Ursachenanalyse! –Waagerechter Kurvenverlauf nach einem Sprung (nach oben oder nach unten) Nach einer einmaligen Störung bzw. einem einmaligen günstigen Ereignis wieder planmäßiger Verlauf; die Plankosten erhöhen sich um den durch den Sprung angezeigten Betrag.

37 Copyright: Dr. Klaus Röber 37 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel BerichtszeitpunktPlankostenAktuelle Ist- Kosten Geschätzte Restkosten Sollkosten (= geschätzte Gesamtkosten)

38 Copyright: Dr. Klaus Röber 38 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Kostentrenddiagramm für das Beispiel Kosten Zeit Plankosten Sollkosten

39 Copyright: Dr. Klaus Röber 39 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Interpretation des Kostentrenddiagramms Die Projektmitarbeiter erkennen auf einen Blick: –Zunächst ist das Projekt (hinsichtlich der kosten) planmäßig verlaufen. –Beim dritten Berichtszeitpunkt wurde erstmals eine Kostenüberschreitung von 2,5 % geschätzt. –Bei den folgenden Berichtszeitpunkten hat sich die Lücke zwischen Plan- und Sollkosten ständig auf zuletzt Euro (12,5 %) erweitert. –Der Projektleiter hätte spätestens nach dem vierten Berichtszeitpunkt Gegenmaßnahmen einleiten müssen.

40 Copyright: Dr. Klaus Röber 40 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Ursachenanalyse Um Gegenmaßnahmen einleiten zu können, muss die Ursache der Kostenabweichung ermittelt werden. Nur aus der Kenntnis der Ursache heraus können zielgenaue Maßnahmen ergriffen werden. Vorsicht: Positive und negative Abweichungen in den Arbeitspaketen können sich ausgleichen! Deshalb gilt: Die Ursachen sind leichter zu ergründen, wenn auf die Arbeitspakete abgestellt wird, in denen die Abweichungen auftreten.

41 Copyright: Dr. Klaus Röber 41 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Mögliche Ursachen für Abweichungen (1) Planungsfehler: –Eine zu optimistische Planung ist keine Grundlage für die Kostenkontrolle. Als Erstes ist die Planung zu überprüfen! Maßnahme: Überarbeitung der Planung. Unplanmäßig schneller Projektfortschritt: –Wenn bis zu den jeweiligen Berichtszeitpunkten mehr Leistung erbracht wurde als geplant, liegen die Kosten entsprechend über den geplanten Ansätzen. Die Leistungskontrolle ist somit Bestandteil der Kostenkontrolle (s. auch Earned Value Analyse). –Ist ein unplanmäßiger Projektfortschritt die Ursache, brauchen keine Korrekturmaßnahmen eingeleitet zu werden, da die Plan- und Sollkosten am Projektende wieder übereinstimmen. Unwirtschaftliche Projektabwicklung: Für die einzelnen Arbeitspakete fallen höhere Aufwände an als geplant. Ursachen dafür könnten sein: –Mitarbeiter sind nicht so produktiv wie geplant (hohe Fluktuation, schlechte Ausbildung, Überlastung durch Linienarbeit …) –Angeforderte Mitarbeiter wurden nicht ins Projekt abgestellt –Mitarbeiter sind nicht motiviert –Leitungsmängel des Projektleiters (unklare Anweisungen, mangelnde Kompetenzausstattung der Mitarbeiter…)

42 Copyright: Dr. Klaus Röber 42 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Mögliche Ursachen für Abweichungen (2) Ausfall wichtiger Mitarbeiter: –Wegen Kündigung, Erkrankung und Ersatz durch weniger qualifizierte Mitarbeiter. Qualitätsmängel: –Qualitätsmängel führen zu Mehrkosten, da Nacharbeiten erforderlich werden. Je später die Qualitätsmängel erkannt werden, desto teurer die Behebung der Mängel. Maßnahme: Überprüfung der Qualitätssicherung. Zusätzliche Anforderungen: –Für zusätzliche Anforderungen kann der Projektleiter nicht verantwortlich gemacht werden. Bei notwendigen zusätzlichen Anforderungen (vom Lenkungsausschuss genehmigt!) muss das Budget angepasst werden! Kostensteigerungen: –Erforderliche Geräte, Material und externe Leistungen kosten mehr, da zwischenzeitlich Preiserhöhungen stattgefunden haben. Dafür kann der Projektleiter nicht verantwortlich gemacht werden!

43 Copyright: Dr. Klaus Röber 43 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Wann ist die Kostentrendanalyse sinnvoll? Grundsätzlich ist der Einsatz der Kostentrendanalyse immer sinnvoll, wenn einige Punkte beachtet werden: –Die Kostentrendanalyse ist nur zusammen mit einer Ursachenanalyse sinnvoll. Aus der Ursachenanalyse geht hervor, welche Maßnahme einzuleiten sind. Nicht immer kann jedoch gegen gesteuert werden, z. B. wenn die erforderlichen und zugesagten Mitarbeiter nicht ins Projekt abgestellt wurde. Das Ausmaß kann aber möglicherweise durch Qualifizierungsmaßnahmen begrenzt werden. –Abweichungen von den Plankosten müssen von den Arbeitspaketverantwortlichen begründet werden. –Es ist darauf zu achten, dass die erforderliche Schätzung der Restkosten sorgfältig von erfahrenen Mitarbeitern durchgeführt wird bzw. von erfahrenen Mitarbeitern verifiziert wird. –Der alleinige Blick auf die Kostentrendanalyse kann Probleme übertünchen: wenn positive und negative Abweichungen sich ausgleichen, müssen dennoch Maßnahmen ergriffen werden! Die Vorteile sind: –Leicht zu erstellen und zu interpretieren –Abweichungen auf einen Blick zu erfassen –Für Präsentationen bestens geeignet –Ideales Frühwarnsystem –Frühzeitige Prognose der Gesamtkosten möglich.

44 Copyright: Dr. Klaus Röber 44 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Terminorientierte Kostenkontrolle Die terminorientierte Kostenkontrolle stellt nicht wie die Kostentrendanalyse ein in die Zukunft gerichtetes Steuerungsinstrument dar, sondern ist rein gegenwartsbezogen. Durch die Einbeziehung der Termine und des Sachfortschritts liefert sie aber zuverlässige Aussagen über den gegenwärtigen Stand der Kosten im Projekt. Das Instrument der terminorientierten Kostenkontrolle isr das Kosten-Termin-Diagramm.

45 Copyright: Dr. Klaus Röber 45 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Wie wird ein Kosten-Termin-Diagramm erstellt? 1.Definition von Meilensteinen, an denen ein klar definierter Sachfortschritt vorliegen muss. 2.Planung der Termine, an denen die definierten Meilensteine erreicht sein sollen. 3.Planung der Kosten, die zur Erreichung der Meilensteine aufgewendet werden müssen. 4.Eintragen der Punkte in ein Zeit-Kosten-Diagramm: Jeder Meilenstein wird durch die Koordinaten Zeit und kosten beschrieben. Ggf. Kann durch Verbinden der Punkte ein Graph erzeugt werden. 5.Bei Erreichen der Meilensteine werden in einer anderen Farbe oder mit anderen Symbolen die erreichten Meilensteine eingetragen, und zwar bei den dann realisierten Koordinaten. So entsteht nach und nach eine zweite Reihe von Punkten. 6.Die Lage der Punkte gibt Aufschluss über die Kosten- und Terminsituation im Projekt.

46 Copyright: Dr. Klaus Röber 46 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel Für ein Projekt wurden vier Meilensteine definiert, der letzte repräsentiert das Planende. Die folgende Tabelle zeigt die Plan- und Istdaten: MeilensteinGeplanter Termin Ist-TerminGeplante Kosten Ist-Kosten A B C D

47 Copyright: Dr. Klaus Röber 47 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Kosten-Termin-Diagramm Kosten Zeit Plan Ist

48 Copyright: Dr. Klaus Röber 48 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung: Kosten-Trendanalyse Führen Sie aufgrund der folgenden Angaben eine Kosten-Trendanalyse durch (Tabelle und Graphik). Das Projekt besteht wegen der besseren Übersichtlichkeit nur aus drei großen Summenarbeitspaketen. Wo setzen Sie bei der Ursachenanalyse an? Arbeit einzeln Zeit: 20 Minuten

49 Copyright: Dr. Klaus Röber 49 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung: Arbeitspaket 1 BerichtszeitpunktPlankostenAktuelle Ist-KostenGeschätzte Restkosten Z Z Z Z Z Z Z Z Z Z

50 Copyright: Dr. Klaus Röber 50 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung: Arbeitspaket 2 BerichtszeitpunktPlankostenAktuelle Ist-KostenGeschätzte Restkosten Z Z Z Z Z Z Z Z Z Z

51 Copyright: Dr. Klaus Röber 51 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung: Arbeitspaket 3 BerichtszeitpunktPlankostenAktuelle Ist-KostenGeschätzte Restkosten Z Z Z Z Z Z Z Z Z Z

52 Copyright: Dr. Klaus Röber 52 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Lösung (1) Berichtszeit- punkt PlankostenAktuelle Ist- Kosten Geschätzte Restkosten Sollkosten (= geschätzte Gesamtkosten) Z Z Z Z Z Z Z Z Z Z

53 Copyright: Dr. Klaus Röber 53 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Lösung (2) Zeit Plan Ist Bei der Ursachenanalyse ist Arbeitspaket 2 zu analysieren, da bei den anderen beiden keine Abweichungen erkennbar sind. Kosten

54 Copyright: Dr. Klaus Röber 54 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Terminsteuerung Plan-Ist bzw. Soll-Ist Vergleich der Termine des Projekts oder von Teilen davon. Ursachenanalyse der Abweichungen Ggf. Anpassung der Planung (Plantermine) an veränderte Bedingungen (Solltermine) Einleitung von Maßnahmen, um eine Übereinstimmung von Planung und tatsächlichen Terminen zu gewährleisten bzw. Abweichungen zu minimieren.

55 Copyright: Dr. Klaus Röber 55 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Zeitlicher Fertigstellungsgrad Der zeitliche Fertigstellungsgrad ist das Äquivalent zum leistungsmäßigen Fertigstellungsgrad, der den sachlichen Projektfortschritt zeigt. Er wird wie folgt ermittelt: 1.Der zeitliche Fertigstellungsrad wird einzeln für jedes Arbeitspaket ermittelt. 2.Er bezeichnet das Verhältnis von Ist-Dauer zur voraussichtlichen Gesamtdauer des Arbeitspakets. 3.Der zeitliche Fertigstellungsgrad beinhaltet zwei Komponenten: die bisherige Dauer (Ist-Dauer) des Arbeitspakets die vom Arbeitspaketverantwortlichen geschätzte noch verbleibende Dauer des Arbeitspakets. 4.Die Ermittlung der Ist-Dauer und die Schätzung der noch verbleibenden Dauer sind regelmäßig durchzuführen, um die Arbeitspaketverantwortlichen zu gewissenhaften Schätzungen zu veranlassen (jede Schätzung wird durch die nächste Schätzung gewissermaßen automatisch überprüft). 5.Damit beinhaltet der zeitliche Fertigstellungsgrad mit fortschreitender Dauer des Arbeitspakets eine immer zuverlässigere Schätzung der verbleibenden Dauer und damit des voraussichtlichen Endtermins. 6.Aus dem voraussichtlichen Endterminen der einzelnen Arbeitspakete wird auf den Endtermin des Projekts geschlossen: Sind von einer Verzögerung des betrachteten Arbeitspakets auch andere Arbeitspakete und deren Endtermine betroffen? Wenn ja, welche Maßnahmen können ergriffen werden, um die Terminabweichung zu verhindern oder zu minimieren?

56 Copyright: Dr. Klaus Röber 56 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Darstellung der Ergebnisse Zur Darstellung der Ergebnisse der Ermittlung des zeitlichen Fertigstellungsgrads eignen sich hervorragend einfache Balkendiagramme. Der voraussichtliche Endtermin sowie die geschätzte Restdauer sind auf einen Blick ersichtlich. Start Jetzt Geplantes Ende Vorauss. Ende Zeit In der Grafik ist das Verhältnis der Strecke vom Start bis Jetzt zu der Strecke von Start bis vorauss. Ende der zeitliche Fertigstellungsgrad. Die Strecke von Jetzt bis vorauss. Ende ist die geschätzte Restdauer des Arbeits- pakets, die erheblich über dem geplanten Ende liegt. Es empfiehlt sich, solche einfachen Balkendiagramme für alle oder für alle zeitkritischen Arbeitspakete anzulegen.

57 Copyright: Dr. Klaus Röber 57 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel ArbeitsbeginnBerichtszeit- punkt Ist-DauerPrognose Restdauer Geplanter Endtermin Prognose Endtermin Tage49 Tage Tage45 Tage Tage44 Tage Arbeitspaket A1 Verantwortlicher: Hr. Meier Zum Berichtszeitpunkt ergibt sich: Ein zeitlicher Fertigstellungsgrad von 32,3% (Ist-Dauer)/(Ist-Dauer + Restdauer) Der Endtermin verschiebt sich vom auf den 6.4..

58 Copyright: Dr. Klaus Röber 58 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Wann ist die Ermittlung des zeitlichen FG sinnvoll? Grundsätzlich ist die Ermittlung des zeitlichen Fertigstellungsgrades immer sinnvoll, da –er sehr leicht zu ermitteln ist, –leicht zu interpretieren ist, –er ein in die Zukunft gerichtetes Instrument ist und damit –ein ideales Frühwarnsystem darstellt, da die kleinsten operativen Bausteine des Projekts (Arbeitspakete) betrachtet werden und aus dem Ablauf unmittelbar hervorgeht, welche der nachfolgenden Arbeitspakete von Terminverschiebungen betroffen sind. Zu beachten ist: –Alle Beteiligten müssen sich bewusst sein, dass der zeitliches Fertigstellungsgrad keinerlei Verbindungen zum sachlichen Fortschritt und zur Kostensituation aufweist. –Er zielt isoliert auf die Terminsituation ab. –Er ermöglicht nur eine Momentaufnahme, ein Trend wird nicht abgebildet.

59 Copyright: Dr. Klaus Röber 59 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Meilenstein-Trend-Analyse (Dr. Georg Angermeier) Die Meilenstein-Trendanalyse (MTA) ist wohl eines der bekanntesten Controllinginstrumente im Projektmanagement (Deutschland). Sie ist sehr leicht zu erstellen: Man braucht dafür nicht mehr als Papier und Bleistift. Außerdem ist die leicht zu verstehen. International wird sie allerdings kaum beachtet, sondern fristet ein bescheidenes Dasein in einigen deutschen Lehrbüchern und Schulungsunterlagen. Nur wenige PM-Werkzeuge verfügen über dieses Leistungsmerkmal, die meisten benötigen dafür ein Add-On. Herr Angermeier meint jedoch, dies sei ungerechtfertigt, denn die MTA erfüllt eine wichtige Funktion: Sie symbolisiert das persönliche Bekenntnis (Commitment) der Mitarbeiter zum Terminplan bzw. den Meilensteinen, für die sie zuständig sind.

60 Copyright: Dr. Klaus Röber 60 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Meilensteine: Die Manager-Sicht auf das Projekt Geschäftsverantwortliche brauchen einen schnellen Gesamtüberblick über das Projektportfolio. Sie können und dürfen nicht ins Detail gehen. Einen Abteilungsleiter oder Geschäftsführer, der für das operative Liniengeschäft und gleichzeitig für mehrere Projekte verantwortlich ist, interessieren Balken- oder Netzpläne mit hunderten von Vorgängen und Basisplänen nicht. Auch für den Projektbeteiligten gleich ob verantwortlich oder ausführend, ist der Blick auf das Projekt aus der Vogelperspektive wichtig, um sich nicht in Einzelheiten zu verzetteln und das Projektziel im Auge zu behalten. Unverzichtbar wird der Überblick über die wesentlichen Stationen eines Projekts, sobald mehrere Organisationseinheiten ihre Planung aufeinander abstimmen müssen. Werden in der Planungsphase zentrale Meilensteine vereinbart und in der Durchführungsphase mittels MTA überwacht, erhält das Management die nötige Übersicht über Termine und Ergebnisse. Die Kostenkontrolle muss parallel dazu erfolgen, ist aber nicht Gegenstand der MTA.

61 Copyright: Dr. Klaus Röber 61 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung MTA-Diagramm (Erläuterung s. Folgefolie)

62 Copyright: Dr. Klaus Röber 62 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung MTA-Erläuterung Ein rechtwinkliges und gleichschenkliges Dreieck wird so gezeichnet, dass der rechte Winkel links oben liegt. Auf der Vertikalen werden von unten nach oben die geplanten Endtermine der Meilensteine im Projekt eingetragen. Wichtig ist, auf die Skalierung der Zeitachse zu achten: Der Projektbeginn liegt unten! Auf der Horizontalen werden die Berichtszeitpunkte nach dem Projektstart von links nach rechts eingetragen. Bei jedem Berichtszeitpunkt wird für jeden Meilenstein der erwartete Endzeitpunkt neu geschätzt. Durch die Verbindung der so ermittelten Endzeitpunkte entsteht eine Linie, die sich Schritt für Schritt der Hypotenuse annähert. Trifft die Linie eines Meilensteins auf die Hypotenuse, so ist der Meilenstein erreicht. Seine Lage auf der senkrechten Skala zeigt den Termin an, zu dem er schließlich erreicht wurde. Aus dem Verlauf der so erzeugten Linien lassen sich nun eine Reihe von Schlüssen ziehen.

63 Copyright: Dr. Klaus Röber 63 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Die MTA visualisiert den zeitlichen Status des Projekts

64 Copyright: Dr. Klaus Röber 64 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Typische Verläufe: Ideale Kurve So wie auf dieser Abbildung sollten die Meilensteine idealer- weise angeordnet sein. Die Projektplanung ist so perfekt, dass in der Abwicklung keiner- lei Probleme auftreten. Kein Termin gerät in Gefahr, alle Meilensteine werden exakt einge- halten. Leider ist ein solches MTA-Chart Äußerst unrealistisch!

65 Copyright: Dr. Klaus Röber 65 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Typische Verläufe: Die Kampfkurve (1)

66 Copyright: Dr. Klaus Röber 66 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Typische Verläufe: Die Kampfkurve (2) Diese MTA-Chart sieht zunächst katastrophal aus. Die Kurve weist auf ein Projekt hin, bei dem die Meilensteinverantwortlichen dem Projektleiter mitteilen, dass das Projekt für sie nicht die höchste Priorität hat. Es besteht offenbar ein Machtkampf zwischen der Projektleitung, die Termine setzt, und den Meilensteinverantwortlichen, die diese Termine nicht akzeptieren. Um in diesem Fall zu klären, warum die Mitarbeiter das Projekt ablehnen und was zu tun ist, um es zu retten, ist eine genaue Umfeld- und ggf. eine Projektanalyse notwendig. Die MTA liefert lediglich Warnsignale, sie ist jedoch keine Ursachenanalyse! Diese muss eigens betrieben werden. Im Beispiel könnte der weitere Projektverlauf so aussehen: –Durch eine Neuplanung in enger Abstimmung mit den Meilensteinverantwortlichen gelang es, das Projekt doch noch zum Erfolg zu führen. Zentrale Maßnahme war der Austausch der Meilensteine 3 und 4. Wie aus der Abb. ersichtlich, lieferte Meilenstein 4 die goldene Brücke zur Lösung des Konflikts. Die Planer gestanden eigene Fehler ein und machten so den Weg für ein Entgegenkommen der Meilensteinverantwortlichen frei. Dieses Zugeständnis war nur möglich, weil dieser Meilenstein unabhängig von den anderen Meilensteinen war. Darüber hinaus entlastete die Geschäftsführung die Meilensteinverantwortlichen von anderen Aufgaben. So konnten alle Skeptiker ins Boot geholt werden, ohne dass ernste Konflikte ausbrachen.

67 Copyright: Dr. Klaus Röber 67 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Typische Verläufe: Die engagierte Kurve Das gut geplante und allgemein akzeptierte Projekt weist weder extreme Sprünge noch die horizon- talen Ideallinien auf. Vielmehr ist der leicht geschwungene Kurvenverlauf typisch für den realistischen Idealfall. Die ersten Meilensteine werden in etwa eingehalten. Die Verantwortlichen schätzen die Termine tatsächlich jeweils zum Stichtag neu und schreiben sie nicht einfach blindlings fort. Sobald ein Meilensteinverantwortlicher die Prognose abgibt, dass sich ein Meilenstein verzögert, sorgen Steue- rungsmaßnahmen dafür, dass der Trend gebrochen oder sogar umge- kehrt wird.

68 Copyright: Dr. Klaus Röber 68 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Typische Verläufe: Alarmstufe Rot (1)

69 Copyright: Dr. Klaus Röber 69 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Typische Verläufe: Alarmstufe Rot (2) Die gefährliche Projektsituation sieht nach den ersten Treffen zunächst harmlos aus: Alle Meilensteine bleiben am Anfang unberührt auf ihrem Termin stehen. Aber sobald sie sich dem Endtermin nähern, beginnen sie, auf der Diagonalen nach oben zu wandern. Der Projektleiter wird von einem zum nächsten Treffen vertröstet. Mit der Zeit verdichten sich die Meilensteinlinien zu einer Schallmauer, die mit dem Knall des Projektabbruchs zerbrechen wird. Die Kurve ist ein untrügliches Zeichen dafür, dass –niemand das Projekt ernst nimmt –sich niemand für das Projekt verantwortlich fühlt –niemand das eigene Teilprojekt voran treibt –der Projektleiter isoliert ist und nicht respektiert wird. Sobald der erste Meilenstein deutlich nach oben rutscht, muss Alarmstufe Rot herrschen – auch wenn sich alles noch als harmlos heraus stellen kann. Der Projektleiter muss heraus finden, ob sich eine ernste Krise abzeichnet oder ob es sich nur um Startschwierigkeiten handelt. Dazu muss er sich vor Ort bei den Mitarbeitern über die Gründe für die Verzögerung informieren.

70 Copyright: Dr. Klaus Röber 70 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Typische Verläufe: Die Stellvertreter- und Lobbykurve (1)

71 Copyright: Dr. Klaus Röber 71 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Typische Verläufe: Die Stellvertreter- oder Lobbykurve (2) Eine Falle, in die auch Profis hinein tappen können! Die ersten Meilensteine verzögern sich, aber die Meilensteine ab Nummer 4 bleiben davon unberührt auf ihren prognostizierten Terminen stehen. Sobald der Meilenstein erledigt ist, auf den die angeblich ungefährdeten Meilensteine folgen, kommt das böse Erwachen. Die Verantwortlichen für die Meilensteine 4 bis 7 haben zu Anfang des Projekts die Auswirkungen der Verzögerungen nicht ernst genommen oder aus politischen Gründen verschwiegen. Die Situation ist besonders gefährlich, da sie zunächst eine normale Entwicklung vortäuscht. Die ersten Meilensteine haben bereits eine Dynamik, die Maßnahmen erfordert. Frühwarnsignale für spätere kritische Entwicklungen werden übertönt. Für effektive Steuerungsmaßnahmen ist es zu spät, wenn die Bombe schließlich platzt. Als die Gefahr für alle Beteiligten deutlich wird, liegen die nunmehr realistisch geschätzten Termine für die letzten Meilensteine so spät, dass das Projekt abgebrochen werden muss.

72 Copyright: Dr. Klaus Röber 72 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Situation klären – Steuerungsmaßnahmen ergreifen Sobald das MTA-Chart vor Terminrisiken warnt, muss der Projektleiter handeln. Denn Beschleunigungsmaßnahmen greifen immer erst mit einer Verzögerung. Jeder Tag zählt, Routineaufgaben müssen aufgeschoben werden. Als erstes muss er die Situation klären. Wer zugleich Projektcontrolling mit der Earned Value Analyse betreibt (s. später), dem steht mit dem Schedule Performance Index (SPI) bereits ein wichtiger zusätzlicher Indikator zu Verfügung. Die wirksamste aber auch aufwändigste Methode zur Situationsklärung ist der Vor-Ort- Einsatz des Projektleiters. Der unmittelbare Kontakt mit den Projektmitarbeitern gibt ihm ein untrügliches Feedback über den tatsächlichen Projektstatus. Bei echten Problemen, also wenn Projektverantwortliche und Mitarbeiter nicht wissen, wie sie weiter arbeiten sollen, helfen die klassischen Problemlösungsmethoden wie das Ishikawa Diagramm oder das Ursache-Wirkungsdiagramm (s. später). Sobald eine Gefahr für das Projekt erkannt ist, muss der Projektleiter seinen Vorgesetzten Meldung erstatten. Dies ist je nach Projektorganisation der Lenkungsausschuss, der Geschäftsführer oder der Auftraggeber. Der Projektleiter muss sich deren Unterstützung versichern und dann die nötigen Steuerungsmaßnahme ergreifen.

73 Copyright: Dr. Klaus Röber 73 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung So gehen Sie bei der MTA vor: Das Schöne an der MTA ist, dass sie für Projekte aller Größenordnungen geeignet ist – von der Vorbereitung einer Weihnachtsfeier bis hin zur Erschließung eines Industriegebiets. Ein einziges Flip-Chart reicht aus, um den Terminverlauf des gesamten Projekts zu visualisieren. Hier ein paar Tipps für die manuelle MTA per Flip-Chart: Verwenden Sie ein kariertes Flip-Chart-Blatt. Bereiten Sie das MTA-Chart mit Lineal und Kalender vor. So umgehen Sie die Gefahr, sich in der Sitzung vor ungeduldig wartenden Zuschauern zu verzeichnen. Lassen Sie nach oben und nach rechts genügend Spielraum für Terminüberschreitungen – aber nicht zuviel, denn das hätte eine verheerende psychologische Wirkung auf die Betrachter. Fünf Meilensteine sind ideal, sieben sind noch in Ordnung, zehn die absolute Obergrenze. Erstellen Sie auf einem zweiten Blatt eine Meilensteintabelle mit Nummer, Titel und Namen der Verantwortlichen. Hängen Sie dieses Blatt neben das Flip-Chart. Bewahren Sie das erstellte Flip-Chart sorgfältig auf und fotografieren Sie nach jedem Treffen die aktuellste Version.

74 Copyright: Dr. Klaus Röber 74 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung MTA pragmatisch: Es müssen nicht immer Dreiecke sein Die Dreiecksform stammt noch aus Zeiten, in denen es nur Papier und Stift für die Visualisierung von Projektdaten gab. Sie wird zwar von einem Lehrbuch und einer Schulungsunterlage zur anderen übernommen, ist aber verzichtbar. Reine Zeitverschwendung ist es, einem Tabellenkalkulationsprogramm mit Hilfe von Makros und Script-Programmierungen das Dreieck-Zeichnen beizubringen. Eine einfache Tabelle mit den Datumsreihen und ein einfaches X-Y Diagramm erfüllen alle Anforderungen für die MTA.

75 Copyright: Dr. Klaus Röber 75 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung: Pyramidenbau (1) (vgl. W. Gruber) Ein Pharao beabsichtigt, eine Pyramide als Grabdenkmal für sich und seine Frau zu bauen. Als durchzuführende Arbeiten wurden identifiziert und die Zeitdauer dafür geschätzt: –Planung (zwei Jahre) –Vorbereiten des Untergrunds und Einrichten der Baustelle (ein Jahr) –Steine aus dem Steinbruch holen und fertig bearbeiten (zehn Jahre) –Transport der Steine zur Baustelle (insgesamt zwei Jahre), die einfache Transportzeit beträgt zwei Monate, es stehen drei Transportanlagen zur Verfügung) –Errichten der Pyramide (15 Jahre) Aus diesen Angaben hat der im Projektmanagement noch unerfahrene Projektleiter den folgenden Zeitplan erstellt (der Pharao hat angeordnet, dass anlässlich des Baus der Pyramide eine neue Zeitrechnung beginnen soll): TätigkeitDauerTermin PlanungZwei Jahre VorbereitungEin Jahr SteinbrucharbeitenZehn Jahre TransportZwei Jahre Errichten der Pyramide15 Jahre

76 Copyright: Dr. Klaus Röber 76 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung: Pyramidenbau (2) Als der Pharao den Terminplan sah, war er überhaupt nicht zufrieden. 30 Jahre, da könnte er ja leicht vorher sterben, und dann stünde kein standesgemäßes Grabmal zur Verfügung! Er würde sich im Totenreich unsterblich blamieren! Er fordert deshalb, die Projektdauer um mindestens 10 Jahre, besser um 12 Jahre zu verkürzen, da er dann exakt 50 Jahre alt sein wird. –Sicher können Sie dem Pharao helfen, die Projektdauer zu verkürzen! Erstellen Sie einen Terminplan, der der Forderung des Pharaos entspricht. –Der Pharao fordert ferner eine Meilenstein-Trendanalyse anzulegen, um die neue Terminplanung überwachen zu können und ständig über die erwartete Fertigstellungszeit informiert zu sein. –Alle Arbeiten laufen zunächst nach Plan. Nach 5 Jahren stellt sich heraus, dass die Steinbrucharbeiten um zwei Jahre länger dauern als ursprünglich geplant. Stellen Sie diese Situation in einer MTA dar. Ergeben sich daraus weitere Konsequenzen? Jeder arbeitet allein Zeit: 20 Minuten

77 Copyright: Dr. Klaus Röber 77 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Lösung (1) Die Projektdauer kann durch Parallelisierung und Überlappung der Arbeiten verkürzt werden. Die Planung ist sachlogisch die Voraussetzung für alle anderen Tätigkeiten. Jedoch die Vorbreitung der Baustelle und die Steinbrucharbeiten können zeitgleich beginnen (Einsparpotenzial: 1 Jahr). Der Transport kann ebenfalls parallel zu den Steinbrucharbeiten erfolgen (Einsparpotenzial zwei Jahre) Schließlich kann mit dem Errichten der Pyramide nach Abschluss der Vorbereitungsarbeiten begonnen werden – die Steinbrucharbeiten laufen bereits seit einem Jahr und die fertigen Steine wurden bereits zur Baustelle transportiert (Einsparpotenzial: 12 Jahre) Insgesamt ergibt sich damit eine Projektdauer von 18 Jahren – die Projektdauer wurde also um 12 Jahre verkürzt. MeilensteinKürzelTermin Planung beendetMS Vorbereitung beendetMS Steinbrucharbeiten beendetMS Pyramide errichtetMS

78 Copyright: Dr. Klaus Röber 78 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Lösung (2) Wie in der MTA zu sehen ist, hat eine Verzögerung der Stein- brucharbeiten keine Auswirkun- gen auf das Projektende.

79 Copyright: Dr. Klaus Röber 79 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Fazit: Effektives Termincontrolling mit minimalem Aufwand Die MTA ist eine äußerst einfache Methode mit maximaler Wirkung zur Projektüberwachung hinsichtlich des Faktors Zeit – vorausgesetzt, ihre Kommunikationsfunktion wird richtig eingeschätzt. Gerade für komplexe Projekte, bei denen verschiedene Organisationseinheiten zusammen wirken, ist sie ein mächtiges Werkzeug, das durch seine Dokumentationsfunktion sowohl auf der ein sachlichen Ebene der Terminplanung als auch auf der politischen Ebene der verbindlichen zusagen Transparenz über den Projektverlauf schafft. Bei kleinen Projekten ist sie das Mittel der Wahl, um den Verwaltungsaufwand für das Projektmanagement so gering wie möglich zu halten. Gemeinsam mit dem Projektstrukturplan bildet sie ein ausreichendes Instrumentarium für ein vollständiges Projektmanagement von Kleinstprojekten. Die MTA ist eine wesentliche Ergänzung für das Kosten-Controlling durch die Kosten-Trendanalyse oder den Soll-Ist-Vergleich um den zeitlichen Aspekt. Die Earned Value Analyse ergänzt die MTA um eine intuitiv erfassbare Visualisierung des Projektstatus, präzisiert deren Prognosefunktion und schafft Verbindlichkeit der Meilensteinverantwortlichen bezüglich ihrer Terminzusagen.

80 Copyright: Dr. Klaus Röber 80 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Varianten: Ressourcen-Trend-Analyse und Kosten-Trend-Analyse Mit denselben Techniken lasse sich auch Ressourcenverbrauch und Kosten, die für die Erreichung der Meilensteine aufgewandt werden müssen, überwachen.

81 Copyright: Dr. Klaus Röber 81 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Ursachen-Wirkungsanalyse Auf Folie 72 wurde erwähnt, dass bei echten Problemen, bei denen das Team nicht so recht weiß, wie es weiter arbeiten soll, eine Ursachen- Wirkungsanalyse durchgeführt werden sollte. Zu diesem Zweck verzweigen wir in den Modul Ursachen-Wirkungsanalyse Ursachen-Wirkungsanalyse

82 Copyright: Dr. Klaus Röber 82 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Earned Value Analyse (1) Die Earned Value Analyse entstand Anfang der 60iger Jahre als Kontrollverfahren der US Airforce parallel zur Netzplanmethode PERT. IM PMBOK wird diese Methode als Steuerungsmethode favorisiert. Die Methode ist verbindlich für alle Projekte des amerikanischen Verteidigungsministeriums sowie für den gesamten öffentlichen Bereich. In verschiedenen Ländern sind bereits Standards zur Anwendung von Earned Value definiert, neben den USA auch in Kanada, Australien und UK. Earned Value ist dort als Steuerungsinstrument für Projekte verbreitet und gewinnt in den letzten Jahren durch internationale Projekte auch im deutschsprachigen Raum an Bedeutung. Vgl. Thomas Valenta

83 Copyright: Dr. Klaus Röber 83 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Earned Value Analyse (2) Die Earned Value Analyse (EVA) wird von vielen Profis als das derzeit beste Kontrollinstrument gepriesen. Für andere ist sie dagegen zu aufwendig, Wir werden hier zeigen, dass die Einschätzung der Profis stimmt und sie dabei noch relativ einfach durchzuführen ist. Das größte Dilemma ist nämlich eine beinahe babylonische Begriffsverwirrung, die wir deshalb gleich beseitigen werden. Die Earned Value Analyse ist ein Instrument zur –objektiven Ermittlung des Projektstatus bzgl. der drei Steuergrößen Leistung Kosten und Termine –zur Feststellung, warum kosten und/oder Termine vom Plan abweichen, –zur Ermittlung der zu erwartenden Kostenabweichung und –zur Ermittlung der zu erwartenden Terminabweichung. Die folgende Darstellung lehnt sich eng an das Arbeitsbuch Projektmanagement von Walter Gruber an

84 Copyright: Dr. Klaus Röber 84 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Earned Value Analyse – Begrifflichkeit (1) Die Terminologie ist für viele an der EVA Interessierte sehr verwirrend, da bunt gemischt meist englische Ausdrücke verwendet werden, deren Bedeutung sich nicht unmittelbar aus der Übersetzung erschließt. Für jeden deutschen Begriff existieren meist mehrere englische Synonyme. BegriffSynonymErklärung Fertigstellungswert (Ertragswert, erbrachte Leistung) - Earned Value (EV) - Budgeted Cost of Work Performed (BCWP) Bisher erbrachte Leistung, bewertet anhand der dem Fertigstellungsgrad entsprechenden Plankosten Istkosten-Burned Value -Actual Cost of Work Performed (ACWP) Bisher tatsächlich angefallene kosten Plankosten-Planned Value -Performance Measurement Baseline (PMB) Bis zum Berichtszeitpunkt geplante Kosten KostenabweichungCost Variance (CV)Differenz zwischen Fertigstellungswert und Istkosten LeistungsabweichungSchedule Variance (SV)Differenz zwischen Fertigstellungs- wert und Plankosten

85 Copyright: Dr. Klaus Röber 85 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Earned Value Analyse – Begrifflichkeit (2) BegriffSynonymErklärung KostenverhältnisCost Performance Index (CPI)Verhältnis von Fertigstellungswert und Istkosten: Effizienz der eingesetzten Mittel TerminverhältnisSchedule Performance Index (SPI)Verhältnis von Fertigstellungswert und Plankosten: Zeitplankennzahl Voraussichtliche Gesamtkosten Cost-at-Completion (CAC)Aufgrund der EVA geschätzte Gesamtkosten (Berechnung: gesamte Plankosten x (Istkosten/Fertigstellungswert)) Voraussichtliche RestkostenCost-to-Completion (CTC)Aufgrund der EVA geschätzte Restkosten (Berechnung: voraussichtliche Gesamtkosten – Istkosten) Voraussichtliche GesamtdauerTime-at-Completion (TAC)Aufgrund der EVA geschätzte Gesamtdauer (Berechnung: Plankosten/Fertigstellungswert) Voraussichtliche RestdauerTime-to-Completion (TTC)Aufgrund der EVA geschätzte Restdauer (Berechnung: voraussichtliche Gesamtdauer – Istdauer)

86 Copyright: Dr. Klaus Röber 86 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Voraussetzungen für die Anwendung der EVA Als Ergebnis der Projektplanung bzw. des Projektcontrollings müssen folgende Werte feststehen: –der geplante Aufwand pro Aktivität und Arbeitspaket (anzustreben ist dabei, dass die geplanten Aktivitäten eine durchschnittliche Dauer von weniger als einem Berichtszeitraum haben) –der gesamte Projektaufwand (BAC = Budget at Completion) –der über alle Aktivitäten kumulierte geplante Aufwand (Cost Baseline) pro Berichtszeitraum (Kontrollperiode oft 1 Monat) –der tatsächlich geleistete Aufwand pro vergangener Kontrollperiode Nur wenn eine solche Planung bei Änderungen konsequent fortgeschrieben wird (Änderungsmanagement), kann die Baseline als tatsächliche Basis der Fortschrittskontrolle angenommen werden. Kosten oder Aufwand: –Aufwand ist immer dann die verwendete Einheit, wenn es vornehmlich auf die Kontrolle der Termine ankommt und wenn alle Ressourcenkostensätze in der gleichen Größenordnung liegen. Dies ist oft bei IT-Projekten der Fall. –Kosten in Währungseinheiten evtl. auch zusätzlich zu Aufwandsbetrachtungen werden dann verwendet, wenn der Fokus der Kontrolle auf einem Projektbudget liegt, relevante Unterschiede bei den Personalkosten vorliegen oder hohe Kostenanteile nicht als Personalaufwand anfallen

87 Copyright: Dr. Klaus Röber 87 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Der Fertigstellungswert Dr. Angermeier bemerkt dazu: Um nun eine Frage nach dem Projektstatus beantworten zu könne, wurde eine Größe definiert, mit der kein Buchhalter etwas anfangen kann, die aber den Schlüssel für das Projektcontrolling darstellt. Wir wollen wissen, was wir bis zu einem bestimmten Tag erreicht haben. Die Antwort darauf gibt der sog. Earned Value (PMBOK Guide), zu deutsch Fertigstellungswert (DIN 69903). Hinter diesem Begriff verbirgt sich etwas sehr Einfaches: Der FW ist in seiner Höhe identisch mit den geplanten Kosten. Er ist aber nicht dem geplanten Starttermin des Arbeitspakets, sondern seinem tatsächlichen Abschlusstermin zugeordnet. Die deutsche Bezeichnung Fertigstellungswert drückt es anschaulich aus: Earned Value ist der Wert der fertig gestellten Arbeiten. Der entscheidende Ansatz des Earned Value Management besteht also darin, die Arbeit im Projekt nicht nach dem tatsächlichen Aufwand, sondern nach dem verfügbaren Budget zu bewerten. Dies führt dazu, dass es für die Projektleitung attraktiv ist, ein Arbeitspaket mit weniger Ressourcenaufwand zu bewältigen als ihm zur Verfügung steht. Das Arbeitspaket erhält trotzdem die gesamten geplanten kosten als Fertigstellungswert honoriert. Andererseits werden Mehraufwände nicht honoriert. Der Fertigstellungswert kann durch Mehrarbeit nicht gesteigert werden, nur die Istkosten erhöhen sich weiter.

88 Copyright: Dr. Klaus Röber 88 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Varianten der EVA: Berechnung des Fertigstellungsgrads Im Beispiel und in der Übung wird die relative Methode zur Ermittlung des Fertigstellungsgrads angewandt. Dr. Angermeier bemerkt dazu : Die strengste Art, den Fertigstellungswert zu bestimmen, ist die 0/100 Methode. Bei ihr rechnen wir erst mit Abschluss des jeweiligen Arbeitspakets 100% der budgetierten Kosten zum Fertigstellungswert hinzu. In der Literatur über den Earned Value nehmen die vielfältigen Methoden breiten Raum ein, mit denen man der Fertigstellungsgrad eines laufenden Arbeitspakets abschätzt. Da gibt es neben der 0/100 Methode die 20/80 Methode, die 50/50 Methode, die Berechnung nach Menge oder die bloße Schätzung des Fertigstellungswerts. Dies ergibt jedoch nur eine buchhalterische Sicht auf das Projekt. Im Projektmanagement gilt die Devise: Was nicht da ist, zählt nicht. Ein Tor ist erst dann ein Tor, wenn der Ball drin ist. Ein 99% Tor, bei dem der Torwart den Ball auf der Linie stoppt, ist eben kein Tor. Ein Arbeitspaket ohne fertig gestelltes Ergebnis hat auch keinen Fertigstellungswert. Wenn ein Projektleiter nicht damit zufrieden ist, dass der FW eines Projekts nur bei 80% liegt, muss er Arbeitspakete schneller und kostengünstiger abschließen. Das ist wichtig, weil sich Kosten treibende und verzögernde Faktoren später ohnehin einstellen werden. Gut, wenn er vorgesorgt hat.

89 Copyright: Dr. Klaus Röber 89 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Wie wird eine EVA durchgeführt? 1.Ermittlung der zur Durchführung der Earned Value Analyse benötigten folgenden Werte: -Fertigstellungswert -Plankosten -Istkosten 2.Vergleich des Fertigstellungswerts mit den Istkosten zur Ermittlung der Terminsituation 3.Vergleich des Fertigstellungswerts mit den Plankosten zur Ermittlung der Kostensituation 4.Berechnung der erwarteten Abweichungen bis Projektende Hinweis: Die Beispiele und Übungen enthalten wegen der Übersichtlichkeit nur wenige Arbeitspakete. Bei einem realen Projekt führt man die EVA erst ab einer Größe von ca. 50 Vorgängen durch (s. Dr. Angermeier)

90 Copyright: Dr. Klaus Röber 90 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Schritt 1: Berechnung der grundlegenden Daten Der erste Schritt besteht in der Ermittlung von –Fertigstellungswert –Istkosten und –Plankosten Der Fertigstellungswert bezeichnet die dem Fertigstellungsgrad des Projekts entsprechenden Kosten. Dabei bezieht sich der Fertigstellungswert immer auf die ursprüngliche Kostenplanung –Wenn beispielsweise die Plankosten für ein Projekt Euro sind und das Projekt einen Fertigstellungsgrad von 50% ausweist, errechnet sich ein Fertigstellungswert von ( x 50%) –Wenn das Projekt beendet ist, die tatsächlichen Kosten aber Euro betragen, ergibt sich dennoch nur ein Fertigstellungswert von ( x 100%) Die Istkosten (tatsächlich zum Berichtszeitpunkt für das Projekt ausgegebene Kosten) gehen aus der Projektbuchführung hervor. Die Plankosten bezeichnen die Kosten, die laut Projektplan bis zum Berichtszeitpunkt ausgegeben werden sollten. Es handelt sich dabei um eine reine Zeitpunktbetrachtung, unabhängig vom leistungsmäßigen Projektfortschritt.

91 Copyright: Dr. Klaus Röber 91 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Schritt 2: Vergleich von Fertigstellungswert mit den Istkosten Aus dem Verhältnis von Fertigstellungswert und Istkosten geht die Kostensituation im Projekt hervor. Es sind drei Situationen möglich: –Fertigstellungswert > Istkosten das Projekt liegt zum Berichtszeitpunkt kostenmäßig besser als geplant. Prognose: Das Projekt wird günstiger fertig gestellt als geplant. –Fertigstellungswert = Istkosten das Projekt liegt kostenmäßig exakt im Plan. Prognose: Das Projekt wird gemäß Kostenplan fertig gestellt –Fertigstellungswert < Istkosten das Projekt liegt zum Berichtszeitpunkt kostenmäßig schlechter als geplant. Prognose: Das Projekt kostet mehr als geplant. Vorsicht: Wenn der Fertigstellungswert unter den Istkosten liegt, sollten Sie nicht sofort zu Gegenmaßnahmen greifen, sondern erst Schritt 3 vollziehen!

92 Copyright: Dr. Klaus Röber 92 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Schritt 3: Vergleich von Fertigstellungswert mit Plankosten Aus dem Verhältnis von Fertigstellungswert und Plankosten geht die Terminsituation im Projekt hervor. Es sind wieder drei Situationen möglich: –Fertigstellungswert > Plankosten das Projekt lief bis zum Berichtszeitpunkt schneller als geplant. Prognose: Das Projekt wird schneller fertig gestellt als geplant –Fertigstellungswert = Plankosten das Projekt liegt zum Berichtszeitpunkt exakt im Terminplan. Prognose: Das Projekt wird termingerecht fertig gestellt werden –Fertigstellungswert < Plankosten das Projekt lief bis zum Berichtszeitpunkt langsamer als geplant. Prognose: Das Projekt wird nicht termingerecht fertig gestellt werden können.

93 Copyright: Dr. Klaus Röber 93 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Traumkonstellation versus Albtraumkonstellation Erst aus der Kombination von Schritt 2 und Schritt 3 sind zuverlässige Aussagen über die Gesamtsituation im Projekt möglich: –Fertigstellungswert > Istkosten und Plankosten für das Projekt wurden bisher weniger Kosten aufgewandt als geplant und es liegt im Zeitplan besser als geplant – die Traumkonstellation –Fertigstellungswert < Istkosten und Plankosten für das Projekt wurden bisher mehr Kosten aufgewandt als geplant und es liegt im Zeitplan schlechter als geplant – die Albtraumkonstellation

94 Copyright: Dr. Klaus Röber 94 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Richtig interpretieren! Der Wert der EVA erweist sich in den folgenden Konstellationen: –Istkosten > Fertigstellungswert > Plankosten das Projekt hat bisher mehr gekostet als geplant, es ist allerdings im Terminplan weiter als geplant. Im Klartext: Für mehr Leistung als geplant ist mehr Geld ausgegeben worden als geplant. Wenn positive und negative Abweichung etwas dieselbe Größenordnung annehmen, braucht der Projektleiter keine Maßnahmen zu ergreifen. Das Projekt wird schneller als geplant, aber im Rahmen der Kosten beendet. –Istkosten < Fertigstellungswert < Plankosten das Projekt liegt kostenmäßig günstiger als geplant, es läuft allerdings langsamer als geplant. Im Klartext: Für weniger Leistung als geplant wurde weniger Geld ausgegeben als geplant. Wenn positive und negative Abweichungen etwa dieselbe Größenordnung haben, wird das Projekt zwar den geplanten Termin überschreiten, aber im Kostenrahmen bleiben. Der Projektleiter muss Maßnahmen ergreifen, um den Termin zu halten.

95 Copyright: Dr. Klaus Röber 95 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Schritt 4: Abweichungen ermitteln Um festzustellen, ob positive und negative Abweichungen etwa dieselbe Größenordnung annehmen, müssen exakte Berechnungen gemacht werden: – Kostenabweichung: Fertigstellungswert – Istkosten, zeigt die momentane Kostenabweichung an. Wenn das Projekt ab dem Berichtszeitpunkt wieder planmäßig verläuft, es sich also um eine einmalige Störung handelt, steht am Projektende diese Kostenabweichung zu Buche. Bei einer vermutlich einmaligen Störung ist die Kostendifferenz das Rationalitätskriterium für die erforderlichen Gegenmaßnahmen. –Leistungsabweichung: Fertigstellungswert – Plankosten, zeigt die momentane Leistungsabweichung an. –Kostenverhältnis: Fertigstellungswert/Istkosten, zeigt die Effizienz der bisher aufgewandten Kosten an. Ein Wert > 1 die erbrachte Leistung ist mehr wert als sie gekostet hat (z. B. 1,1 es ist effizienter gearbeitet worden als geplant) Ein Wert < 1 die erbrachte Leistung ist weniger wert als sie gekostet hat (z.B. 0,8 es ist uneffizienter gearbeitet worden als geplant) Vorsicht: Das Kostenverhältnis kann auch bei anhaltendem Trend nicht zur Prognose von Kostenüber- oder -unterschreitungen heran gezogen werden.

96 Copyright: Dr. Klaus Röber 96 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel (1) Die folgende Tabelle zeigt die Daten eines Projekts (Gesamtdauer ist ein Jahr – vom 1.1. bis zum , Berichtszeitpunkt ist der : ArbeitspaketPlankosten je Arbeitspaket Plankosten zum Berichtszeitpunkt IstkostenRestkosten A B C D E F Insgesamt

97 Copyright: Dr. Klaus Röber 97 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel (2) Aus den vorliegenden Daten muss der Fertigstellungswert des Projekts berechnet werden. Dazu ist als Zwischenschritt die Ermittlung des Fertigstellungsgrads aller Arbeitspakete erforderlich: –Der Fertigstellungsgrad errechnet sich aus dem Verhältnis der geschätzten Restkosten zu den Gesamtkosten (Istkosten + Restkosten): Restkosten von 0 führen zu einem Fertigstellungsgrad von 100% Istkosten von 0 führen zu einem Fertigstellungsgrad von 0% –Der Fertigstellungswert ergibt sich aus der Multiplikation des Fertigstellungsgrads mit den ursprünglichen Plankosten für das gesamte Arbeitspaket: Der Fertigstellungswert kann also maximal den Wert der Plankosten erreichen Um den Fertigstellungswert des gesamten Projekts zu bestimmen, müssen die einzelnen Werte aller Arbeitspakete addiert werden.

98 Copyright: Dr. Klaus Röber 98 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel (3) Im Beispiel ergeben sich die folgenden Fertigstellungsgrade der Arbeitspakete und daraus die Fertigstellungswerte: ArbeitspaketPlankosten je Arbeitspaket Plankosten zum Berichts- zeitpunkt IstkostenRestkostenFertigstel- lungsgrad Fertigstel- lungswert A % B % C %5 000 D %6 480 E %3 060 F %0 Insgesamt

99 Copyright: Dr. Klaus Röber 99 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel (4) Es ergeben sich folgende Werte: Kostendifferenz (Cost Variance) von – Interpretation: Wenn es sich um eine einmalige Störung handelt und nach dem aktuellen Berichtszeitpunkt das Projekt planmäßig verläuft, werden die geplanten kosten um rund überschritten. Aus der folgenden Grafik geht jedoch hervor, dass es sich nicht um eine einmalige Störung, sondern um einen anhaltenden Trend handelt. Aus der Grafik geht die Kostenabweichung aus der vertikalen Differenz zwischen Fertigstellungswert und Istkosten hervor. Leistungsabweichung (Schedule Variance) von Der momentane Terminverzug ist aus der Grafik zu bestimmen, indem gefragt wird, wann der momentane (Stand: Ende Juli) Fertigstellungswert erreicht hätte sein sollen (die horizontale Lücke zwischen Plankosten und Fertigstellungswert). Ein signifikanter Terminverzug ist nicht erkennbar. Das Kostenverhältnis beträgt 0,85 (40 790/ ) bisher wurde uneffizient gearbeitet: Für jeden ausgegebenen Euro wurde nur ein Wert von 0,85 Euro erstellt. Bei stabilem Trend betragen die geschätzten Gesamtkosten ( x (48 000/40 790)). Das entspricht einer Kostenüberschreitung von 17,7% ((48 000/40 790) – 1). Bei stabilem Trend ist mit einer Gesamtdauer von 1,005 Jahren (1 x (41 000/40 790)) zu rechnen.

100 Copyright: Dr. Klaus Röber 100 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Beispiel (5): Grafik Kosten Zeit J F M A M J J A S O N Plankosten Istkosten FW

101 Copyright: Dr. Klaus Röber 101 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Integrierte Betrachtung Die integrierte Betrachtung der drei Werte –Fertigstellungswert –Plankosten und –Istkosten Erleichtert die Interpretation von Abweichungen. In der folgenden Tabelle sehen Sie die Werte von drei Projekten (Laufzeit je 12 Monate, Stichtag ist der ProjektGesamte Plankosten Plankosten zum Stichtag IstkostenFertigstellungs wert

102 Copyright: Dr. Klaus Röber 102 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Interpretation In Projekt 1 errechnet sich bei isoliertem Plan-/Ist-Vergleich eine gegenwärtige Kostenüberschreitung von oder 20%. Bei gleich bleibendem Trend wäre danach mit einer Kostenüberschreitung von 20% zu rechnen. Die integrierte Betrachtung zeigt aber, dass nicht nur um 20% mehr Kosten verursacht wurden, sondern auch um 20% mehr Leistung erbracht wurde. Die Aussage der EVA ist hier, dass das Projekt nach bereits 10 Monaten zu den geplanten Kosten fertig gestellt wird. In Projekt 2 errechnet sich bei isoliertem Plan-/Ist-Vergleich eine Kostenunterschreitung von 20%. Bei gleich bleibendem Trend wäre demnach mit einer Kostenunterschreitung von 20% zu rechnen. Die integrierte Betrachtung zeigt aber, dass die Kostenunterschreitung auf eine ungeplant niedrige Leistung zum Stichtag zurück zu führen ist. Die Aussage der EVA ist hier, dass das Projekt gemäß den geplanten Kosten fertig gestellt wird, aber 3 Monate länger dauern wird als geplant. In Projekt 3 errechnet sich bei isoliertem Plan-/Ist-Vergleich ein planmäßiger Verlauf. Die integrierte Betrachtung zeigt aber, dass bisher weniger geleistet wurde als geplant. Bei gleich bleibendem Trend ist die Aussage der EVA, dass die Kosten um 25% überschritten werden und die gesamte Projektdauer 15 Monate sein wird.

103 Copyright: Dr. Klaus Röber 103 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung zur EVA (1) In der folgenden Tabelle sehen Sie die Daten eines Projekts zum Berichtszeitpunkt. Die geplante Projektdauer ist 15 Monate. Der Berichtszeitpunkt ist am Ende des 6. Monats. Führen Sie aufgrund dieser Angaben eine Earned-Value – Analyse durch. Unterstellen Sie, dass der bisherige Trend anhalten wird: Welche Maßnahmen sollten Sie ergreifen? Jeder arbeitet allein Zeit 30 Minuten

104 Copyright: Dr. Klaus Röber 104 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Übung zur EVA (2) ArbeitspaketPlankosten je Arbeitspaket Plankosten zum Berichtszeitpunkt IstkostenRestkosten

105 Copyright: Dr. Klaus Röber 105 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Lösung (1) Arbeits paket Plankosten je AP Plankosten zur Zeit t IstkostenRestkostenFertigstellungs grad Fertigstellungs wert % % % % % % % Gesamt

106 Copyright: Dr. Klaus Röber 106 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Lösung (2) Der Plan-/Ist-Vergleich zeigt eine Überschreitung der geplanten Kosten um oder rund 17%. Die EVA deckt die tatsächliche Situation auf: –Eine Kostenabweichung ist nicht festzustellen – der Fertigstellungswert deckt exakt die Istkosten. –Dieses Ergebnis wird durch die Berechnung der voraussichtlichen Gesamtkosten bestätigt: ges,. Plankosten x (Istkosten/FW) = –Auch das Kostenverhältnis von 1 (FW/Istkosten) zeigt, dass für jede eingesetzte Geldeinheit genau der entsprechende Gegenwert erstellt wurde – es wurde effizient gearbeitet. –Die Terminabweichung ist positiv: FW – Plankosten (t) = Das heißt, das Projekt läuft sehr viel schneller als geplant. Die über den Plankosten liegenden Istkosten sind allein auf einen schnelleren Projektfortschritt zurück zu führen. –Die Berechnung der gesamten Projektdauer ergibt 12,85 Monate (geplante Dauer x (Plankosten/FW), während 15 Monate geplant waren. Das Projekt wird also mehr als zwei Monate früher als geplant fertig gestellt werden! Entgegen den ersten Annahmen brauchen überhaupt keine Gegenmaßnahmen gegen die (nur scheinbare) Kostenüberschreitung ergriffen werden.

107 Copyright: Dr. Klaus Röber 107 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Zusammenfassende Beurteilung der EVA (1) (Dr. Angermeier) Managen anstatt Erbsen zählen –Earned Value Management kann vom Rechenvorgang her sehr einfach gestaltet werden. Eine einfache Tabellenkalkulation reicht völlig aus. Es kommt vielmehr darauf an, dass wir bereit sind, das Konzept eines ergebnisorientierten Controllings zu übernehmen und nicht nach der letzten Kommastelle zu suchen. Der Earned Value muss dadurch wachsen, dass das Projektteam Arbeitspakete abschließt, und nicht dadurch, dass es sie anfängt. Aufgaben sofort erledigen –Was für das individuelle Zeitmanagement gilt, trifft auch im Projektmanagement zu. Ein Projekt kommt nur voran, wenn Tätigkeiten nicht verschoben werden und klare, eindeutige Terminvorgaben besitzen. Bereits bei der Terminplanung sind daher die Arbeitspakete zu ihrem frühest möglichen Zeitpunkt einzuplanen. Puffer gehören immer in Fahrtrichtung. Schließlich ist auch der Airbag vor dem Fahrer, nicht hinter ihm. Die Earned Value Berechnung nach dem vorgestellten Schema belohnt die Fertigstellung und sorgt dafür, dass die Puffer nach Möglichkeit nicht in Anspruch genommen werden. Es gibt keinen Grund mehr, eine Arbeit mit dem Argument Wir haben je noch so viel Zeit zu verschieben. Projektstrukturierung in keine Arbeitspakete –Setzen Sie Earned Value Management ein, sollten Sie die Arbeitspakete so klein wie möglich wählen. Als Faustregel für kostenkritische Projekte gilt eine maximale Arbeitspaketgröße von bis zu 5% des Projektbudgets. Bei teriminkritischen Projekten sollte die Dauer nicht mehr als 5% der Projektdauer betragen.

108 Copyright: Dr. Klaus Röber 108 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Zusammenfassende Beurteilung der EVA 2) Vereinbarte Berichtszeitpunkte –Sobald der Terminplan fertig ist, sollten wir die Berichtszeitpunkte festlegen. Den ersten Berichtszeitpunkt sollten wir frühestens auf einen Termin nach Ablauf von 10 Arbeitspaketendterminen legen. Je nach Projektverlauf setzen wir dann die weiteren Berichtszeitpunkte. Sinnvoll sind Termine, vor denen Arbeitspakete abgeschlossen sein sollen. Obligatorische Stichtage sind alle Meilensteine und Phasenabschlüsse. Der Blick zurück –Wie beim Bergsteigen hat der Blick zurück erst Sinn, wennman ein Stück gegangen ist. Gerade am Anfang sollten wir das Projekt vorantreiben. Während der Startphase steht keine belastbare Datengrundlage zur Verfügung. Sobald das Projekt läuft, liefert die Projektbewertung mit der EVA aber eine wichtige Kennzahl, um die subjektiven Einschätzungen der Projektbeteiligten zu objektivieren. So können wir beispielsweise optimistische Prognosen der Meilensteintrendanalyse mit den Kennzahlen der EVA kritisch hinterfragen:Wie wollen wir die Meilensteintermine einhalten, wenn unser Terminverhältnis (Schedule Performance Index) nur bei 30% liegt? Der Blick nach vorn –Mit Hilfe von Terminverhältnis (SPI) und Kostenverhältnis (CPI = Cost Performance Index) lassen sich auch Prognosen erstellen. Dafür sind aber deutlich aufwändigere Rechnungen erforderlich. Meilensteintrendanalyse und Kostentrendanalyse sind zunächst die einfachsten Methoden für die Prognose. Sie werden durch den Blick zurück objektiviert. Eine ausführlich Behandlung des Earned Value Managements einschließlich der Prognosefunktionen finden Sie bei Alan Webb: Using Earned Value. A Project Managers Guide, 2003 Gower (UK)

109 Copyright: Dr. Klaus Röber 109 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Zusammenfassende Beurteilung der EVA (3) Fazit: Kosten- und schonungslose Transparenz für Mutige Sind SPI und CPI nur Zahlenspielerei und Verwaltungsaufwand oder unverzichtbare Kenngrößen des Projektfortschritts? Es kommt darauf an, wie man sie einsetzt. Der tatsächliche Aufwand ihrer Ermittlung ist minimal und lässt sich mühelos mit einer Exel-Tabelle bewerkstelligen. Aber ihre Aussage kann so schmerzhaft sein wie ein Zahnarztbesuch. Deshalb beginnen viele Projektmanager unter dem Vorwand, ein möglichst realistisches Bild ihres Projekts zu erzeugen, mit den unterschiedlichsten Rechenübungen. Dadurch schaffen sie schnell einen Verwaltungsaufwand, der den Istzustand des Projekts mehr vernebelt als erhellt. Wer aber gleich das hier geschilderte konsequente Verfahren wählt, hat fast keinen Aufwand und verfügt über ein Frühwarnsystem, das zu einem Zeitpunkt Alarm schlägt, an dem noch alles steuerbar ist.

110 Copyright: Dr. Klaus Röber 110 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Definition von Steuerungsmaßnahmen bei Planabweichungen (1) Werden bei der Auswertung der Ist-Daten durch die beschriebenen Instrumente mögliche Probleme bei der weiteren Projektabwicklung bzgl. Kosten, Aufwand, Terminen oder Produktqualität erkannt, müssen Gegenmaßnahmen getroffen werden. Folgende Maßnahmen zur Projektsteuerung bei drohendem Terminverzug sind möglich: –Verkürzung von Dauern Termin bestimmender Vorgänge durch Erhöhung der verfügbaren Kapazität (Überstunden, Fremdvergabe, Änderung der Prioritäten usw.) Höhere Effizienz (externer Spezialist, Schulung…) bei der Abwicklung der Aktivitäten Verminderung des Leistungsumfangs von Aufgaben oder des gesamten Projekts –Änderung der Reihenfolge durch Überlappung oder Parallelisierung bislang sequentieller Arbeitspakete (Kapazitäten beachten!). Dies kann z. B. durch negative Zeitabstände im Netzplan (s. Modul Netzplanrechnung) erfolgen –Verschieben von Terminen, notfalls des Projektendtermins

111 Copyright: Dr. Klaus Röber 111 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Definition von Steuerungsmaßnahmen bei Planabweichungen (2) Bei einer drohenden Aufwands- oder Kostenüberschreitung verbleiben als mögliche Steuerungsmaßnahmen –Höhere Effizienz bei der Auftragsabwicklung oder die –Verminderung des Leistungsumfangs (z. B. in Form eines Release- Konzepts, bei dem die volle Funktionalität erst in späteren Ausbaustufen erreicht wird) Wesentlich für die Beurteilung von Steuerungsmaßnahmen sind zwei Faktoren: –Kosten – Was kostet die Maßnahme an Zeit, Geld und Aufwand? –Wirkung – Welche Auswirkungen hat eine Maßnahme auf Termine, Budget oder Produktqualität? Um die richtige Maßnahme aus allen möglichen auszuwählen, müssen diese beiden Faktoren gegeneinander abgewogen werden. Ein Patentrezept dafür gibt es aber leider nicht!

112 Copyright: Dr. Klaus Röber 112 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Projekt-Controlling-Bericht = Zahlen über Termine Aufwand Kosten... für Plan Ist Abweichung Hochrechnung Projekt-Controlling-Bericht = Zahlen über Termine Aufwand Kosten... für Plan Ist Abweichung Hochrechnung Projekt-Change-Request = Dokumentation jeder Änderung mit Auswirkung auf Termine Aufwand Kosten Risiko Projekt-Change-Request = Dokumentation jeder Änderung mit Auswirkung auf Termine Aufwand Kosten Risiko Projekt-Status-Bericht = Kommentierung / Interpretation der Abweichungen zu Terminen Aufwand Kosten Fertigstellung Risiken Projekt-Status-Bericht = Kommentierung / Interpretation der Abweichungen zu Terminen Aufwand Kosten Fertigstellung Risiken Basis Projektplan ! Zusammenhang der Berichte in der Projektsteuerung

113 Copyright: Dr. Klaus Röber 113 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Ergebnistyp Projekt-Controlling-Bericht: Inhalte Ein periodischer Report, der für das gesamte Team die folgenden Aspekte aufzeigt: –geplante, erreichte und zukünftige Aufwände/Kosten –geplante, erreichte und zukünftige Termine –Abweichungen zwischen geplanten und erbrachten Aufwänden/Kosten –Abweichungen zwischen geplanten und zukünftigen Terminen (Vorschau, Trend) Dieser Bericht wird benutzt um die Projektarbeit gegenüber den Planwerten zu managen.

114 Copyright: Dr. Klaus Röber 114 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung TermincontrollingPhase VorstudieAnalyseDesignRealisierungEinführung Planung: Laufzeit in Wochen16,025,030,010,015,0 Endtermin Ist-Werte: Start in KW Letzte Meldung in KW Fertigstellung in % Laufzeit in Wochen17,031,011,00,0 Endtermin offen Analyse/Hochrechnung: Abweichung in Wochen-1,0-6,019,010,015,0 Hochrechnung Laufzeit:17,031,055,010,015,0 Neue Abweichung-1,0-6,0-25,00,0 Neuer Endtermin Projekt-Controlling-Bericht: Beispiel Termincontrolling Zahlen

115 Copyright: Dr. Klaus Röber 115 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Projekt-Controlling-Bericht: Beispiel Termincontrolling Grafik

116 Copyright: Dr. Klaus Röber 116 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung AufwandscontrollingPhase VorstudieAnalyseDesignRealisierungEinführung Planung: Aufwand15,045,060,030,0 Ist-Werte: Aufwand30,035,014,30,0 Abweichung-15,010,045,830,0 Fertigstellung in % Analyse/Hochrechnung: Aufwand hochgerechnet30,035,071,330,0 Abweichung-15,010,0-11,30,0 Projekt-Controlling-Bericht: Beispiel Aufwandscontrolling intern

117 Copyright: Dr. Klaus Röber 117 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung AufwandscontrollingPhase Externe12345 VorstudieAnalyseDesignRealisierungEinführung Planung: Aufwand Plan25,050,045,05,0 Ist-Werte: Aufwand Ist27,556,013,00,0 Abweichung-2,5-6,032,05,0 Fertigstellung in % Analyse/Hochrechnung: Aufwand hochgerechnet27,556,065,05,0 Abweichung-2,5-6,0-20,00,0 Projekt-Controlling-Bericht: Beispiel Aufwandscontrolling Externe

118 Copyright: Dr. Klaus Röber 118 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Planaufwand intern Istaufwand intern Planaufwand extern Istaufwand extern Beispiel für Aufwandscontrolling

119 Copyright: Dr. Klaus Röber 119 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Integriertes Änderungsmanagement Aufgabe des integrierten Änderungsmanagements ist die Steuerung der Änderungen, die im Projektverlauf auftreten. Es befasst sich –mit der Beeinflussung der Faktoren, die Änderungen verursachen, um sicher zu stellen, dass diese Änderungen von Vorteil sind –mit dem Feststellen erfolgter Veränderungen und –dem Umgang mit tatsächlichen Veränderungen, falls und wenn sie auftreten (PMBOK) Änderungen im Projekt werfen Probleme auf, da sie –zu Terminverzug führen können –zu Kostensteigerungen führen können und –negativ auf die Qualität wirken können. Änderungen sind nie völlig zu vermeiden; eine umsichtige Projektvorbereitung und –planung kann den Änderungsumfang nur vermindern. Häufig werden Änderungen aber notwendig, um neuen Marktanforderungen oder neuen technischen Möglichkeiten gerecht werden zu können oder wegen Gesetzesänderungen. Änderungen sind somit als Chance zu begreifen, da sie i. d. R. zu einer Verbesserung des Projektgegenstands führen.

120 Copyright: Dr. Klaus Röber 120 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Ablauf einer Änderung (Change Request) 1.Beantragung der Änderung - Im formellen Antrag sind der Anlass, die erwarteten Auswirkungen, die erwarteten Auswirkungen auf Termine, kosten, Qualität sowie auf andere Teile des Projekts anzugeben. 2.Ermittlung der Auswirkungen und Klassifizierung - Das Steuerungsgremium bewertet die geplanten Änderungen hinsichtlich ihrer Auswirkungen und Dringlichkeit 3.Genehmigung – Auf der Grundlage der Bewertung wird der Änderungsantrag genehmigt, abgelehnt oder bei gravierenden Änderungen wichtige Stakeholder hinzu gezogen. Die Entscheidung wird protokolliert. 4.Anweisung der Änderung - Die Genehmigung geht dem Projektleiter und den betroffenen Bereichen zu. 5.Durchführung der Änderung 6.Dokumentation der Änderung

121 Copyright: Dr. Klaus Röber 121 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Genehmigte Change- Requests und Planänderungen Projektauftrag Projektplan Projekt-Controlling Bericht Projekt-Status- Bericht Projekt-Abschluss Bericht Projekt-Change. Request Ergebnisse im Management-Regelkreis "Projekt"

122 Copyright: Dr. Klaus Röber 122 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Kritischer Erfolgsfaktor der Steuerung: Kontrolle des Umfangs Der Projektleiter muss von Anfang an sicherstellen, dass –alle Teammitglieder die Notwendigkeit einer rigiden Kontrolle des Projektumfangs verstehen und sich dazu verpflichten. –die Prozeduren des Änderungsmanagements befolgt werden. –eine Zunahme von Aufwand, Kosten und Terminverzögerungen nur aus genehmigten Änderungen resultieren können. –solche Kosten/Verschiebungen getrennt ausgewiesen werden und separat an den Sponsor/Auftraggeber berichtet werden. Durch Dokumentation aller potentiellen Änderungen und Erweiterungen in Change Requests kann das Team die vereinbarten Meilensteine halten (ohne dem Benutzer das Gefühl zu geben, dass seine Anforderung ignoriert wird ). Nur so bleibt das Projekt für das Management transparent und objektiv steuerbar.

123 Copyright: Dr. Klaus Röber 123 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Projekt-Change-Request / Change Order: Beispiel Projekt Change Request / Change Order (Beispiel) Request-Nr.: cr0001 Projektname: Integrierte Auftragsabwicklung Sponsor: Herr Kern, Hongkong Projektnummer: T4711 Projektmanager: Herr Meyer Teilprojekt : Teilprojekt-Nr. : Beschreibung der Änderung: Für das integrierte Auftragsabwicklungs-System war der Server in der Konzernzentrale am Standort Frankfurt geplant. Damit sollte die Integration zum Terminüberwachungs- und Informationssystem des Konzerns erleichtert werden. Der Server einschließlich der erforderlichen Netzanbindungen und der Betriebssoftware sollab am neuen Standort Berlin stehen. Begründung: Der Konzern hat sich für den neuen Standort Berlin als Konzernzentrale entschieden. Alternativen: Die Bauarbeiten und der Umzug nach Berlin kann sich u.U. verzögern.Um dieses Risiko zu vermeiden, könnte der Server in einem der Auslandsbüros aufgestellt werden. Dafür bietet sich Hongkong an, da dort das System in der ersten Stufe eingeführt wird. Nach erfolgreicher Einführung des Systems in Hongkong kann im Rahmen der Stufe 2 ( alle anderen Auslandsbüros ) der Server nach Berlin verlegt werden. Zwischenzeitlich können die rel e vanten Daten im 4-Stundentakt an das Terminüberwachungs- und Informationssystem per übertragen werden. Auswirkungen: __ K Termin __ G__ Aufwand __ G Kosten __ K Risiko (K=Keine Auswirkung, G=Geringe Auswirkungen, H=Hohe Auswirkung) Terminauswirkung: Aufwandauswirkung: Durch die zweimalige Installation des Servers, zunächst in Hongkong und später in Berlin entsteht ein Mehrau f wand von ca. 3 MM. Kostenauswirkung: Die Projekt-Kosten-werden sich durch die Änderung um ca DM erhöhen. Dies kommt zum einen durch den höheren Aufwand zustande (ca DM ) und durch die zusätzlichen Reisekosten (ca DM). Risiko-Auswirkung: Keine. Da der Standort Berlin entschieden ist, das Datum für den Umzug aber noch unsicher ist, kann durch die Alternative das Risiko eher minimiert werden. Request: ________________________________________ _________________ Unterschrift Projektmanager Datum Genehmigung:

124 Copyright: Dr. Klaus Röber 124 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Projekt Change Report: Beispiel

125 Copyright: Dr. Klaus Röber 125 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Qualitätslenkung Im Abschnitt Projektplanung haben wir uns bereits relativ ausführlich über die Definition von Qualitätszielen und die Testplanung unterhalten. Im Rah- men der Projektausführung geht es jetzt darum sicher zu stellen, dass die Qualitätsziele erreicht werden. Wesentliche Techniken, die angewandt werden, sind für die Überprüfung der Zwischenergebnisse durch Reviews und speziell in Sonderfällen Inspektionen sowie das Testen der Programme Modultest, Funktionstest, Integrationstest, Systemtest, ggf. Lasttest, Akzeptanztest sowie bei Systemerweiterungen Regressionstest. Da es sich beim Testen um eine sehr spezielle entwicklungsnahe Tätigkeit handelt, die nicht zum Projektmanagement gehört und über die der Projektleiter nicht im Detail informiert sein muss, werden wir diese Thematik hier nicht weiter behandeln. Behandeln werden wir hingegen Reviews, Inspektionen und Walkthroughs, da hier der Projektleiter bzw. der Qualitätsbeauftragte in der Regel die Sitzung leitet und deshalb etwas über die anzuwendenden Methoden wissen muss.

126 Copyright: Dr. Klaus Röber 126 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Verschiedene Formen von Reviews +Reviews überprüfen am Ende jeder Entwicklungsphase Umfang und Qualität der Zwischenprodukte. Projektpersonal, Auftragnehmer- management und Auftraggeber entscheiden gemeinsam, ob die nächste Phase angegangen werden kann +Audits sind offizielle Reviews zur Verifikation besonders kritischer Teile durch das QS-Personal +Ziel eines Walk-Throughs ist, Problembereiche zu entdecken, sie aber erst nach Abschluß des Walk-Throughs und nach Zustimmung des Erstellers zu beheben +Peer Review entspricht dem Walk Through. Es geht dabei um eine methodische Examinierung der Ergebnisse durch sachkundige Kollegen (Peers). Ziel ist, Fehler zu finden und Bereiche, in denen Änderungen erforderlich sind +Inspection ist eine sehr formale Gruppensitzung, in der die zu inspizierende Unterlage vom Autor vorgelesen und sequentiell Wort für Wort durchgearbeitet wird

127 Copyright: Dr. Klaus Röber 127 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Reviews: Stand der Praxis (www.software-kompetenz.de) IESE (Fraunhofer Institut für experimentelles Software Engineering 1998): –Obwohl Qualitätssicherung von Software eine immer größere Rolle bei der Entwicklung einnimmt, werden die durch Fehlersuche und Fehlerbehebung entstehenden kosten innerhalb der Entwicklung auf 30-50% der Gesamtkosten geschätzt. Reviews oder Inspektionen sind eine der grundlegenden Techniken für Qualitätssicherung, da Fehler früh im Entwicklungsprozess gefunden werden und somit kosteneffektiv behoben werden können. Eine Umfrage, die das IESE durchgeführt hat, deckt den Stand der Praxis in deutschen Unternehmen bei Software Reviews auf. An der Umfrage beteiligten sich 121 Teilnehmer aus Unternehmen aller Branchen mit eigener Software-Entwicklung. –Insgesamt lässt sich feststellen, dass Reviews als Methode allgemein akzeptiert sind, wobei die einzelne Durchführung oft wenig systematisch ist. Kaum ein Anwender hat eine spezielle Schulung für Software-Reviews absolviert. Spezielle Vorgehensweisen wie Software-Inspektionen werden bei kleineren Unternehmen (< 50 Entwickler) deutlich seltener angewandt als bei großen. Die folgenden beiden Folien zeigen die Verteilung. –Nur eine kleine Zahl der Befragten gab an, mit begleitenden Messungen die Qualität der Reviews selbst zu bewerten (50% sammeln überhaupt keine Daten, 20% Aufwandsdaten, 20% Fehlerdaten). Somit besteht bei den Firmen in den meisten Fällen keine Information über die Effektivität der Maßnahmen, was eine gezielte Optimierung und Prozessverbesserung unmöglich macht.

128 Copyright: Dr. Klaus Röber 128 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Verbreitung von Reviews Von den verschiedenen Review-Typen sind die sogenannten Peer-Reviews am verbreitetsten (49,6%), es folgen Inspektionen und Walk- Throughs (20,7 bzw. 16,5%)

129 Copyright: Dr. Klaus Röber 129 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Anwendung von Review-Maßnamen je Entwicklungsphase Bei einem Vergleich bei der Anwendung fällt auf, dass die informelleren Peer Reviews insbesondere in der Analysephase eingesetzt werden. Als Gründe gegen Reviews werden vielfach Kosten (55%) und Zeitdruck (75%) genannt. Empirische Untersuchungen haben jedoch gezeigt, Das beispielsweise Inspektionen einfach zu erlernen sind und die zusätzlichen Kosten durch geringeren Aufwand bei Tests und Fehler- Behebung mehr als ausgeglichen werden (s. Quality Assurance Technologies for the EURO Conversion – Industrial Experience at Allianz Life Insurance, (www.software-kompetenz.de).

130 Copyright: Dr. Klaus Röber 130 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Reviews organisieren und durchführen ( Tilo Linz, 19/2000) Ein Review ist nichts anders als eine Gruppenarbeit durchgeführte, strukturierte Prüfung eines Reviewobjekts (meist eines Dokuments). Entscheidend dabei ist, dass die Prüfung schrittweise durchgeführt wird, unter Einhaltung eines festen Schemas. Je nach Grad der Formalisierung werden verschiedene Review-Varianten unterschieden (s. z. B. Software Inspection, Tom Gilb u. Dorothy Graham, Addison-Wesley 1993). Folgende Schritte finden sich aber immer: –1. Review-Planung –2. Review-Vorbereitung –3. Review-Sitzung –4. Review-Entscheidung Erst die beiden Aspekte Gruppenarbeit und strukturierter Ablauf zusammen garantieren Erfolg und machen aus einem simplen Gegenlesen ein systematisches Review. –Die Arbeit in der Gruppe sorgt dafür, dass die Wahrscheinlichkeit, viele Fehler zu entdecken hoch ist, weil Personen mit unterschiedlichem Blickwinkel und Know-How beteiligt werden. –Das feste Ablaufschema sorgt für die notwendige Effizienz.

131 Copyright: Dr. Klaus Röber 131 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Review-Planung Verantwortlich für die Review-Planung ist der spätere Review-Leiter oder Moderator. Er oder sie wählt das Review-Team aus, stimmt Termin und Ort der Review-Sitzung ab und kümmert sich um die Bereitstellung aller erforderlichen Unterlagen (Prüfobjekt, Prüfkriterien, sonstige Begleitdokumente). Die Prüfaufgaben werden im Team verteilt, wobei die Teilnehmer spezifische Rollen einnehmen (Moderator, Gutachter, Autor, Protokollführer). Die Zusammenstellung des Teams sollte nicht ausschließlich anhand der fachlichen Qualifikationen der Gutachter erfolgen. Trotz entsprechender Qualifikationen ist es z. B. wenig hilfreich, Mitarbeiter als Gutachter einzuteilen, die keine Zeit zur Vorbereitung haben oder die auf den Autor schlecht zu sprechen sind, dessen Dokument geprüft werden soll. Der Review-Leiter verteilt die Unterlagen zusammen mit einer schriftlichen Einladung an die Teilnehmer des Reviews. Die Einladung muss dabei so rechtzeitig ergehen, dass jeder Teilnehmer die Möglichkeit zu einer angemessenen Vorbereitung hat.

132 Copyright: Dr. Klaus Röber 132 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Review-Vorbereitung In der Vorbereitungsphase erledigen die Gutachter – jeder für sich – die eigentliche Prüfung. Sie arbeiten das Prüfobjekt durch und notieren alle Fragen, Unklarheiten oder Fehler, auf die sie dabei stoßen. Dabei ist es wichtiger, die richtigen Fragen aufzuwerfen als Lösungen vorzuschlagen. Ein kompetenter Gutachter wird nicht nur den sichtbaren Text prüfen und sich überlegen, ob das funktionieren kann und fehlerfrei ist. Er wird sich darüber hinaus fragen: –Was fehlt? –Welche Themen hat der Autor vergessen? –Welche Lösungsvarianten oder Probleme werden im Dokument nicht angesprochen? Der Review-Leiter kann den Prüfaufwand je Gutachter begrenzen, indem er in der Review-Einladung jedem Prüfer gezielt bestimmte Prüfaspekte zur Bearbeitung zuteilt, z. B. bestimmte Kapitel. Als Ergebnis erstellt jeder Gutachter seine Fragenliste. Mit dieser geht er in die Review-Sitzung.

133 Copyright: Dr. Klaus Röber 133 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Review-Sitzung Ziel der Review-Sitzung ist es, in der geplanten, vorgegebenen Zeit möglichst viele Fehler und Probleme zu identifizieren und zu einer umfassenden Beurteilung des Prüfobjekts zu gelangen. Ziel ist es nicht, Problemlösungen zu erarbeiten. Der Review-Leiter moderiert die Sitzung. Er sorgt dafür, dass –Das Prüfobjekt zügig abgearbeitet wird, –Diskussionen nicht ausufern oder gar in Streit eskalieren, –dennoch jeder Review-Teilnehmer Gelegenheit hat, seine Befunde angemessen zu präsentieren, –alle Befunde vollständig und richtig protokolliert werden. Trotz Review-Planung, schriftlicher Einladung und Vorbereitungszeit kommt es immer wieder vor, dass Review-Teilnehmer schlecht oder gar nicht vorbereitet in die Sitzung gehen. In diesem Falle hat der Review-Leiter das Recht und die Pflicht, solche Teilnehmer von der weiteren Sitzung auszuschließen. Sind zu viele Teilnehmer schlecht vorbereitet, sollte man die Sitzung absagen bzw. abbrechen.

134 Copyright: Dr. Klaus Röber 134 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Review-Entscheidung Alle im Review-Verlauf festgestellten und vom Review-Team akzeptierten Befunde werden in einer Mängelliste festgehalten. Als etwas informellere Methode ist es auch üblich, dass der Autor Mängel und Korrekturbemerkungen direkt im Prüfobjekt an den entsprechenden Stellen notiert. Entscheidend ist, dass das Review-Team anhand der Mängelliste attestiert, ob das geprüfte Dokument ohne Änderung akzeptiert werden kann (Freigabe), oder ob es der Autor überarbeiten muss. Die Punkte, an denen überarbeitet werden muss, gehen aus der Mängelliste hervor. Sind die Mängel schwerwiegend, sollte nach erfolgter Korrektur ein erneutes Review anberaumt werden (Überarbeitung mit Wiedervorlage). Bei geringfügigen Änderungen kann das Team eine Freigabe nach Änderung ohne Wiedervorlage beschließen. Diese Review-Entscheidung wird im Sitzungsprotokoll dokumentiert. Das Protokoll wird von allen Teilnehmern unterzeichnet und an alle Teilnehmer verteilt.

135 Copyright: Dr. Klaus Röber 135 Workshop: IT-Projektmanagement - Version /2004Modul: Projektsteuerung Risikoverfolgung Die Risikoverfolgung ist die Voraussetzung dafür, um im Laufe des Projekts auf Risikoereignisse reagieren zu können. Damit das Risikomanagement zusammenhängend dargestellt wird, ist dieser Punkt wieder ausgelagert als selbstständiger Modul. Verfolgung der Risikoentwicklung


Herunterladen ppt "Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version 3.0 - 07/2004Modul: Projektsteuerung Modul Projektsteuerung (-controlling) Literatur:"

Ähnliche Präsentationen


Google-Anzeigen