Output vs. Outcome

Da war er wieder. Dieser Satz, der mich zusammenzucken ließ. „Wir müssen uns ja entlasten.“ Obwohl ich nun schon einige Jahre im Projektgeschäft bin, überrascht es mich immer wieder, wie unterschiedlich die Sichtweisen sein können.

„Das Ziel des Projektes ist ein bestellbares Produkt“ vs. „Das Ziel des Projektes ist es, die Kundenzufriedenheit um 2 Prozentpunkte zu steigern (mit Hilfe eines Produktes)“.

„Wir sind fertig, wenn das Produkt bestellbar ist“ vs. „wir sind fertig, wenn die Kundenzufriedenheit um 2 Prozentpunkte gestiegen ist“.

Ich habe in einem älteren Artikel schon einmal die Notwendigkeit beschrieben, für den Projekterfolg unbedingt auch den Nutzen zu berücksichtigen. Ein Projekt, welches perfekt und wie geplant durchgeführt wurde, aber nicht den erwarteten Nutzen abliefert, ist aus Sicht des Unternehmens ein Fehlschlag. Dies gilt aber nicht nur für Projekte, sondern für alles, was wir im Projekt tun. Ich plädiere für eine andere, erweiterte Denkweise!

Lassen Sie uns die unterschiedlichen Denkweisen einmal systematisch am Beispiel des ÖPNV durchgehen.

Input / Einsatz

Was ist das?

Mit Einsatz bezeichnen wir alles, was wir in das Projekt hineinstecken. Dies sind üblicherweise Arbeitstage, Softwarelizenzen u.ä. In unserem ÖPNV Beispiel könnten wir festhalten, dass wir 1.000 Tage gearbeitet haben.

Was messe ich?

Die Messung des Inputs ist meist einfach – ich kann die Arbeitstage bzw. Stunden einfach aufschreiben und mit einem Stundensatz multiplizieren, Kosten für Lizenzen o.ä. sind ebenfalls direkt ersichtlich. Hilft uns die Messung des Inputs, um den Projekterfolg zu bestimmen? Aus meiner Sicht nein – es erinnert mich eher an das Bonmot „am Ende des Geldes ist noch ein Stück Monat übrig“.

Eine Anmerkung am Rande: Die meisten Entlohnungssysteme in Unternehmen orientieren sich am Input – Mitarbeiter werden nach ihrem Input (=Arbeitszeit) bezahlt, unabhängig davon, ob ihre Arbeit dem Unternehmen auch nützt. Warum? Weil der Input leicht zu messen ist.

Activities / Tätigkeiten

Wenn bestimmte Inputs vorhanden sind, dann können bestimmte Activities durchgeführt werden.

Was ist das?

Die Tätigkeiten im Projekt sind genau das: alles, was das Projektteam tut. Beispielsweise ein Fachdesign erstellen, Code produzieren, Tests durchführen. In unserem ÖPNV Beispiel könnten wir festhalten, dass wir für eine Anwendung entwickelt und getestet haben.

Was messe ich?

Auch die Tätigkeiten sind leicht zu erfassen – Sie können das Team einfach beobachten oder nachfragen. Hilft die Messung der Tätigkeiten? Wieder nein – Sie wissen nicht, ob die Tätigkeiten überhaupt abgeschlossen sind.

Output / Ergebnis

Wenn bestimmte Activities durchgeführt werden, dann erwarte ich einen bestimmten Output.

Was ist das?

Der Output (Projektergebnis, deliverables) beschreibt die Dinge, die nach der Projektdurchführung vorhanden sind, beispielsweise eine funktionsfähige Anwendung (das Was). In unserem Beispiel könnten wir einen Anzeiger für Bushaltestellen entwickelt haben, der die Ankunft des nächsten Buses anzeigt.

Was messe ich?

Ich messe die konkreten, abzählbaren Projektergebnisse. Diese werden üblicherweise zu Projektbeginn vereinbart. Die Erreichung der Projektergebnisse liegt vollständig in der Hand des Projektteams und ist leicht (und objektiv) zu überprüfen.

Outcome / (Aus-)Wirkung

Wenn ein Output vorliegt, dann kann dies zu einem Outcome führen.

Was ist das?

Die Auswirkung beschreibt üblicherweise den Nutzen des Projektes (das Warum). In unserem Beispiel könnte ein Outcome eine Verbesserung der Kundenzufriedenheit sein.

Was messe ich?

Jetzt wird etwas kniffliger... Das Outcome ist erstens nicht immer leicht zu messen. Zweitens ist oft nur eine subjektive Einschätzung möglich. Drittens kann zwischen Herstellung des Outputs und Eintritt des Outcomes recht viel Zeit liegen. Viertens besteht nicht immer ein kausale 1-zu-1 Beziehung zwischen Output und Outcome (Ausfälle der Busflotte zieht die Kundenzufriedenheit nach unten, unabhängig von den Anzeigern).

Impact / (Ein-) Wirkung

Wenn es ein Outcome gibt, kann dies langfristig zu einem Impact führen.

Was ist das?

Impact beschreibt eine Wirkung über die eigentliche Zielgruppe hinaus. In unserem Beispiel könnte die höhere Kundenzufriedenheit dazu führen, dass noch mehr Menschen den ÖPNV nutzen und die Schadstoffbelastung sinkt.

Erkenntnisse

1. Die dargestellte Kausalkette sollte uns bewusst sein. Dies gilt insbesondere für die Definition eines Projektziels – verspreche ich einen Output oder ein Outcome.
2. Es ist problemlos möglich, einen Output ohne Outcome zu erreichen. Daher mein eingangs erwähntes „Zusammenzucken“.
3. Es ist problemlos möglich, ein bestimmtes Outcome mit unterschiedlichen Outputs zu erreichen. Die Festlegung auf einen bestimmten Output (Deliverables) zu Projektbeginn verbaut unter Umständen einfachere Lösungen, die erst im Projektverlauf sichtbar werden (siehe auch mein Artikel zu Value Trees).
4. Ohne Outcome gibt es keine Notwendigkeit für Output. Wenn sich die Kundenzufriedenheit durch Busanzeiger nicht erhöht, brauche ich keine Busanzeiger.
5. Die Kausalkette gilt in unterschiedlichen Dimensionen, nicht nur für Projekte. Ich kann das Feature „Zahlung mit PayPal“ umsetzen (output) oder die adressierbare Kundengruppe um 12% erhöhen (outcome). Ich kann den Sprint 14 erfolgreich abschließen (output) oder eine Designvariante validieren (outcome). Ich kann eine User Story abschließen (output) oder den Aufruf der PayPal-Zahlungsübersicht um 70% schneller machen (outcome).

Ich plädiere für eine andere Denkweise! Der Fokus auf Outcomes führt vielleicht dazu, dass sich die geplanten Projektergebnisse verändern. Langfristig führt es aber zu erfolgreicheren Projekten und glücklicheren Kunden.