Earned Value Controlling» zur Fortschrittskontrolle

IT-Projektmanagment topsoft-Magazin 15-3
Mehr Transparenz bei IT-Projekten: «Earned
Value Controlling» zur Fortschrittskontrolle
Ein erfolgreiches Informatikprojekt setzt voraus, dass die vorgesehene Funktionalität im projektierten Zeit- und Kostenrahmen eingeführt wird. Der Projekterfolg bemisst sich an den drei Grössen
Inhalt, Zeit und Kosten. Die Methode des Earned Value Controlling ermöglicht es, Projektausschuss
und Projektleitung, den Fortschritt integriert zu überwachen – ein «Must» für mehr Transparenz im
IT-Projekt.
>> Prof. Dr. Adrian Specker | Fachhochschule Nordwestschweiz
Der Artikel zeigt zunächst auf, weshalb viele Ansätze des Fortschrittscontrollings nicht
ausreichen, eine verlässliche Ein-schätzung
des Projektstandes abzugeben (was heisst:
«80 Prozent» Fortschritt?). Weiter wird die
Methode des «Earned Value Controlling»
vorgestellt, eine Transparenz schaffende Controlling-Methode, die eine verlässliche ITProjektverfolgung ermöglicht. Abschliessend
zeigt der Artikel auf, welche Voraussetzungen
zu beachten sind, um diese Methode anzuwenden. Widerstände sind vorprogrammiert,
insofern Transparenz nicht immer auf Gegenliebe stösst.
Fortschrittskontrolle in Projekten
Prof. Dr. Adrian Specker
Dozent für Wirtschaftsinformatik & ERP-Systeme,
Leiter CAS Projektmanagement, Fachhochschule Nordwestschweiz, Windisch
www.fhnw.ch
Wer kennt es nicht: der Projektleiter H. Glück
verbreitet im Projektausschuss die Schönwetterstimmung. So wird gemeinsam mit dem
SW-Partner berichtet, die Zahl der implementierten Funktionalitäten habe im letzten Monat die 70 Prozent Marke überschritten. Weiter wird ausgeführt, die aufgelaufenen Kosten
würden sich auf CHF 500'000 belaufen - bei
einem Gesamtbudget von 1. Mio. Weiter sei
nunmehr die halbe Projektdauer verstrichen,
was Gutes verheisst. Gemäss Herr Glück ist das
Projekt soeben auf die Zielgerade eingebogen!
Anlässlich einer Projektausschusssitzung zwei
Monate später zeigt sich ein ganz verändertes
Bild: H. Glück muss nun berichten, zur Fertigstellung des Projektes sei das Projektbudget
aufgrund eingehender Betrachtungen nicht
mehr ausreichend, sondern müsse erhöht
werden. Es sei leider mit einer verlängerten
Projektdauer und erheblich höheren Kosten
zu rechnen. Dies wäre bei IT-Projekten aber
normal.
Wo liegt der Denkfehler von H. Glück?
Wo liegt der Denkfehler von H. Glück? Hätte
bereits früher erkannt werden können, wie es
58
um das Projekt tatsächlich steht? Dem Projektausschuss wurde zum Stand des Projektes
ursprünglich folgendes berichtet:
∙∙ 70 Prozent umgesetzte Funktionalität
∙∙ 50 Prozent der budgetierten Kosten
∙∙ halbe Projektdauer
Diese drei Zahlen präsentieren sich auf den
ersten Blick recht gut und man könnte (fälschlicherweise) hoffen, dass die verbleibenden
30Prozent im Budgetrahmen umgesetzt werden. Die dem Projektausschuss präsentierten Zahlen sind aber in Tatsache vollständig
wertlos. Wo liegt der Denkfehler? Betrachten wir hierzu die drei fraglichen Grössen im
Einzelnen:
Fehler 1:
Eine Aussage «70 Prozent» des Funktionsumfanges ist mehrdeutig und unklar. So ist damit
nicht gesagt, ob es sich dabei um a) die Anzahl
der implementierten Funktionen handelt oder
b) um eine Angabe, welche sich korrekterweise auf den gesamten Umsetzungsaufwand
bezieht. Man spricht nicht ohne Grund davon,
wonach die ersten 80 Prozent einer Aufgabe
gleich viel Aufwand verursachen, wie die restlichen 20 Prozent.
Wird mit der Aussage «70 Prozent» also lediglich darauf Bezug genommen, wie viele
Funktionalitäten umgesetzt sind, so sagt dies
gerade nichts über den noch zu leistenden
Restaufwand aus. Wäre damit aber z.B. seitens
des Software-Lieferanten die klare Aussage
verbunden, bis zum Projektabschluss seien
tatsächlich nur noch 30 Prozent des Budgets,
d.h. CHF 300'000 aufzuwenden, dann würde
das einer guten und korrekten Information
entsprechen. Herr Glück begnügte sich aber
mit der vagen Aussage von 70 Prozent, ohne
dass tatsächlich explizit vereinbart worden
wäre, der Aufwand bis Abschluss betrage noch
CHF 300'000.
IT-Projektmanagement
Fehler 2:
Die Aussage, es sei bereits die Hälfte der Projektdauer verstrichen, ist ebenfalls zweideutig.
Wenn damit ausgesagt werden soll, auch der
inhaltliche Fortschritt müsste damit bei der
Hälfte liegen, so ist dies unzutreffend. Die verstrichene Zeitdauer sagt gerade nichts darüber
aus, welcher Fortschritt gemäss Projektplan
hätte geleistet werden müssen. In unserem
Beispiel wäre z.B. vorgesehen gewesen, nach
der ersten Projekthälfte bereits 60 Prozent des
Gesamtaufwandes umzusetzen, da anschliessend die Ferienzeit ansteht. Die einzig verlässliche Grösse im Controlling Bericht war demnach die Kostenangabe.
Earned Value: Drei geldwerte Grössen
Wie verschafft nun der Ansatz des «Earned
Value Controllings» eine Verbesserung und
eine erhöhte Transparenz? Die Grundidee besteht darin, die drei zentralen Projektgrössen
«Inhalt, Zeit und Kosten» nicht nur in unklaren Prozentangaben, sondern explizit monetär
zu bewerten, d.h. als Geldwert anzugeben.
Beginnen wir bei den Kosten. Die Kosten sind
insofern problemlos, sie müssen aber lückenlos erfasst werden. Die Kosten belaufen sich
auf CHF 500'000.
In einem nächsten Punkt betrachten wir die
zeitliche Planung der Aufwände. Mit Hilfe einer sauberen Planung der Arbeitspakete über
die Zeitachse lässt sich eine «Plankostenkurve» für das Projekt erstellen. Diese zeigt auf,
wie sich die Kosten über die Zeitachse entwickeln sollen und hätte im Beispiel die Angabe erlaubt, dass nach der halben Projektdauer
Arbeiten im Umfang von CHF 600'000 fertiggestellt sein sollten. Aus Managementsicht
ermöglicht nur eine saubere Planung ein späteres Controlling in Bezug auf die Abweichungen von Plan und Ist.
Die entscheidende Idee des «Earned Value
Controllings» betrifft nun aber den Inhaltsfortschritt. Die Idee besteht darin, den erreichten Inhaltsfortschritt, d.h. den im Projekt bis
dato «erarbeiteten Projektwert» (engl.: «Earned Value»), monetär zu bewerten. Herr Glück
hat also – gemeinsam mit dem SW-Lieferanten
– sauber abzuschätzen, welchen «Wert» das
Projekt bereits erreicht hat. Hierzu bestehen
verschiedene Möglichkeiten. Einerseits kann
man aufgrund der tatsächlich implementierten Funktionen und Budgets auf-summieren,
um damit die in Summe erreichte Gesamtleistung zu erfassen. Oder aber alternativ,
als einfacher Weg, wird lediglich abgeschätzt,
welcher Restaufwand bis zum Abschluss des
Projektes noch anfallen wird. Anschliessend
berechnet man die Differenz aus Gesamtbudget und Restaufwand, was gerade dem erreichten Projektwert entsprechen muss. Dies gilt
nämlich immer, falls keine Anpassungen und
Veränderungen im Projektumfang vorgenommen wurden.
Wenn also der SW-Anbieter Herr Glück darüber informiert, er werde bis zum vereinbarten
Projektabschluss noch CHF 700'000 fakturieren (und es würden keine Mehrleistungen
erbracht), so entspricht der Earned Value des
Projektes bis dato CHF 300'000 (=CHF 1 Mio.
minus CHF 700'000).
Wir haben damit das folgende, veränderte
Bild, welches H. Glück dem Projektausschuss
bereits anlässlich der besagten Sitzung hätte
präsentieren müssen:
Fortschrittsübersicht:
Hätte der Projektausschuss diese drei wichtigen Grössen in ein Verhältnis zueinander
gestellt, so wäre rasch klar geworden, wie
schlecht es um das Projekt von H. Glück eigentlich bestellt gewesen wäre:
∙∙ CHF 300'000 Earned Value
∙∙ CHF 600'000 geplante Leistung
∙∙ CHF 500'000 verbuchte Kosten
Obwohl dieser von «70 Prozent» der Funktionalität gesprochen hatte, kam diesen Arbeiten
ein Projektwert von lediglich CHF 300'000 zu
(es hat sich mit anderen Worten um Funktionen gehandelt, welche nicht grossen Aufwand
hätten verursachen dürfen). Gemäss Plan hätten aber bereits Arbeiten im Umfang von CHF
600'000 umgesetzt sein sollen. In Bezug auf
den Zeitfortschritt geht das Projekt damit nur
halb so schnell vorwärts, wie ursprünglich geplant. In der Sprache des «Earned Value Controllings» hat das Projekt einen «Zeitwirkungsgrad» von 50 Prozent.
In Bezug auf die Kosteneffizienz sieht das
Projekt leider auch nicht besser aus. Dem erreichten Projektwert von CHF 300'000 (Earned Value) stehen die vom SW-Lieferanten in
Rechnung gestellten Kosten im Umfang von
CHF 500'000 gegenüber. Abgerechnete Kosten
bedeuten nicht automatisch, dass diese einem
effektiven Wert des Projektes entsprechen. Wie
das Beispiel zeigt, musste der SW-Lieferant für
die umgesetzten Funktionen wesentlich mehr
aufwenden, als ursprünglich von ihm selbst
geplant.
Das Verhältnis von Earned Value und IstKosten entspricht dem sogenannten Kostenwirkungsgrad. Im Beispiel entspricht dies dem
Verhältnis von CHF 300'000 zu CHF 500'000,
entsprechend 60 Prozent. Für jeden verrechneten Franken werden lediglich 60 Rappen
an Wert geschaffen. Offenbar wird für die geplante Leistung zu viel Zeit aufgewendet und
der «Wirkungsgrad» ist gering – entsprechend
einem Benzinmotor mit schlechter Wirkung.
Prognose: Wie endet das Projekt?
Auf der Basis dieser drei Grössen lässt sich
nun eine Abschätzung vornehmen, zu welchen
Gesamtkosten und in welcher Projektdauer
das Projekt abschliessen sollte. Aufgrund des
Zeitfaktors von 50 Prozent muss zurzeit davon
ausgegangen werden, dass das Projekt doppelt
so lange dauern wird, wie ursprünglich geplant. Die Kosten werden bei einem Kostenfaktor von 60 Prozent rund 1.66 Mio. betragen,
viel mehr als die budgetierte Million.
Voraussetzungen für die Umsetzung
Zum Einsatz der Methode in der Praxis sind
mehrere Faktoren zu beachten. So empfiehlt
es sich, die Methode bereits im Dienstleistungsvertrag einzufordern. Die Softwarelieferanten müssen sich dazu verpflichten, die
entsprechende Plankostenkurve tatsächlich zu
erstellen und regelmässig Kosten und Earned
Value zu rapportieren. Beides stösst auf gewisse Schwierigkeiten, insofern es mit einigem
Mehraufwand verbunden ist. Sodann ist bei
Fixpreisprojekten nicht immer klar, weshalb
der Lieferant diese Werte abgeben soll, auch
wenn es für den Kunden von zentraler Bedeutung ist, den Fortschritt auch hier gut abschätzen zu können.
Erfahrungen aus aktuellem Projekt
Die Erfahrungen aus früheren und einem eben
abgeschlossenen IT-Projekt zeigen, dass der
Vorteil der hohen Transparenz den notwendigen Zusatzansatzaufwand für das Reporting
aufwiegt. Sodann werden die SW-Anbieter
dazu gebracht, auch intern selbst regelmässig über die Bücher zu gehen. In der Regel
wird auch schneller erkannt, ob es versteckte
«Change Requests» gegeben hat, welche zu
Kostenüberschreitungen führen dürften. Insgesamt werden Probleme viel zeitnaher erkannt und die Diskussion über Mehrkosten
verschiebt sich nicht ausschliesslich auf das
Projektende. <<
59

Download Report