Beim Abschlusstreffen für das neue Fallbearbeitungssystem einer mittelgroßen Gemeinde gibt es Applaus: termingerecht geliefert, innerhalb des Budgets von etwas über einer Million Euro, alle vereinbarten Funktionen gebaut. Der Projektleiter erhält ein Schulterklopfen und den nächsten Auftrag. Niemand stellt die Frage, die ein Jahr später noch zählt: Sind die im Business Case versprochenen dreißig Prozent kürzeren Bearbeitungszeiten tatsächlich eingetreten?
Das ist keine Ausnahme. Es ist das Muster, an dem die nachträgliche Evaluation meist scheitert: Projekte werden danach abgeschlossen, ob sie geliefert haben, was vereinbart war, nicht danach, ob sie geliefert haben, was versprochen war.
Zwei unterschiedliche Versprechen
Ein Projektplan verspricht etwas anderes als ein Business Case. Der Plan verspricht Umfang, Zeit und Geld: dieses System, zu jenem Termin, für jenes Budget. Der Business Case verspricht einen Nutzen: kürzere Bearbeitungszeiten, geringere Kosten, höhere Kundenzufriedenheit. Ein Projekt kann beim ersten Versprechen erfolgreich sein und beim zweiten völlig stumm bleiben, und das geschieht strukturell, weil nach der Lieferung niemand mehr den Auftrag hat, den Nutzen zu messen.
Der niederländische Rechnungshof (Algemene Rekenkamer) stellte dies bereits 2013 für IT-Projekte des Staates fest: Die Nutzenrealisierung wird zu wenig überwacht. Nicht, weil niemand sie für wichtig hält, sondern weil es nach der Inbetriebnahme keinen vorgesehenen Zeitpunkt mehr gibt, an dem jemand diese Frage noch stellt. Das Projekt ist fertig, das Team ist aufgelöst, die nächste Ausschreibung wartet.
Was vier Rahmenwerke gemeinsam haben
OECD DAC, ein breit angewandtes, übertragbares Rahmenwerk für Evaluation, entwickelt im Kontext der Entwicklungszusammenarbeit, stellt die Prüfung des Nutzens gegen das Versprechen an erste Stelle: nicht „wurde es geliefert", sondern „hat es getan, was es tun sollte". Das britische Gate 5, die PRINCE2-Praxis und das CIPP-Modell von Stufflebeam, unabhängig voneinander entwickelt, kommen zum selben Kern. Vier verschiedene Traditionen, eine Schlussfolgerung: Eine Evaluation, die nur auf die Lieferung schaut, evaluiert das Falsche.
Die Frage, die beim Abschluss fehlt
Das praktische Problem ist nicht, dass Organisationen keine Kriterien haben. Der Projektplan ist voll davon, es sind nur die falschen. Umfang, Zeit und Geld lassen sich bei der Lieferung leicht prüfen: Das System läuft oder läuft nicht, die Rechnung liegt vor oder liegt nicht vor. Ein Nutzen wie „dreißig Prozent kürzere Bearbeitungszeit" ist erst nach einer Phase tatsächlicher Nutzung messbar, zu einem Zeitpunkt, an dem die Inbetriebnahme längst gefeiert wurde und die Aufmerksamkeit bereits zum nächsten Projekt gewandert ist.
Das erklärt, warum die Ex-ante-Prüfung, seit der Elias-Kommission für die staatliche IT verpflichtend, zum Standard wurde, während die Ex-post-Prüfung des Nutzens es nicht ist: Die erste gehört zu dem Moment, in dem noch alle hinschauen, die zweite zu dem Moment, in dem niemand mehr hinschaut.
Für einen Projektleiter, der dieses Muster durchbrechen will, ist der erste Schritt nicht ein aufwendigerer Evaluationsprozess, sondern eine andere Frage bei der Lieferung: nicht „haben wir gebaut, was vereinbart war", sondern „welchen Nutzen aus dem Business Case prüfen wir in sechs Monaten noch, und wer macht das". Ohne diese zweite Frage bleibt „termin- und budgetgerecht" die einzige Antwort, die je gegeben wird.