Am Ende eines Projekts fällt fast immer ein Urteil: erfolgreich, teilweise erfolgreich, gescheitert. Auffällig ist, wie oft die Kriterien für dieses Urteil erst in dem Moment entstehen, in dem das Urteil gefällt wird. Man blickt zurück auf das, was geliefert wurde, und leitet daraus ab, was "Erfolg" eigentlich bedeuten sollte. Das ist keine Evaluation — das ist eine nachträgliche Rechtfertigung, und das Ergebnis steht bereits fest, bevor die Frage überhaupt gestellt wird.
Ein Baustein aus vier unabhängigen Rahmenwerken
Vier eigenständige Evaluationsrahmenwerke — OECD DAC (ein breit angewandtes, übertragbares Rahmenwerk, ursprünglich für die Entwicklungszusammenarbeit entwickelt), die britische Gate-5-Prüfung, die PRINCE2-Praxis und das CIPP-Modell von Stufflebeam — sind unabhängig voneinander zu denselben Bausteinen gelangt. Einer davon: Kriterien, die im Voraus festgelegt werden, nicht nachträglich. Neben der Prüfung des Nutzens gegen das ursprüngliche Versprechen und der unabhängigen Validierung ist dies eines der wiederkehrenden Elemente, auf die diese Rahmenwerke jeweils für sich kommen.
Die Logik ist einfach. Sobald die Kriterien erst nach der Lieferung formuliert werden, ist kein echter Vergleich mehr zwischen Versprechen und Ergebnis möglich — nur noch eine Beschreibung des Ergebnisses selbst, gefärbt von dem, was nun einmal geliefert wurde.
Warum das in der Praxis schiefgeht
Zu Beginn eines Projekts wird Erfolg oft vage umschrieben: "ein funktionierendes System", "zufriedene Nutzer", "im Budget- und Zeitrahmen" — ohne festzuhalten, was das konkret bedeutet und wann das geprüft wird. Bis das Projekt fertig ist, hat sich der Kontext verändert, wurde der Umfang angepasst, sind neue Stakeholder hinzugekommen — und die Definition von "Erfolg" passt sich entsprechend an. Nicht aus böser Absicht, sondern weil es nie einen festen Referenzpunkt gab, an dem geprüft werden konnte.
Das Ergebnis ist eine Evaluation, die vor allem bestätigt, was bereits bekannt war, statt etwas zu prüfen. Die Nutzenrealisierung ist dafür das deutlichste Beispiel: Wurde vorab nicht festgehalten, welcher Nutzen wann eintreten sollte, lässt sich im Nachhinein unmöglich belegen, ob er tatsächlich eingetreten ist.
Was das konkret verlangt
Im Voraus festgelegte Kriterien bedeuten kein dickes Dokument beim Projektstart, das nie wieder angeschaut wird. Es bedeutet drei praktisch umsetzbare Dinge:
- Festhalten, was Erfolg misst, nicht nur, was das Projekt liefert. Eine Liste von Ergebnissen ist kein Erfolgskriterium; ein Maßstab, an dem diese Ergebnisse gemessen werden, schon.
- Festhalten, wann das geprüft wird. Mancher Nutzen wird erst Monate nach der Lieferung sichtbar — dieser Zeitpunkt sollte bereits beim Start im Kalender stehen, nicht erst erfunden werden, wenn die Frage aktuell wird.
- Die Kriterien nicht stillschweigend ändern. Umfang und Umstände ändern sich während eines Projekts häufig zu Recht. Müssen die Kriterien deshalb mitziehen, gehört diese Anpassung selbst festgehalten und begründet — nicht stillschweigend im Abschlussbericht zu verschwinden.
Keine Garantie, aber eine Voraussetzung
Dass vier unabhängige Rahmenwerke unabhängig voneinander zu diesem Baustein gelangen, bedeutet nicht, dass ein Projekt mit im Voraus festgelegten Kriterien automatisch besser verläuft oder dass eine Evaluation mit diesem Baustein nachweislich zu besseren Folgeprojekten führt. Was es bedeutet: Ohne im Voraus festgelegte Kriterien ist eine Evaluation im Nachhinein nicht mehr als eine Zusammenfassung mit einer Note obendrauf. Die Frage, ob ein Projekt erfolgreich war, lässt sich dann nie ehrlich beantworten — weil niemand im Voraus festgehalten hat, was die Antwort eigentlich belegen sollte.
Wer prüfen will, ob die eigenen Erfolgskriterien für ein laufendes oder abgeschlossenes Projekt tatsächlich im Voraus tragfähig festgelegt wurden, findet mit dem EvaluatieScore für 15 € eine strukturierte Einschätzung: dutchmind.com/producten/evaluatiescore.
Quellen
- OECD DAC Network on Development Evaluation (EvalNet) (2019), Evaluation Criteria (herzien, DCD/DAC(2019)58 FINAL) — one.oecd.org.
- HM Government / Cabinet Office–IPA (nu NISTA) (2021), Gate 5: Operations Review and Benefits Realisation (Assurance Portfolio Standard, V1.0) — assets.publishing.service.gov.uk.
- PRINCE2-praktijk — End Project Report en Lessons Report Template (prince2.wiki, secundaire bron, geen officiële AXELOS-manual).
- Stufflebeam, D.L. (2015), CIPP Model checklist (2e ed.) — rszarf.ips.uw.edu.pl.