Mehr Transparenz bei IT-Projekten mit Earned Value Controlling

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.

Der Beitrag zeigt zunächst auf, weshalb viele Ansätze des Fortschrittscontrollings nicht ausreichen, eine verlässliche Einschä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 IT-Projektverfolgung ermöglicht. Abschliessend folgt eine Übersicht über die nötigen Voraussetzungen, um diese Methode anzuwenden. Widerstände sind vorprogrammiert, insofern Transparenz nicht immer auf Gegenliebe stösst.

Fortschrittskontrolle in Projekten

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

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 verschaff 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» betriff 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 Kosteneffzienz 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 Ist-Kosten 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.

 Autor:

Prof. Dr. Adrian Specker
Dozent für Wirtschaftsinformatik & ERP-Systeme,
Leiter CAS Projektmanagement,
Fachhochschule Nordwestschweiz, Windisch
www.fhnw.ch