EvaluatieScore Blog
Einblicke zu Lernwert, Projektevaluationen und KI
Eine Evaluation, die nicht im Kalender steht, findet nie statt
Evaluationen scheitern selten am fehlenden Willen, sondern daran, dass nie ein Zeitpunkt dafür festgelegt wurde. Was vier Evaluationsrahmenwerke und Williams' Forschung dazu sagen — und wie man es löst.
Weiterlesen →Unabhängige Evaluation beginnt nicht bei einer externen Prüfung
Vier Rahmenwerke fordern unabhängige Validierung, doch in der Praxis bedeutet das oft entweder eine externe Prüfung oder gar nichts. Dazwischen liegt eine Reihe praktikabler Formen, wenn man sie rechtzeitig wählt.
Weiterlesen →An welchem Versprechen misst man, wenn sich niemand mehr daran erinnert?
Vier Evaluationsrahmenwerke setzen voraus, dass am ursprünglichen Versprechen gemessen wird — doch nach Reorganisationen und Personalwechseln ist dieses Versprechen oft nicht mehr auffindbar. Was das für die Praxis der Projektevaluation bedeutet.
Weiterlesen →Eine Empfehlung ohne Verantwortlichen verschwindet von selbst
Eine Evaluation mit guten Empfehlungen verändert selten etwas, weil niemand außerhalb des Projektteams für die Umsetzung verantwortlich ist. Drei konkrete Schritte sorgen dafür, dass eine Lehre tatsächlich zu Politik wird.
Weiterlesen →Warum die Lehre aus diesem Projekt das nächste nie erreicht
Eine Evaluation kann unabhängig und gründlich sein und trotzdem ins Leere laufen: Ohne einen dafür vorgesehenen Prozess springt eine Lehre selten auf das nächste, vergleichbare Projekt über.
Weiterlesen →Was eine Evaluation wirklich bringt — und was unbewiesen bleibt
Es gibt wenig belastbare Belege dafür, dass eine gute Evaluation zu besseren Folgeprojekten führt. Belegbar ist hingegen: Vier unabhängig entwickelte Rahmenwerke verweisen auf dieselben vier Bausteine einer sinnvollen Evaluation.
Weiterlesen →Die PRINCE2-Praxis liefert ein Lessons-Log. Selten eine Evaluation.
PRINCE2-Projekte liefern routinemäßig ein Lessons-Log, das ist aber noch keine Evaluation. Drei kleine Ergänzungen — vorab festgelegte Kriterien, eine unabhängige Lesart und ein Verantwortlicher für die Nachverfolgung — machen den Unterschied.
Weiterlesen →Warum der Maßstab für ein Projekt schon vor dessen Start feststehen muss
Vier unabhängige Evaluationsrahmenwerke kommen jeweils für sich zum selben Baustein: Erfolgskriterien, die im Voraus festgelegt werden, nicht nachträglich. Was das konkret von einer Projektevaluation verlangt.
Weiterlesen →Vier unabhängige Rahmenwerke, dieselben vier Bausteine für eine Evaluation
OECD DAC, die britische Gate-5-Prüfung, die PRINCE2-Praxis und Stufflebeams CIPP-Modell wurden unabhängig voneinander entwickelt — und kommen dennoch zu denselben vier Bausteinen für eine Evaluation.
Weiterlesen →Der blinde Fleck der Selbstevaluation ist ein Mangel an Unabhängigkeit
Vier unabhängig voneinander entwickelte Bewertungsrahmen weisen auf denselben Punkt hin: Wer das Projekt geleitet hat, sollte nicht allein darüber urteilen, ob es erfolgreich war. Was das für Ihre nächste Evaluation bedeutet.
Weiterlesen →Warum wir keine Hindsight-Bias-Behauptung aufstellen
Hindsight Bias und Self-Serving Bias sind verlockende Erklärungen dafür, warum Evaluationen oft zu positiv ausfallen. Unsere eigene Quellenrecherche fand keine Belege, die sich spezifisch auf Ex-post-Projektevaluationen beziehen — deshalb verwenden wir diese Behauptung nicht.
Weiterlesen →Warum 'wir besprechen es noch kurz nach' keine Evaluation ist
Eine informelle Nachbesprechung fühlt sich wie eine Evaluation an, lässt aber meist das Wesentliche vermissen: eine vorab festgelegte Frage, einen Umfang und Kriterien. Dieser Unterschied ist die erste Kategorie, anhand derer EvaluatieScore einen Bericht prüft.
Weiterlesen →Vom Plan zur Evaluation: der gesamte Projektlebenszyklus in sechs Tools
CaseCheck für den Business Case, PlanScore für den Projektplan, RisicoRadar für Risiken, StakeholderScan für das Umfeld, RapportageScore während der Durchführung und EvaluatieScore für die Evaluation im Nachhinein. Eine zusammenhängende Suite entlang des gesamten Projektlebenszyklus.
Weiterlesen →'Der gegenseitige Lernprozess befindet sich noch in einem Anfangsstadium' — was der Rechnungshof 2013 bereits sah
2013 stellte der niederländische Rechnungshof fest, dass die Lernfähigkeit des Staates bei IT-Projekten noch unreif war. Hat sich das inzwischen gebessert, oder erkennen wir das Muster noch immer in den meisten Organisationen?
Weiterlesen →Die Lücke zwischen Ex-ante und Ex-post: warum jedes große IT-Projekt vorab geprüft wird, und danach fast nie
Die Elias-Kommission sorgte dafür, dass große IT-Projekte vorab verpflichtend geprüft werden. Was danach damit geschieht, ist in den Niederlanden niemandem aufgetragen. Diese instrumentelle Lücke ist der schärfste Befund unserer Quellenrecherche.
Weiterlesen →Das CIPP-Modell von Stufflebeam stellt vier Fragen für einen strukturierten Rückblick
Context, Input, Process, Product. Das CIPP-Evaluationsmodell von Daniel Stufflebeam bietet ein methodisches Fundament für Projektevaluation — einschließlich einer Anforderung, die die meisten Evaluationsberichte auslassen: die Metaevaluation.
Weiterlesen →Gate 5: wie die britische Regierung unabhängig prüft, ob der versprochene Nutzen auch tatsächlich eingetreten ist
Die britische Infrastructure and Projects Authority kennt einen Assurance-Moment, der speziell nach der Lieferung prĂĽft, ob Nutzen realisiert wurde: Gate 5. Es ist eines der wenigen maĂźgeblichen Beispiele fĂĽr einen echten Ex-post-PrĂĽfmoment.
Weiterlesen →Dokumentieren ist nicht dasselbe wie Lernen
Ein Lessons-Learned-Bericht, der in einer Schublade verschwindet, ändert nichts. Williams (2007) untersuchte, warum Lehren aus Projekten selten in die breitere Politik einer Organisation einfließen — und was dafür tatsächlich nötig wäre.
Weiterlesen →Sechs OECD-DAC-Fragen für jede Projektevaluation
Relevance, coherence, effectiveness, efficiency, impact, sustainability. Die OECD-DAC-Kriterien wurden für die Entwicklungszusammenarbeit entwickelt, sind aber sechs Fragen, die in fast jede Projektevaluation gehören.
Weiterlesen →Die Governance der Nutzenrealisierung fällt nach der Lieferung zwischen zwei Stühle
Ein Business Case verspricht Nutzen. Ein Projekt wird abgeliefert. Und dann? In den meisten Organisationen fällt die Nutzenrealisierungs-Governance zwischen Stuhl und Bank — genau in dem Moment, in dem das Projektteam aufgelöst wird.
Weiterlesen →