Warum ist Projektfortschritt so schwer zu messen?
Weil die üblichen Zahlen selten Ergebnisse zählen. Meist sind es Einschätzungen: Ein Projekt meldet 80 Prozent, zwei Wochen später 85, dann 90. Und dort bleibt es. Im Projektmanagement heißt das 90-Prozent-Syndrom.
Oft ist das Optimismus. In den letzten Schritten stecken halt die Überraschungen: Tests, Abnahmen, Sonderfälle, der eine Standort, der anders ist. Wer vorher schätzt, sieht sie noch nicht. Manchmal ist es Politik. Eine geschätzte Zahl ist immer auch eine Botschaft, und vor dem Lenkungskreis sieht 90 besser aus als 70.
Schwierig wird es mit mehreren Projekten. Rechnet jede Projektleitung auf ihre Art, passen die Zahlen nicht zusammen. Eine Geschäftsführung mit zwanzig Vorhaben legt dann Einschätzungen nebeneinander. Im Beitrag über echte Projektleiter steht der Rat, nach dem Fertigstellungsgrad zu fragen statt nach der Ampelfarbe. Bleibt die Frage, wie man ihn misst.
Welche Methoden gibt es, den Projektfortschritt zu messen?
Der Begriff ist genormt. Die DIN 69901 definiert den Fertigstellungsgrad als „Verhältnis der zu einem Stichtag erbrachten Leistung zur Gesamtleistung eines Vorgangs oder eines Projekts“. Wie man die erbrachte Leistung ermittelt, lässt sie offen. Das entscheidet die Methode. Keine davon ist falsch — jede beantwortet eine eigene Frage.
| Methode | So wird gemessen | Beantwortet die Frage | Passt, wenn … |
|---|---|---|---|
| Prozentschätzung | Die Verantwortlichen schätzen den Anteil | Wie weit ist es nach Einschätzung der Beteiligten? | die Arbeit kurz ist oder eine zweite Meinung gebraucht wird |
| 0/100 | Zählt erst, wenn das Ergebnis vorliegt | Was ist fertig? | ein Arbeitspaket in ein bis zwei Berichtszeiträume passt |
| 50/50 oder 20/80 | Fester Anteil bei Beginn, Rest bei Abschluss | Was ist begonnen, was abgeschlossen? | viele kleine Pakete laufen, deren Abweichungen sich ausgleichen |
| Gewichtete Meilensteine (Statusschritt-Methode) | Feste Anteile je Zwischenergebnis | Welche Zwischenergebnisse liegen vor? | Arbeiten länger laufen und sich in Stufen teilen lassen |
| Mengenzählung | Fertige Einheiten werden gezählt | Wie viele Einheiten sind durch? | viele gleichartige Einheiten anfallen: Geräte, Postfächer, Standorte |
| Earned Value (PMI) | Wert der erledigten Arbeit gegen Plan und Istkosten | Sind wir im Plan und im Budget, und wo landen wir? | ein Kostenplan je Arbeitspaket und laufende Istkosten vorliegen |
| Budget- oder Aufwandsverbrauch | Anteil der verbrauchten Mittel | Wie viel ist ausgegeben? | Kosten gesteuert werden sollen |
| Story Points und Burndown | Geschätzte Punkte je Sprint | Schafft das Team, was es sich vorgenommen hat? | ein festes Team in Sprints plant |
| Erledigte Tickets | Anteil geschlossener Aufgaben | Wie viel ist abgearbeitet? | ein Team seine laufende Arbeit steuert |
Messtechniken nach dem Practice Standard for Earned Value Management des PMI und der deutschsprachigen Projektmanagement-Literatur. Die rechte Spalte ist unsere Einordnung.
Budgetverbrauch, Story Points und Tickets messen etwas Richtiges, nur eben keinen Fortschritt. Was ausgegeben ist, sagt nichts darüber, was dafür fertig wurde. Story Points sind die relative Schätzung eines Teams. Zwischen Teams lassen sie sich nicht vergleichen. Und Tickets sind unterschiedlich groß — die Quote steigt schon, wenn jemand eine Aufgabe in drei teilt. Alle drei gehören in die Steuerung. Für die Frage nach dem Stand sind sie nicht gemacht.
Was ist die Earned-Value-Methode nach PMI?
Die vollständigste der Methoden. Sie entstand in den 1960er-Jahren in Programmen der US-Regierung. Seit 1987 steht sie im PMBOK Guide, seit 2019 gibt es sie als amerikanische Norm ANSI/PMI 19-006-2019. Das Prinzip: Jedes Arbeitspaket bekommt vorab einen Wert. Erledigte Arbeit „verdient“ diesen Wert, daher der Name. Dann liegen drei Größen nebeneinander — was geplant war, was erledigt ist und was es gekostet hat.
Ein erfundenes Rechenbeispiel mit einem Gesamtbudget (BAC) von 250.000 Euro:
| Kennzahl | Bedeutung | Im Beispiel |
|---|---|---|
| Planwert (PV) | Wert der Arbeit, die bis zum Stichtag erledigt sein sollte | 100.000 Euro |
| Fertigstellungswert (EV) | Wert der Arbeit, die tatsächlich erledigt ist | 80.000 Euro |
| Istkosten (AC) | Was bis zum Stichtag ausgegeben wurde | 95.000 Euro |
| Fertigstellungsgrad = EV ÷ BAC | Anteil der gesamten Arbeit, der fertig ist | 32 Prozent |
| SPI = EV ÷ PV | Terminkennzahl, unter 1 heißt hinter dem Plan | 0,80 |
| CPI = EV ÷ AC | Kostenkennzahl, unter 1 heißt teurer als geplant | 0,84 |
| EAC = BAC ÷ CPI | Prognose der Gesamtkosten bei gleichem Verlauf | rund 297.000 Euro |
Das Vorhaben ist also zu 32 Prozent fertig. Es liegt ein Fünftel hinter dem Plan und landet bei gleichem Verlauf knapp 50.000 Euro über Budget. Drei Aussagen aus einer Rechnung. Wo die Daten dafür vorliegen, ist Earned Value für mich die erste Wahl.
Warum passt Earned Value in vielen IT-Abteilungen nicht eins zu eins?
Weil die Methode Daten braucht, die dort oft fehlen. Einen Wert je Arbeitspaket. Einen Basistermin je Paket. Und Istkosten, die genau auf diese Pakete gebucht werden.
In den IT-Abteilungen, die ich kenne, sieht es meist anders aus. Interne Stunden werden selten auf Projekte gebucht. Das Budget ist nach Kostenarten aufgeteilt: externe Dienstleistung, Hardware, Lizenzen. Wer dort Euro-Werte je Paket einträgt, erfindet sie.
Mit der Methode selbst hat das nichts zu tun. Es fehlen schlicht ihre Voraussetzungen. Die siebte Ausgabe des PMBOK Guide macht es sogar zum Grundsatz, das Vorgehen an das Vorhaben anzupassen. Und die Earned-Value-Literatur kennt den einfachen Fall: In einfachen Projekten bekommt jede Aktivität einen gewichteten Punktwert statt eines Budgets.
Übrig bleibt der Fertigstellungsgrad. Gewichtet wird mit Punkten, Geld spielt dafür keine Rolle.
Wie macht man ein Projekt messbar, ohne Kosten zu erfassen?
Mit vier Regeln. Mehr braucht es nicht.
1. Die Messbasis steht vorher fest. Ein Projekt hat 100 Punkte, vorab auf seine Ergebnisse verteilt. Für jedes Ergebnis ist aufgeschrieben, woran man erkennt, dass es fertig ist. 2. Gezählt wird mit Nachweis. Ein Ergebnis zählt ganz oder gar nicht, mit Datum und Beleg. Was lange dauert, bekommt Zwischenstufen. Ein Konzept zählt etwa halb mit dem Entwurf und halb mit der Freigabe. 3. Mehr Arbeit ändert keine Punkte. Kommt eine Aufgabe dazu oder dauert etwas länger, rutscht ein Termin. Lenkungskreise, Berichte und Abstimmungen bringen keine Punkte. Sie sind nötig, aber kein Ergebnis. 4. Nur ein geänderter Lieferumfang ändert die Summe. Das braucht eine Entscheidung. Erreichtes bleibt erreicht. Berichtete Stände werden nie nachgerechnet.
Ich nehme 100 Punkte, weil dann ein Punkt ein Prozent ist, solange der Umfang gleich bleibt. Die Messbasis pflegt die Projektleitung, allein. Vom Team kommt nichts Zusätzliches, die Ergebnisse entstehen ohnehin. Bevor die erste Zahl berichtet wird, gibt der Auftraggeber die Messbasis frei.
Ein zweites erfundenes Beispiel. Ein Unternehmen stellt die Telefonie an acht Niederlassungen um. Die Grundlagen zählen 20 Punkte: Konzept, Pilot, Schulungsunterlagen. Der Abschluss zählt 8, also Rückbau der Altanlagen und Projektabschluss. Jede Niederlassung bekommt 9 Punkte nach demselben Muster: vorbereitet 2, umgestellt 4, übergeben 3. Sind die Grundlagen erledigt, drei Niederlassungen übergeben und eine vorbereitet, stehen 49 von 100 Punkten.
Braucht jede Niederlassung nach dem Pilot eine zweite Schulung, gehört das zum Schritt „umgestellt“. Sein Termin rutscht vielleicht. An den Punkten ändert sich nichts. Kommt aber eine neunte Niederlassung dazu, bringt sie 9 Punkte mit. Die Summe steigt auf 109, die 49 erreichten Punkte bleiben — und sind jetzt 45 Prozent. Das ist Absicht. Mehr Lieferumfang heißt mehr Weg bis zum Ziel, und das soll man sehen. Fällt dagegen eine noch nicht begonnene Niederlassung weg, stehen 49 von 91 Punkten, also 54 Prozent. Die Umrechnung steht mit Datum und Begründung im nächsten Bericht. Das Schaubild zeigt beide Fälle.
Warum lässt sich so eine Zahl kaum schönen?
Weil es nichts mehr zu verhandeln gibt. Die Gewichte stehen vorher fest, gezählt wird nur mit Nachweis, und Berichtetes wird nicht umgerechnet. Nach oben geht die Zahl nur, wenn etwas fertig wird.
Damit wird auch der Bericht selten, der monatelang grün ist und dann plötzlich rot. Der entsteht meist nicht aus böser Absicht. Niemand meldet gern als Erster, dass es hakt. Eine Schätzung lässt dafür Spielraum, die Messbasis fast keinen.
Das entlastet die Projektleitung. Sie muss keinen Wert mehr vertreten, der nach Fortschritt aussehen soll. Bleibt ein Schritt aus, steht er mit Grund und neuem Termin im nächsten Bericht.
Wie macht man den Fortschritt vieler Projekte vergleichbar?
Indem in jedem Projekt dieselben Regeln gelten. Dann ist ein Stand von 40 Prozent in der Netzerneuerung genauso gemessen wie in der Telefonie, egal wer die Projekte leitet. Im Portfolio sieht man, welches Vorhaben in den letzten vier Wochen Ergebnisse geliefert hat. Und welches nur Aufwand.
Für IT-Infrastruktur passt das gut. Dort wiederholt sich die Arbeit: je Standort, je Werk, je Gesellschaft. Die Schritte sind überall gleich, also auch die Punkte.
Nicht jedes Vorhaben braucht dieselbe Tiefe. Für ein kleines reicht die einfache Form: Die vorhandenen Meilensteine werden gleich gewichtet, bei fünf zählt jeder 20 Punkte. Erst wo sich Arbeit wiederholt, an Standorten oder in Rollout-Wellen, lohnt die ausführliche Form mit gewichteten Schritten wie im Beispiel oben. Beide Formen haben dieselben vier Regeln. Deshalb passen ihre Zahlen in dieselbe Übersicht. Wie man ein überfülltes Portfolio überhaupt erst ordnet, beschreibt der Projekt Portfolio Review.
Wie stellt man den echten Stand eines laufenden Projekts fest?
Mit derselben Messbasis, nur rückwärts aufgestellt. Die Methode lässt sich jederzeit einführen, auch mitten im Projekt. Übernehme ich ein Vorhaben, das ins Rutschen geraten ist, fange ich genau damit an.
Schreiben Sie den Lieferumfang auf, wie er heute gilt. Verteilen Sie die 100 Punkte und legen Sie je Ergebnis fest, wann es fertig ist. Suchen Sie dann für alles, was als erledigt gilt, den Nachweis. Was keinen hat, zählt noch nicht.
Heraus kommt der erste gemessene Stand. Liegt er unter dem letzten Bericht, ist das unangenehm. Aber von da an misst sich jeder Bericht an einer Zahl, die stimmt. Bei neuen Vorhaben gehört die Messbasis gleich in den Projektsteckbrief, als Teil der Projekt-Initialisierung. Wie ich laufende Vorhaben steuere, steht unter methodische IT-Projektleitung.
Häufige Fragen
Wie berechnet man den Fertigstellungsgrad eines Projekts?
Erreichte Punkte geteilt durch Gesamtpunkte. Vorher muss feststehen, was jedes Ergebnis wert ist und wann es als fertig gilt. In der Earned-Value-Analyse rechnet man dasselbe in Geld: Fertigstellungswert geteilt durch Gesamtbudget.
Ist das noch Earned Value nach PMI?
Was die Messung angeht, ja: feste Werte vorab, objektive Regeln, Änderungen nur per Entscheidung, keine nachträglichen Korrekturen. Vollständiges Earned Value Management ist es trotzdem nicht. Dazu fehlen Kostenplan und geplanter Verlauf über die Zeit. Hinterlegt man später je Schritt einen Basistermin, lässt sich die Terminkennzahl ergänzen.
Kann man das in Jira oder einem anderen Projektwerkzeug abbilden?
Ja. Am einfachsten mit einem Feld für die Punkte an Epics oder Meilensteinen und der Regel, dass erst ein Nachweis den Status auf erledigt setzt. Eine Tabelle reicht genauso.
Funktioniert das auch in agilen Projekten?
Ja. Ein abgenommenes Release ist ein Ergebnis wie jedes andere und bekommt seine Punkte. Story Points und Burndown bleiben, wo sie hingehören: in der Sprintplanung.
Was kann diese Fortschrittszahl nicht?
Termin- und Budgettreue zeigt sie nicht, dafür bleiben Meilensteinplan und Kostenübersicht zuständig. Sie bewegt sich in Sprüngen: nichts, solange kein Ergebnis fertig ist, dann ein ganzer Schritt. Und sie hängt an den Kriterien. Steht bei einem Schritt nur „weitgehend erledigt“, ist die Zahl wieder eine Schätzung.