Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version 3.0 - 07/2004Modul:...

135
opyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

Transcript of Copyright: Dr. Klaus Röber 1 Workshop: IT-Projektmanagement - Version 3.0 - 07/2004Modul:...

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

Copyright: Dr. Klaus Röber 1Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 2Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 3Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

Berichtswesen Ein 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.

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

Copyright: Dr. Klaus Röber 4Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Unterstützungsprozesse der Projektsteuerung

Qualitätslenkung Als 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.

Risikoverfolgung Die 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.

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

Copyright: Dr. Klaus Röber 5Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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).

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

Copyright: Dr. Klaus Röber 6Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Offene Punkte-Liste: Beispiel

L.Nr. Datum Meldender offener Punkt Prio1=hoch,2=mittel3=niedrig

Termin Klärender Status0=offen1=in Arbeit2=abgeschl.

Hinweis auf Lösung

0004 6.04.1998 M. Lontke Zukünftige Abwicklung vonPrivate Label

1 4.05.1998 F. Grünauer 1

0001 19.01.1998 A. Neumann Tabelle T9MOD im R/3erstellen; Hinweis beiReparaturen auf diese Tabelle(Modifikation)

3 23.01.1998 A. Neumann 1 Modifikation der Standard-Message ”Im Auslieferungs-system nur dringendeReparaturen vornehmen”

002 19.01.1998 A. Neumann offene Transportaufträgefreigeben und transportieren

1 20.01.1998 A. Neumann 1 Alle offenen Transportetransportieren; Dummies inDummy-Auftrag einhängen

003 29.01.98 R. Heitkamp Spiegelsystem 1 R. Heitkamp 1 Ansprechpartner aus WDBeratung BASIS

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

Copyright: Dr. Klaus Röber 7Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Projektsteuerung – Regelkreis (1)

Quelle: F.P. Walder-G. Patzak, Qualitätsmanagement und Projektmanagement, Vieweg 1997

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

Copyright: Dr. Klaus Röber 8Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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)

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

Copyright: Dr. Klaus Röber 9Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 10Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 11Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 12Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 13Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 14Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 15Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 16Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

1. Beispiel für die 0/100 Methode

Arbeitspaket Geplanter Aufwand

Bisheriger Aufwand

Restlicher Aufwand

FG lt. 0/100 Methode

Kumulierter FG

A 10 PT 10 PT 0 PT 100 % 9,5 %

B 20 PT 15 PT 5 PT 0 %

C 15 PT 10 PT 10 PT 0 %

D 10 PT 0 PT 10 PT 0 %

E 30 PT 15 PT 15 PT 0 %

F 10 PT 0 PT 10 PT 0 %

G 5 PT 0 PT 5 PT 0 %

Total 100 PT 50 PT 55 PT 9,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.

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

Copyright: Dr. Klaus Röber 17Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

2. Beispiel für die 0/100 Methode

Arbeitspaket Geplanter Aufwand

Bisheriger Aufwand

Restlicher Aufwand

FG lt. 0/100 Methode

Kumulierter FG

A 10 PT 10 PT 0 PT 100 % 10 %

B 10 PT 10 PT 0 PT 100 % 20 %

C 15 PT 5 PT 10 PT 0 %

D 10 PT 2 PT 8 PT 0 %

E 20 PT 0 PT 20 PT 0 %

F 10 PT 0 PT 10 PT 0 %

G 10 PT 0 PT 10 PT 0 %

H 10 PT 0 PT 10 PT 0 %

I 5 PT 0 PT 5 PT 0 %

Total 100 PT 27 PT 73 PT 20 %

Im zweiten Beispiel kommt man mit der 0/100 Methode zu einem FG von 20 %. Zwarwird auch hier der reale Leistungsfortschritt (27 %) noch immer unterschätzt, dafür ist die Datengewinnung aber sehr einfach.

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

Copyright: Dr. Klaus Röber 18Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 19Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 20Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel für die 50/50 Methode

Arbeitspaket Geplanter Aufwand

Bisheriger Aufwand

Restlicher Aufwand

FG lt. 0/100 Methode

Kumulierter FG

A 10 PT 10 PT 0 PT 100 % 10 %

B 10 PT 10 PT 0 PT 100 % 20 %

C 15 PT 5 PT 10 PT 50 % 27,5 %

D 10 PT 2 PT 8 PT 50 % 32,5 %

E 20 PT 0 PT 20 PT 0 %

F 10 PT 0 PT 10 PT 0 %

G 10 PT 0 PT 10 PT 0 %

H 10 PT 0 PT 10 PT 0 %

I 5 PT 0 PT 5 PT 0 %

Total 100 PT 27 PT 73 PT 32,5 %

Das Beispiel zeigt, dass mit der 50/50 Methode eine bessere Annäherung an den realenLeistungsfortschritt gelingt als mit der 0/100 Methode. In diesem Falle wird der Leistungs-Fortschritt sogar überschätzt (was eigentlich nicht gut ist!).

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

Copyright: Dr. Klaus Röber 21Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 22Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 23Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel für die Step-to-Step Methode

Meilenstein Aufwand Fertigstellungsgrad

MS 1 100 PT 20 %

MS 2 50 PT 30 %

MS 3 80 PT 46 %

MS 4 120 PT 70 %

MS 5 100 PT 90 %

MS 6 (Projektende) 50 PT 100 %

Gesamt 500 PT

Bei diesem Beispiel ist beim Erreichen eines Meilensteins jeweils eine exakte Angabe desFertigstellungsgrades möglich. Wenn eine detailliertere Skalierung des Fertigstellungs-Grades erwünscht oder erforderlich ist, müssen mehr Meilensteine definiert werden.

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

Copyright: Dr. Klaus Röber 24Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel für Softwareentwicklung

Projektphase Aufwand in % Fertigstellungsgrad

Anforderungsanalyse 7 % 7 %

Systementwurf 16 % 23 %

Programmentwurf 23 % 46 %

Codierung 31 % 77 %

Systemintegration 23 % 100 %

Summe 100 %

Im Beispiel wird eine standardisierte Aufwandsverteilung für eine mittelschwere Software-Entwicklung bei mittlerer Programmgröße (32 kloc) zugrunde gelegt.

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

Copyright: Dr. Klaus Röber 25Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 26Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 27Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel für die relative Methode

Arbeitspaket Geplanter Aufwand

Bisheriger Aufwand

Restaufwand FG des Arbeitspakets

FG des Projekts

A1 15 PT 6 PT 9 PT 40 %

A2 20 PT 10 PT 10 PT 50 %

A3 15 PT 3 PT 15 PT 17 %

A4 15 PT 5 PT 15 PT 25 %

A5 25 PT 0 PT 25 PT 0 %

A6 10 PT 0 PT 10 PT 0 %

Gesamt 100 PT 24 PT 84 PT 22 %

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.

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

Copyright: Dr. Klaus Röber 28Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 29Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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?

Arbeitspaket Geplanter Aufwand Bisheriger Aufwand

A1 10 PT 10 PT

A2 15 PT 15 PT

A3 20 PT 12 PT

A4 10 PT 3 PT

A5 25 PT 10 PT

A6 10 PT 0 PT

A7 10 PT 0 PT

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

Copyright: Dr. Klaus Röber 30Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Lösung

Arbeitspaket Geplanter Aufwand

Bisheriger Aufwand

0/100 Methode

50/50 Methode

Relative Methode

A1 10 PT 10 PT 100 % 100 % 100 %

A2 15 PT 15 PT 100 % 100 % 100 %

A3 20 PT 12 PT 0 % 50 % 60 %

A4 10 PT 3 PT 0 % 50 % 30 %

A5 25 PT 10 PT 0 % 50 % 40 %

A6 10 PT 0 PT 0 % 0 % 0 %

A7 10 PT 0 PT 0 % 0 % 0 %

Gesamt 100 PT 50 PT 25 % 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.

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

Copyright: Dr. Klaus Röber 31Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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?

Arbeitspaket Geplanter Aufwand Bisheriger Aufwand Restaufwand

A1 10 PT 10 PT 0 PT

A2 15 PT 15 PT 5 PT

A3 20 PT 12 PT 10 PT

A4 10 PT 3 PT 12 PT

A5 25 PT 10 PT 20 PT

A6 10 PT 0 PT 10 PT

A7 10 PT 0 PT 10 PT

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

Copyright: Dr. Klaus Röber 32Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Lösung

Arbeitspaket Geplanter Aufwand

Bisheriger Aufwand

Restaufwand 0/100 Methode

50/50 Methode

Relative Methode

A1 10 PT 10 PT 0 PT 100 % 100 % 100 %

A2 15 PT 15 PT 5 PT 0 % 50 % 75 %

A3 20 PT 10 PT 12 PT 0 % 50 % 45,5 %

A4 10 PT 3 PT 12 PT 0 % 50 % 20 %

A5 25 PT 10 PT 20 PT 0 % 50 % 33,3 %

A6 10 PT 0 PT 10 PT 0 % 0 % 0 %

A7 10 PT 0 PT 10 PT 0 % 0 % 0 %

Gesamt 100 PT 50 PT 67 PT 10 % 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 Wahlder Methode (50/50 oder relative Methode) davon ab, ob der Projektleiter die Daten für ausreichend zuverlässig erachtet.

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

Copyright: Dr. Klaus Röber 33Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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)

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

Copyright: Dr. Klaus Röber 34Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 35Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 36Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 37Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel

Berichtszeitpunkt Plankosten Aktuelle Ist-Kosten

Geschätzte Restkosten

Sollkosten (= geschätzte

Gesamtkosten)

1 200 000 12 000 188 000 200 000

2 200 000 35 000 165 000 200 000

3 200 000 65 000 140 000 205 000

4 200 000 90 000 125 000 215 000

5 200 000 115 000 105 000 220 000

6 200 000 130 000 95 000 225 000

7 200 000

8 200 000

9 200 000

10 200 000

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

Copyright: Dr. Klaus Röber 38Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Kostentrenddiagramm für das Beispiel

230 000

225 000

220 000

215 000

210 000

205 000

200 000

195 000

190 000

185 000

180 000

Kosten

Zeit1 2 3 4 5 6 7 8 9 10

PlankostenSollkosten

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

Copyright: Dr. Klaus Röber 39Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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 25 000 Euro (12,5 %) erweitert.

– Der Projektleiter hätte spätestens nach dem vierten Berichtszeitpunkt Gegenmaßnahmen einleiten müssen.

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

Copyright: Dr. Klaus Röber 40Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 41Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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…)

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

Copyright: Dr. Klaus Röber 42Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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!

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

Copyright: Dr. Klaus Röber 43Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 44Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 45Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 46Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel

Für ein Projekt wurden vier Meilensteine definiert, der letzte repräsentiert das Planende. Die folgende Tabelle zeigt die Plan- und Istdaten:

Meilenstein Geplanter Termin

Ist-Termin Geplante Kosten

Ist-Kosten

A 1.2. 1.2. 15 000 20 000

B 1.4. 1.5. 28 000 25 000

C 1.7. 1.7. 35 000 35 000

D 1.11. 1.10. 50 000 54 000

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

Copyright: Dr. Klaus Röber 47Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Kosten-Termin-Diagramm

0 1 2 3 4 5 6 7 8 9 10 11 12

0

10 000

20 000

30 000

40 000

50 000

60 000

Kosten

Zeit

PlanIst

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

Copyright: Dr. Klaus Röber 48Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 49Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Übung: Arbeitspaket 1

Berichtszeitpunkt Plankosten Aktuelle Ist-Kosten Geschätzte Restkosten

Z1 50 000 5 000 45 000

Z2 50 000 12 000 38 000

Z3 50 000 15 000 35 000

Z4 50 000 20 000 30 000

Z5 50 000 25 000 25 000

Z6 50 000

Z7 50 000

Z8 50 000

Z9 50 000

Z10 50 000

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

Copyright: Dr. Klaus Röber 50Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Übung: Arbeitspaket 2

Berichtszeitpunkt Plankosten Aktuelle Ist-Kosten Geschätzte Restkosten

Z1 70 000 8 000 62 000

Z2 70 000 15 000 55 000

Z3 70 000 25 000 50 000

Z4 70 000 33 000 45 000

Z5 70 000 40 000 42 000

Z6 70 000

Z7 70 000

Z8 70 000

Z9 70 000

Z10 70 000

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

Copyright: Dr. Klaus Röber 51Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Übung: Arbeitspaket 3

Berichtszeitpunkt Plankosten Aktuelle Ist-Kosten Geschätzte Restkosten

Z1 30 000 0 30 000

Z2 30 000 0 30 000

Z3 30 000 2 000 28 000

Z4 30 000 5 000 25 000

Z5 30 000 9 000 21 000

Z6 30 000

Z7 30 000

Z8 30 000

Z9 30 000

Z10 30 000

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

Copyright: Dr. Klaus Röber 52Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Lösung (1)

Berichtszeit-punkt

Plankosten Aktuelle Ist-Kosten

Geschätzte Restkosten

Sollkosten (= geschätzte

Gesamtkosten)

Z1 150 000 13 000 137 000 150 000

Z2 150 000 27 000 123 000 150 000

Z3 150 000 42 000 113 000 155 000

Z4 150 000 58 000 100 000 158 000

Z5 150 000 74 000 88 000 162 000

Z6 150 000

Z7 150 000

Z8 150 000

Z9 150 000

Z10 150 000

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

Copyright: Dr. Klaus Röber 53Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Lösung (2)

0 1 2 3 4 5 6 7 8 9 10 11

140 000

145 000

150 000

155 000

160 000

165 000

170 000

Zeit

PlanIst

Bei der Ursachenanalyse ist Arbeitspaket 2 zu analysieren, da bei den anderen beidenkeine Abweichungen erkennbar sind.

Kosten

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

Copyright: Dr. Klaus Röber 54Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 55Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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?

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

Copyright: Dr. Klaus Röber 56Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 57Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel

Arbeitsbeginn Berichtszeit-punkt

Ist-Dauer Prognose Restdauer

Geplanter Endtermin

Prognose Endtermin

1.2. 7.2. 7 Tage 49 Tage 28.3. 28.3.

1.2. 14.2. 14 Tage 45 Tage 28.3. 31.3.

1.2. 21.2. 21 Tage 44 Tage 28.3. 6.4.

1.2.

1.2.

1.2.

Arbeitspaket A1 Verantwortlicher: Hr. Meier

Zum Berichtszeitpunkt 21. 2. ergibt sich: Ein zeitlicher Fertigstellungsgrad von 32,3% (Ist-Dauer)/(Ist-Dauer + Restdauer)Der Endtermin verschiebt sich vom 28.3. auf den 6.4. .

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

Copyright: Dr. Klaus Röber 58Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 59Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 60Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 61Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

MTA-Diagramm (Erläuterung s. Folgefolie)

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

Copyright: Dr. Klaus Röber 62Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 63Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Die MTA visualisiert den zeitlichen Status des Projekts

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

Copyright: Dr. Klaus Röber 64Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Typische Verläufe: Ideale Kurve

So wie auf dieser Abbildungsollten 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, alleMeilensteine werden exakt einge-halten. Leider ist ein solches MTA-ChartÄußerst unrealistisch!

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

Copyright: Dr. Klaus Röber 65Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Typische Verläufe: Die Kampfkurve (1)

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

Copyright: Dr. Klaus Röber 66Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 67Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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 derleicht geschwungene Kurvenverlauf typisch für den realistischen Idealfall.Die ersten Meilensteine werden in etwa eingehalten. Die Verantwortlichen schätzen die Termine tatsächlichjeweils zum Stichtag neu und schreibensie nicht einfach blindlings fort.Sobald ein Meilensteinverantwortlicherdie Prognose abgibt, dass sich einMeilenstein verzögert, sorgen Steue-rungsmaßnahmen dafür, dass der Trend gebrochen oder sogar umge-kehrt wird.

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

Copyright: Dr. Klaus Röber 68Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Typische Verläufe: Alarmstufe Rot (1)

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

Copyright: Dr. Klaus Röber 69Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 70Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Typische Verläufe: Die Stellvertreter- und Lobbykurve (1)

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

Copyright: Dr. Klaus Röber 71Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 72Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 73Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 74Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 75Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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ätigkeit Dauer Termin

Planung Zwei Jahre 31. 12. 02

Vorbereitung Ein Jahr 31. 12. 03

Steinbrucharbeiten Zehn Jahre 31.12. 13

Transport Zwei Jahre 31.12. 14

Errichten der Pyramide 15 Jahre 31. 12. 30

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

Copyright: Dr. Klaus Röber 76Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 77Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

Meilenstein Kürzel Termin

Planung beendet MS 1 31. 12. 02

Vorbereitung beendet MS 2 31. 12. 03

Steinbrucharbeiten beendet MS 3 31. 12. 13

Pyramide errichtet MS 4 31. 12. 18

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

Copyright: Dr. Klaus Röber 78Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Lösung (2)

Wie in der MTA zu sehen ist,hat eine Verzögerung der Stein-brucharbeiten keine Auswirkun-gen auf das Projektende.

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

Copyright: Dr. Klaus Röber 79Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 80Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Varianten: Ressourcen-Trend-Analyse und Kosten-Trend-Analyse

Berichtszeitpunkte Berichtszeitpunkte

Au

fwä

nd

e f

ür

Mei

len

stei

ne

Ko

ste

n f

ür

Me

ilen

stei

ne

1 .1 1.1

10 100

1.2 1.2

20 200

1.3 1.3

30 300

1.4 1.4

40 400

1.5 1.5

50 500

1.6 1.6

60 600

Personen-monate

TDM

Mit denselben Techniken lasse sich auch Ressourcenverbrauch und Kosten, die für dieErreichung der Meilensteine aufgewandt werden müssen, überwachen.

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

Copyright: Dr. Klaus Röber 81Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 82Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 83Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 84Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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 englischeSynonyme.

Begriff Synonym Erklä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

Kostenabweichung Cost Variance (CV) Differenz zwischen Fertigstellungswert und Istkosten

Leistungsabweichung Schedule Variance (SV) Differenz zwischen Fertigstellungs-wert und Plankosten

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

Copyright: Dr. Klaus Röber 85Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Earned Value Analyse – Begrifflichkeit (2)

Begriff Synonym Erklärung

Kostenverhältnis Cost Performance Index (CPI) Verhältnis von Fertigstellungswert und Istkosten: Effizienz der eingesetzten Mittel

Terminverhältnis Schedule 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 Restkosten Cost-to-Completion (CTC) Aufgrund der EVA geschätzte Restkosten (Berechnung: voraussichtliche Gesamtkosten – Istkosten)

Voraussichtliche Gesamtdauer

Time-at-Completion (TAC) Aufgrund der EVA geschätzte Gesamtdauer (Berechnung: Plankosten/Fertigstellungswert)

Voraussichtliche Restdauer Time-to-Completion (TTC) Aufgrund der EVA geschätzte Restdauer (Berechnung: voraussichtliche Gesamtdauer – Istdauer)

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

Copyright: Dr. Klaus Röber 86Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 87Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 88Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 89Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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)

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

Copyright: Dr. Klaus Röber 90Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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 100 000 Euro sind und das Projekt einen Fertigstellungsgrad von 50% ausweist, errechnet sich ein Fertigstellungswert von 50 000 (100 000 x 50%)

– Wenn das Projekt beendet ist, die tatsächlichen Kosten aber 150 000 Euro betragen, ergibt sich dennoch nur ein Fertigstellungswert von 100 000 (100 000 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.

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

Copyright: Dr. Klaus Röber 91Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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!

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

Copyright: Dr. Klaus Röber 92Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 93Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 94Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 95Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 96Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel (1)

Die folgende Tabelle zeigt die Daten eines Projekts (Gesamtdauer ist ein Jahr – vom 1.1. bis zum 31.12., Berichtszeitpunkt ist der 31. 7.:

Arbeitspaket Plankosten je Arbeitspaket

Plankosten zum Berichtszeitpunkt

Istkosten Restkosten

A 15 000 15 000 18 00 0

B 15 000 12 000 15 000 5 000

C 10 000 5 000 5 000 5 000

D 12 000 6 000 7 000 6 000

E 18 000 3 000 3 000 15 000

F 20 000 0 0 20 000

Insgesamt 90 000 41 000 48 000 51 000

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

Copyright: Dr. Klaus Röber 97Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 98Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel (3)

Im Beispiel ergeben sich die folgenden Fertigstellungsgrade der Arbeitspakete und daraus die Fertigstellungswerte:

Arbeitspaket Plankosten je

Arbeitspaket

Plankosten zum Berichts-

zeitpunkt

Istkosten Restkosten Fertigstel-lungsgrad

Fertigstel-lungswert

A 15 000 15 000 18 000 0 100% 15 000

B 15 000 12 000 15 000 5 000 75% 11 250

C 10 000 5 000 5 000 5 000 50% 5 000

D 12 000 6 000 7 000 6 000 54% 6 480

E 18 000 3 000 3 000 15 000 17% 3 060

F 20 000 0 0 20 000 0% 0

Insgesamt 90 000 41 000 48 000 51 000 40 790

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

Copyright: Dr. Klaus Röber 99Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel (4)

Es ergeben sich folgende Werte: Kostendifferenz (Cost Variance) von – 7210. 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 7 000 ü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 -210. 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/ 48 000) 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 105 908 (90 000 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.

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

Copyright: Dr. Klaus Röber 100Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Beispiel (5): Grafik

90 000

80 000

70 000

60 000

50 000

40 000

30 000

20 000

10 000

0

Kosten

ZeitJ F M A M J J A S O N

PlankostenIstkostenFW

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

Copyright: Dr. Klaus Röber 101Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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 30.6.

Projekt Gesamte Plankosten

Plankosten zum Stichtag

Istkosten Fertigstellungswert

1 100 000 50 000 60 000 60 000

2 100 000 50 000 40 000 40 000

3 100 000 50 000 50 000 40 000

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

Copyright: Dr. Klaus Röber 102Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Interpretation

In Projekt 1 errechnet sich bei isoliertem Plan-/Ist-Vergleich eine gegenwärtige Kostenüberschreitung von 10 000 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.

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

Copyright: Dr. Klaus Röber 103Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 104Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Übung zur EVA (2)

Arbeitspaket Plankosten je Arbeitspaket

Plankosten zum Berichtszeitpunkt

Istkosten Restkosten

1.1 10 000 10 000 10 000 0

1.2 15 000 15 000 16 000 0

2.1 25 000 10 000 15 000 10 000

2.2 10 000 5 000 4 000 4 000

2.3 20 000 8 000 10 000 10 000

3.1 30 000 10 000 12 000 18 000

3.2 15 000 2 000 3 000 12 000

3.3 25 000 0 0 25 000

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

Copyright: Dr. Klaus Röber 105Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Lösung (1)

Arbeits

paket

Plankosten je AP

Plankosten zur Zeit t

Istkosten Restkosten Fertigstellungsgrad

Fertigstellungswert

1.1 10 000 10 000 10 000 0 100% 10 000

1.2 15 000 15 000 16 000 0 100% 15 000

2.1 25 000 10 000 15 000 10 000 60% 15 000

2.2 10 000 5 000 4 000 4 000 50% 5 000

2.3 20 000 8 000 10 000 10 000 50% 10 000

3.1 30 000 10 000 12 000 18 000 40% 12 000

3.2 15 000 2 000 3 000 12 000 20% 3 000

3.3 25 000 0 0 25 000 0 0

Gesamt 150 000 60 000 70 000 79 000 70 000

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

Copyright: Dr. Klaus Röber 106Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Lösung (2)

Der Plan-/Ist-Vergleich zeigt eine Überschreitung der geplanten Kosten um 10 000 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) = 150 000

– 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) = 10 000. 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.

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

Copyright: Dr. Klaus Röber 107Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 108Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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 Manager‘s Guide, 2003 Gower (UK)

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

Copyright: Dr. Klaus Röber 109Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 110Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 111Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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!

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

Copyright: Dr. Klaus Röber 112Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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 Auswirkungauf• Termine• Aufwand• Kosten• Risiko

Projekt-Change-Request=Dokumentation jeder Änderung mit Auswirkungauf• 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

BasisProjektplan !

Zusammenhang der Berichte in der Projektsteuerung

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

Copyright: Dr. Klaus Röber 113Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 114Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Termincontrolling Phase Phase Phase Phase Phase

1 2 3 4 5

Vorstudie Analyse Design Realisierung Einführung

Planung:

Laufzeit in Wochen 16,0 25,0 30,0 10,0 15,0

Endtermin 24.05.97 15.11.97 13.06.98 22.08.98 05.12.98

Ist-Werte:

Start in KW 2 22 15 0 0

Letzte Meldung in KW 18 52 25 0 0

Fertigstellung in % 100 100 20 0 0

Laufzeit in Wochen 17,0 31,0 11,0 0,0 0,0

Endtermin 31.05.97 03.01.98 offen offen offen

Analyse/Hochrechnung:

Abweichung in Wochen -1,0 -6,0 19,0 10,0 15,0

Hochrechnung Laufzeit: 17,0 31,0 55,0 10,0 15,0

Neue Abweichung -1,0 -6,0 -25,0 0,0 0,0

Neuer Endtermin 31.05.97 03.01.98 23.01.99 03.04.99 17.07.99

Projekt-Controlling-Bericht: Beispiel Termincontrolling Zahlen

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

Copyright: Dr. Klaus Röber 115Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

20.08.95

06.01.96

24.05.96

10.10.96

26.02.97

16.07.97

02.12.97

20.04.98

06.09.98

23.01.99

11.06.99

29.10.99

Starttermin Vorstudie Analyse Design Realisierung Einführung

Planung Analyse/Hochrechnung

Projekt-Controlling-Bericht: Beispiel Termincontrolling Grafik

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

Copyright: Dr. Klaus Röber 116Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Aufwandscontrolling Phase Phase Phase Phase Phase

1 2 3 4 5

Vorstudie Analyse Design Realisierung Einführung

Planung:

Aufwand 15,0 45,0 60,0 30,0 30,0

Ist-Werte:

Aufwand 30,0 35,0 14,3 0,0 0,0

Abweichung -15,0 10,0 45,8 30,0 30,0

Fertigstellung in % 100 100 20 0 0

Analyse/Hochrechnung:

Aufwand hochgerechnet 30,0 35,0 71,3 30,0 30,0

Abweichung -15,0 10,0 -11,3 0,0 0,0

Projekt-Controlling-Bericht: Beispiel Aufwandscontrolling intern

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

Copyright: Dr. Klaus Röber 117Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Aufwandscontrolling Phase Phase Phase Phase Phase

Externe 1 2 3 4 5

Vorstudie Analyse Design Realisierung Einführung

Planung:

Aufwand Plan 25,0 50,0 45,0 5,0 5,0

Ist-Werte:

Aufwand Ist 27,5 56,0 13,0 0,0 0,0

Abweichung -2,5 -6,0 32,0 5,0 5,0

Fertigstellung in % 100 100 20 0 0

Analyse/Hochrechnung:

Aufwand hochgerechnet 27,5 56,0 65,0 5,0 5,0

Abweichung -2,5 -6,0 -20,0 0,0 0,0

Projekt-Controlling-Bericht: Beispiel Aufwandscontrolling Externe

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

Copyright: Dr. Klaus Röber 118Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

0,0

10,0

20,0

30,0

40,0

50,0

60,0

70,0

80,0

Vorstudie Analyse Design Realisierung Einführung

Planaufwandintern

Istaufwandintern

Planaufwandextern

Istaufwandextern

Beispiel für Aufwandscontrolling

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

Copyright: Dr. Klaus Röber 119Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 120Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 121Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Genehmigte Change-Requests undPlanänderungen

Projektauftrag

Projektplan

Projekt-ControllingBericht

Projekt-Status-Bericht

Projekt-AbschlussBericht

Projekt-Change.Request

Ergebnisse im Management-Regelkreis "Projekt"

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

Copyright: Dr. Klaus Röber 122Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 123Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Projekt-Change-Request / Change Order: Beispiel

Pro

jekt

Ch

ang

e R

equ

est

/ C

han

ge

Ord

er (

Bei

spie

l)R

eque

st-N

r.:

cr00

01

Pro

jekt

nam

e:In

tegr

iert

e A

uftr

agsa

bwic

klun

g

Spo

nso

r:

Her

r K

ern,

Hon

gkon

g

Pro

jekt

nu

mm

er:

T47

11

Pro

jekt

man

ager

:

Her

r M

eyer

Tei

lpro

jek

t:

Tei

lpro

jek

t-N

r.:

Bes

chre

ibun

g de

r Ä

nder

ung:

Für

das

inte

grie

rte

Auf

trag

sabw

ickl

ungs

-Sys

tem

war

der

Ser

ver

in d

er K

onze

rnze

ntra

le a

m S

tand

ort F

rank

furt

gepl

ant.

Dam

it s

ollt

e di

e In

tegr

atio

n zu

m T

erm

inüb

erw

achu

ngs-

und

Inf

orm

atio

nssy

stem

des

Kon

zern

s

erle

icht

ert w

erde

n. D

er S

erve

r ei

nsch

ließ

lich

der

erf

orde

rlic

hen

Net

zanb

indu

ngen

und

der

Bet

rieb

ssof

twar

e so

llab

1.1

.199

9 am

neu

en S

tand

ort B

erli

n st

ehen

.

Beg

ründ

ung:

Der

Kon

zern

hat

sic

h fü

r de

n ne

uen

Sta

ndor

t Ber

lin

als

Kon

zern

zent

rale

ent

schi

eden

.

Alt

erna

tive

n:

Die

Bau

arbe

iten

und

der

Um

zug

nach

Ber

lin

kann

sic

h u.

U. v

erzö

gern

.Um

die

ses

Ris

iko

zu v

erm

eide

n, k

önnt

ede

r S

erve

r in

ein

em d

er A

usla

ndsb

üros

auf

gest

ellt

wer

den.

Daf

ür b

iete

t sic

h H

ongk

ong

an, d

a do

rt d

as S

yste

m in

der

erst

en S

tufe

ein

gefü

hrt w

ird.

Nac

h er

folg

reic

her

Ein

führ

ung

des

Sys

tem

s in

Hon

gkon

g ka

nn im

Rah

men

der

Stu

fe 2

( a

lle

ande

ren

Aus

land

sbür

os )

der

Ser

ver

nach

Ber

lin

verl

egt w

erde

n. Z

wis

chen

zeit

lich

kön

nen

die

rele v

ante

n D

aten

im 4

-Stu

nden

takt

an

das

Ter

min

über

wac

hung

s- u

nd I

nfor

mat

ions

syst

em p

er E

-Mai

l übe

rtra

gen

wer

den.

Aus

wir

kung

en:

__K

__T

erm

in__

G__

Auf

wan

d__

G__

Kos

ten

__K

__R

isik

o(K

=K

eine

Aus

wir

kung

, G=

Ger

inge

Aus

wir

kung

en, H

=H

ohe

Aus

wir

kung

)

Ter

min

ausw

irku

ng:

Auf

wan

daus

wir

kung

:D

urch

die

zw

eim

alig

e In

stal

lati

on d

es S

erve

rs, z

unäc

hst i

n H

ongk

ong

und

spät

er in

Ber

lin

ents

teht

ein

Meh

rau

f wan

d vo

n ca

. 3 M

M.

Kos

tena

usw

irku

ng:

Die

Pro

jekt

-Kos

ten-

wer

den

sich

dur

ch d

ie Ä

nder

ung

um c

a. 7

5.00

0 D

M e

rhöh

en. D

ies

kom

mt z

um e

inen

dur

chde

n hö

here

n A

ufw

and

zust

ande

(ca

. 60.

000

DM

) u

nd d

urch

die

zus

ätzl

iche

n R

eise

kost

en (

ca. 1

5.00

0 D

M).

Ris

iko-

Aus

wir

kung

:

Kei

ne. D

a de

r St

ando

rt B

erli

n en

tsch

iede

n is

t, da

s D

atum

für

den

Um

zug

aber

noc

h un

sich

er is

t, ka

nn d

urch

die

Alt

erna

tive

das

Ris

iko

eher

min

imie

rt w

erde

n.

Req

uest

:

____

____

____

____

____

____

____

____

____

____

____

____

____

____

_

Unt

ersc

hrif

t Pro

jekt

man

ager

Dat

um

Gen

ehm

igun

g:

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

Copyright: Dr. Klaus Röber 124Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Projekt Change Report: Beispiel

( Projekt Change Report)

Request Nr. Kurzbeschreibung Datum desRequests

Status desRequests

Change Ordererteilt durch/am

Kommentar

cr0001 Bridge-Programm OrderEntry

cr0002 Zusätzliche FunktionDrucken Auftragsstatus

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

Copyright: Dr. Klaus Röber 125Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 126Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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

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

Copyright: Dr. Klaus Röber 127Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 128Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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%)

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

Copyright: Dr. Klaus Röber 129Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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 atAllianz Life Insurance, (www.software-kompetenz.de).

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

Copyright: Dr. Klaus Röber 130Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: Projektsteuerung

Reviews organisieren und durchführen ( Tilo Linz, www.projektmagazin.de,

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.

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

Copyright: Dr. Klaus Röber 131Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 132Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 133Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 134Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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.

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

Copyright: Dr. Klaus Röber 135Workshop: IT-Projektmanagement - Version 3.0 - 07/2004 Modul: 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