Das Problem ist nicht, dass Programmteams nicht wissen, wie man einen Logframe ausfüllt. Die meisten können das. Das Problem ist, dass der Logframe routinemäßig als Compliance-Dokument konzipiert wird, um die Programmentwurfsanforderungen eines Spenders zu erfüllen, anstatt als Managementinstrument, das auf die tatsächlichen Entscheidungen zugeschnitten ist, die Programmleiter treffen müssen.
Wenn der Logframe ein Compliance-Dokument ist, wird er abgelegt und vergessen. Wenn er ein Managementinstrument ist, steht er im Mittelpunkt jeder vierteljährlichen Überprüfung, jeder Arbeitsplanrevision und jeder Entscheidung über die Umverteilung von Ressourcen. Die Gestaltung des letzteren erfordert einen völlig anderen Ausgangspunkt.
Was ein Logframe tatsächlich ist
Ein logischer Rahmen ist eine Matrix, die die Logik eines Programms in einem strukturierten, überprüfbaren Format darstellt. Die Standard-Vier-mal-Vier-Matrix enthält:
- Eine Projektbeschreibungsspalte die Hierarchie der Ergebnisse von Aktivitäten über Outputs, Outcomes und Impact
- Eine Indikatorenspalte die messbaren Nachweise, die zeigen, ob jede Ergebnisebene erreicht wurde
- Eine Spalte für die Verifizierungsmethoden die Datenquellen, aus denen die Indikatorwerte gesammelt werden
- Eine Annahmenspalte die Bedingungen außerhalb der Kontrolle des Programms, die gegeben sein müssen, damit die Ergebniskette funktioniert
Die in der Matrix verankerte Logik ist vertikal und horizontal. Vertikale Logik: Wenn Aktivitäten abgeschlossen sind, werden Outputs produziert; wenn Outputs produziert werden und Annahmen zutreffen, werden Outcomes erreicht; wenn Outcomes erreicht werden und Annahmen zutreffen, treten Impacts ein. Horizontale Logik: Jede Ergebnisebene hat spezifische, messbare Indikatoren mit definierten Datenquellen und Verifizierungsmethoden.
Beide Dimensionen müssen solide sein, damit der Logframe ein nützliches Instrument ist. Ein Logframe mit einer plausiblen vertikalen Logik, aber unmessbaren Indikatoren ist dekorativ. Ein Logframe mit messbaren Indikatoren, aber einer fehlerhaften vertikalen Logik, produziert Daten, die nicht mit Ergebnissen verknüpft werden können.
Die Ergebnis-Hierarchie: Jede Ebene verstehen
Aktivitäten
Aktivitäten sind das, was das Programm tut. Schulung von Gemeinde-Gesundheitspersonal. Konfiguration von DHIS2 Tracker für die Krankheitsüberwachung. Verteilung von insektizidbehandelten Netzen. Durchführung von Haushaltserhebungen.
Aktivitäten sind der Input der Ergebniskette, nicht das Ergebnis. Ein häufiger und kostspieliger Designfehler bei Logframes ist die Platzierung von Aktivitäten auf der Outcome-Ebene, wobei durchgeführte Schulungseinheiten so berichtet werden, als wären sie die Veränderung, die das Programm bewirken sollte. Schulung ist eine Aktivität. Eine Veränderung der Praxis von Gesundheitspersonal ist ein Outcome. Der Abstand zwischen beiden ist der Punkt, an dem die meisten Programmevaluierungen ihre Lücke finden.
Outputs
Outputs sind die direkten, greifbaren Produkte von Aktivitäten – die Dinge, die das Programm liefert. Anzahl des geschulten Gesundheitspersonals. Anzahl der erstellten Überwachungsberichte. Anzahl der erreichten Gemeinden. Anzahl der eingesetzten Datenerfassungsinstrumente.
Outputs stehen unter der direkten Kontrolle des Programms und sind typischerweise einfach zu messen. Sie sind notwendig für Outcomes, aber nicht ausreichend. Ein Programm, das alle geplanten Outputs liefert und keine Veränderung in der Zielpopulation bewirkt, ist nicht an der Umsetzung gescheitert – es ist am Design der Theorie des Wandels gescheitert.
Outcomes
Outcomes sind Veränderungen in Wissen, Fähigkeiten, Verhaltensweisen, Praktiken oder Systemen, die aus den Programmergebnissen resultieren. Gesundheitspersonal, das Falldefinitionen am Behandlungsort korrekt anwendet. Überwachungsdaten, die den staatlichen Epidemiologen innerhalb von 48 Stunden erreichen. LGA-Gesundheitsbeauftragte, die Dashboard-Daten in wöchentlichen Briefings nutzen.
Outcomes sind schwieriger zu messen als Outputs, nehmen länger in Anspruch, um sich zu materialisieren, und sind schwieriger einem einzelnen Programm zuzuordnen. Dies sind genau die Gründe, warum sie wichtiger sind. Ein Programm, das nur nach Outputs gemessen wird, kann auf dem Papier erfolgreich sein, während es keine Veränderung in der Welt bewirkt. Ein Programm, das nach Outcomes gemessen wird, kann dies nicht.
Eine vollständige Behandlung von Outcome-Indikatoren und deren Gestaltung finden Sie unter Wie man M&E-Indikatoren entwirft.
Impact
Impact ist die langfristige, bevölkerungsweite Veränderung, zu der das Programm beiträgt – typischerweise gemessen in Begriffen der Krankheitslast: Morbiditätsraten, Mortalitätsraten, Krankheitsinzidenz, behinderungsbereinigte Lebensjahre. Impact ist selten einem einzelnen Programm zuzuschreiben und operiert auf einer Zeitskala, die die meisten Programmfinanzierungszyklen überschreitet.
Im Logframe-Design entsteht hier eine praktische Spannung: Impact ist das, was letztendlich zählt, aber es ist nicht das, was ein dreijähriges Programm mit Sicherheit demonstrieren kann. Die Lösung besteht darin, den Logframe mit Impact als Richtungsziel zu entwerfen, während Outcomes rigoros gemessen werden. Wenn die Theorie des Wandels solide ist und Outcomes erreicht werden, wird Impact folgen – obwohl der Nachweis der Kausalität auf Bevölkerungsebene typischerweise ein separates Evaluationsdesign erfordert.
Gestaltung der Annahmen-Spalte: Die am meisten vernachlässigte Spalte
Die Spalte für Annahmen ist der Ort, an dem das Logframe-Design seine analytische Qualität offenbart. Die meisten Logframes, die ich überprüfe, listen Annahmen auf, die entweder trivial wahr sind („Regierung bleibt dem Programm verpflichtet“), nachweislich falsch („Gemeinden werden aktiv Gesundheitsdienste in Anspruch nehmen“) oder generisch genug, um auf jedes Programm in jedem Kontext anzuwenden.
Eine nützliche Annahme ist eine spezifische, überprüfbare Bedingung, die tatsächlich unsicher ist, die das Programm nicht kontrollieren kann und die für die Ergebniskette wichtig ist. Für ein Krankheitsüberwachungsprogramm in Westafrika umfassen echte Annahmen:
- Die Laborkapazität des staatlichen Referenzlabors hält einen ausreichenden Durchsatz aufrecht, um Proben innerhalb von fünf Werktagen zu verarbeiten
- Die Mobilfunkabdeckung in den Ziel-LGAs ist ausreichend für die DHIS2-Synchronisierung mindestens einmal pro Woche
- Das staatliche Gesundheitsministerium behält geschultes Überwachungspersonal für die Dauer des Programmzyklus im Amt
- Gemeinschaftsgesundheitshelfer erstellen monatliche Berichte konsistent ohne zusätzlichen finanziellen Anreiz
Dies sind Annahmen, weil sie unsicher sind. Einige von ihnen werden sich in einigen Kontexten als falsch erweisen. Wenn eine Annahme fehlschlägt, unterbricht sie die Kausalkette an der Stelle, an der sie sich befindet. Das frühzeitige Erkennen dieses Scheiterns durch systematische Überwachung wichtiger Annahmen – nicht nur der Programmindikatoren – ermöglicht es dem Programm, sich anzupassen, bevor die Ergebniskette zusammenbricht.
Integrieren Sie die Überwachung von Annahmen in Ihren M&E-Plan. Weisen Sie die Verantwortung für die Verfolgung jeder kritischen Annahme zu. Überprüfen Sie den Status der Annahmen bei vierteljährlichen Programmüberprüfungen zusammen mit den Indikatordaten.
Indikatorauswahl: Der horizontale Logiktest
Für jede Ebene der Ergebnis-Hierarchie muss der Indikator einen dreiteiligen Test bestehen:
- Misst er tatsächlich das Ergebnis, dem er zugeordnet ist? Ein Indikator, der die Output-Lieferung gegen ein Outcome-Ergebnis misst, produziert Output-Daten und nennt sie Outcome-Evidenz.
- Kann er durch die angegebenen Verifizierungsmethoden erfasst werden? Ein Indikator ohne eine plausible, erschwingliche Datenquelle ist kein Indikator – es ist ein Wunsch.
- Ist er empfindlich genug, um Veränderungen innerhalb des Programmzeitraums zu erkennen? Bevölkerungsweite Krankheitsinzidenzraten zeigen in einem zweijährigen Programm keine erkennbare Veränderung. Ein Zwischenindikator – Überwachungsempfindlichkeit, Untersuchungsfristen, Berichterstattungs-Vollständigkeit – wird dies tun.
Das dritte Kriterium wird am häufigsten verletzt. Programmdesigner wählen Indikatoren auf Impact-Ebene für Outcome-Zeilen aus, weil sie beeindruckend klingen. Das Programm erzeugt dann keine messbare Veränderung bezüglich dieser Indikatoren – nicht weil das Programm gescheitert ist, sondern weil die Indikatoren nicht empfindlich genug waren für das Ausmaß der Veränderung, das das Programm bewirken sollte.
Detaillierte Anleitungen zur Indikatorauswahl finden Sie im M&E-Glossar und unter Wie man M&E-Indikatoren entwirft.
Der Logframe in Programmüberprüfungen
Ein Logframe, der bei Programmüberprüfungstreffen nicht geöffnet wird, hat als Managementinstrument versagt, unabhängig davon, wie gut er technisch konzipiert ist.
In den WHO-Polio- und Überwachungsprogrammen, die ich unterstützt habe, ist der Logframe das erste Dokument, das bei jeder vierteljährlichen Programmüberprüfung geprüft wird. Die Überprüfungsstruktur folgt der Matrix:
- Überprüfung des Indikatorstatus: Für jeden Outcome- und Output-Indikator, wie ist der aktuelle Wert im Vergleich zum Ziel? Rot, Amber oder Grün? Wie ist der Trend?
- Überprüfung des Annahmestatus: Welche kritischen Annahmen halten noch? Welche haben sich geändert? Was sind die Auswirkungen auf die Ergebniskette?
- Arbeitsplananpassung: Basierend auf dem Indikatorstatus und Annahmenänderungen, welche Anpassungen sind für den Arbeitsplan für das nächste Quartal erforderlich?
- Entscheidungen zur Ressourcenumverteilung: Sind die Ressourcen den Aktivitäten zugewiesen, die am ehesten die zurückbleibenden Indikatoren voranbringen? Wenn nicht, welche Änderungen sind erforderlich?
Diese Struktur macht den Logframe zu dem, wofür er entworfen wurde: das analytische Rückgrat eines adaptiven Programmmanagements, kein statisches Planungsdokument.
Häufige Fehler beim Logframe-Design
Zu viele Indikatoren
Ein Logframe mit vierzig Indikatoren für ein dreijähriges Programm führt entweder zu einer Datenlast, die Programmressourcen verbraucht, oder wird mit geschätzten Werten gefüllt. Beschränken Sie die Matrix auf die zehn bis fünfzehn Indikatoren, die für Managemententscheidungen wirklich wesentlich sind. Für den Rest verwenden Sie einen separaten Überwachungsplan mit geringerer Messfrequenz.
Verwechslung von Outputs und Outcomes
Der häufigste Fehler im Logframe-Design. Abgeschlossene Schulungseinheiten sind ein Output. Die Verhaltensänderung bei geschultem Gesundheitspersonal ist ein Outcome. Geschultes Gesundheitspersonal ist ein Output. Gesundheitspersonal, das korrekte Falldefinitionen am Behandlungsort anwendet, ist ein Outcome. Diese Unterscheidungen sind wichtig, da sie festlegen, wofür das Programm verantwortlich ist und welche Nachweise es erbringen muss.
Baselines nach Programmstart festgelegt
Eine Baseline, die nach Beginn der Programmaktivitäten gemessen wird, ist keine Baseline. Es ist ein Zwischenpunkt. Ohne eine echte Baseline vor dem Programm ist es unmöglich, Veränderungen zu messen – nur den aktuellen Status zu beschreiben. Die Erfassung von Baseline-Daten muss abgeschlossen sein, bevor programmatische Aktivitäten, die die Indikatoren beeinflussen könnten, beginnen.
Ziele ohne Bezug zu Evidenz festgelegt
Willkürlich festgelegte Ziele – „Abdeckung um 20 % erhöhen“, weil 20 % ehrgeizig klingt – führen in herausfordernden Kontexten zu systematischem Zielverfehlen und in hochleistenden Kontexten zu systematischer Unterambition. Legen Sie Ziele basierend auf historischer Programmleistung, Bevölkerungsgröße, Ressourcenniveau und Vergleichsprogrammen fest. Siehe Ergebnisorientiertes Management für einen evidenzbasierten Rahmen zur Zielsetzung.
Der Logframe ist eine Theorie, keine Garantie
Jeder Logframe enthält eine Theorie darüber, wie die Welt funktioniert – wie Aktivitäten Outputs erzeugen, wie Outputs Outcomes erzeugen, wie Outcomes zu Impacts beitragen. Diese Theorie kann richtig oder falsch sein. Der Zweck der Überwachung ist es, die Theorie unter realen Bedingungen zu testen und anzupassen, wenn die Evidenz zeigt, dass sie nicht zutrifft.
Ein Programm, das eine fehlerhafte Theorie des Wandels rigoros umsetzt, wird Outputs treu produzieren und Outcomes, die von der Ergebniskette abweichen. Der Logframe ist das Instrument, das diese Abweichung früh genug sichtbar macht, um darauf reagieren zu können.
Das ist es, was das Data-to-Decision-Modell fordert: nicht nur, dass Daten gemäß einem Plan gesammelt werden, sondern dass sie eine Echtzeit-Rückkopplungsschleife zwischen Evidenz und Aktion bilden.