Nutzenmanagement

Zweck

Die Infrastructure and Projects Authority (IPA) der britischen Regierung definiert Nutzenmanagement als Identifikation, Definition, Verfolgung, Realisierung und Optimierung von Nutzen. Ein Nutzen ist dort eine messbare Verbesserung, die mindestens eine Anspruchsgruppe als Vorteil wahrnimmt und die zu einem Ziel der Organisation beiträgt. Die Technik macht aus dem Versprechen eines Business Case einen Nutzen, der im Tagesgeschäft der Organisation gemessen wird.

Der Nutzen folgt aus dem, was das Projekt liefert. Er ist nicht das Gelieferte selbst. Ein Online-Schalter ist ein Liefergegenstand; die eingesparten Besuche am Schalter sind der Nutzen. Peppard, Ward und Daniel leiten daraus den Grundsatz der Technik ab: Eine Technologie hat keinen Wert an sich. Nutzen entsteht, wenn Menschen anders arbeiten. Nur die Linienverantwortlichen und die Benutzenden können ihn erzielen. Die drei Autoren untersuchen Informatikinvestitionen. Die Überlegung gilt für jede Veränderung der Arbeitsweise.

Die Technik beantwortet die Frage, die der Business Case offenlässt: Bringt die finanzierte Veränderung, was sie versprach? Der Business Case und die Kosten-Nutzen-Analyse bewerten die Veränderung vor dem Finanzierungsentscheid. Das Nutzenmanagement läuft nach dem technischen Projektabschluss weiter, bis jeder Nutzen erreicht oder aufgegeben ist. Die IPA benennt den umgekehrten Irrtum: den verbreiteten Glauben, Nutzenmanagement beginne und ende mit der Bewertung des Business Case.

Das Arbeitsergebnis ist ein Satz laufend nachgeführter Dokumente: das Nutzenregister, ein Profil je Nutzen, der Realisierungsplan, das Übergabeprotokoll und die Nutzenberichte. Der PMBOK Guide beschreibt ein einziges Dokument: den Nutzenmanagementplan. Er ordnet ihn neben dem Business Case den Geschäftsdokumenten zu, weil beide vor dem Projekt entstehen und nach seinem Abschluss weiter verwendet werden.

Einsatz

Wann einsetzen

• Genehmigter Business Case: aus jedem versprochenen Nutzen eine namentliche, gemessene und terminierte Verpflichtung machen.
• Veränderung, deren Wert von der Nutzung abhängt: neues System, neuer Prozess oder Reorganisation, die die Teams übernehmen müssen.
• Projekt vor seinem Nutzen abgeschlossen: die Übergabe an die Linienverantwortlichen und die Messung in den Monaten nach dem Abschluss organisieren.
• Phasenende: prüfen, ob der erwartete Nutzen die nächste Phase noch rechtfertigt. In HERMES entscheidet der Auftraggeber über jede Phasenfreigabe.
• Programm oder Portfolio: Nutzen verfolgen, den mehrere Projekte gemeinsam für dasselbe Ziel erzeugen.
• Umstrittener Nutzen: Ein gemessener Ausgangswert zeigt, ob das Problem besteht, bevor das Budget gebunden wird.

Wann nicht einsetzen

• Veränderung mit kleinem Budget: Die Verfolgung kostet mehr als die Abweichung, die sie aufdecken würde; Akzeptanzkriterien, die bei der Abnahme geprüft werden, genügen.
• Compliance oder gleichwertiger Ersatz: Niemand ändert seine Arbeitsweise; das Serviceniveau mit Metriken und KPI verfolgen.

Beschreibung

Nutzen, Nachteil, Eigner

Peppard, Ward und Daniel nennen eine Bank, die ein CRM-System für 10 Millionen Dollar termin- und budgetgerecht geliefert hat. Das System brachte keinen unmittelbaren Nutzen. Die Bank hatte die Veränderungen der Arbeitsweise nicht identifiziert, die dieser Nutzen verlangte. Sie hatte sich auf die Einführung der Technologie konzentriert.

Ein Nutzen, der sich nicht messen lässt, lässt sich nicht geltend machen. "Höhere Zufriedenheit der Einwohnerinnen und Einwohner" wird zum Nutzen, sobald feststeht, welcher Indikator sie misst, aus welcher Quelle und wie oft.

Ein Nachteil (englisch disbenefit) ist eine messbare Verschlechterung, die eine Anspruchsgruppe als negativ wahrnimmt. Die IPA verlangt, ihn mit Messgrösse und Eigner wie einen Nutzen zu steuern. Sie grenzt ihn vom Risiko ab: Der Nachteil ist erwartet; das Risiko ist ungewiss. Dieselbe Veränderung kann für eine Gruppe ein Nutzen und für eine andere ein Nachteil sein. Ein Schalter, der samstags schliesst, spart Personalstunden. Die Einwohnerinnen und Einwohner, die unter der Woche arbeiten, verlieren dafür Stunden. Ein Nachteil, den der Business Case verschweigt, taucht in den Beschwerden wieder auf.

Jeder Nutzen hat einen Eigner: die Führungsperson in der Linie, die die Veränderung der Arbeitsweise herbeiführen muss. Peppard, Ward und Daniel schreiben, dass der Eigner für den Wert einsteht, den der Business Case dem Nutzen zuschreibt. Ein Nutzen, der der Projektleitung oder der Informatik zugeteilt ist, hat keinen Eigner: Keine von beiden führt die Personen, die anders arbeiten müssen. Laut IPA steht der Auftraggeber für den Business Case und den Nutzen ein. Der Leitfaden nennt ihn Senior Responsible Owner; Auftraggeber ist der Begriff von HERMES. Die Nutzeneigner realisieren den Nutzen. Eine Nutzenmanagerin oder ein Nutzenmanager steuert den Prozess, führt die Dokumente und bereitet die Berichte vor. Eine RACI-Matrix hält diese Aufteilung für jede Tätigkeit fest.

Der Zyklus

Die IPA beschreibt sechs Praktiken. Sie folgen nicht zwingend aufeinander. Der Leitfaden wiederholt sie in jeder Projektetappe. Sein Zyklus ist auf jenen von Managing Benefits der APMG abgestimmt. Die IPA hält fest, dass ihr Leitfaden nicht präskriptiv ist: Jede Organisation passt die Dokumente der Grösse des Vorhabens an.

Erfolg definieren

Bevor sie Nutzen suchen, verknüpfen der Auftraggeber und die Geschäftsleitung die Veränderung mit den Zielen der Organisation. Sie legen fest, woran sie den Erfolg erkennen. Peppard, Ward und Daniel stellen die Fragen, die von dort zum Plan führen:

1. Warum müssen wir uns verbessern?
2. Welche Verbesserungen sind nötig oder möglich?
3. Welchen Nutzen zieht jede Anspruchsgruppe daraus und wie wird er gemessen?
4. Wer ist Eigner jedes Nutzens?
5. Welche Veränderungen der Arbeitsweise braucht es, um den Nutzen zu erzielen?
6. Wer ist für jede Veränderung verantwortlich?
7. Wie und wann lassen sich diese Veränderungen umsetzen?

Die letzten drei Fragen trennen die Technik von einer Rentabilitätsrechnung. Sie verbinden jeden Nutzen mit den Veränderungen, die ihn erzeugen. Das Benefits Dependency Network geht von den Zielen aus und zeichnet diese Verbindung von rechts nach links.

Identifizieren und quantifizieren

Das Team identifiziert den Nutzen in einem Workshop mit den wichtigsten Anspruchsgruppen. Jeder Nutzen erhält eine eindeutige Kennung, die ihn vom Register bis zu den Berichten begleitet. Das Team priorisiert die Nutzen und ordnet sie dann den Kategorien zu, die die Organisation verwendet, zum Beispiel finanziell oder nicht finanziell, Budgeteinsparung oder Kapazitätsgewinn. Die Kategorien der IPA gelten für die britische Regierung; eine Schweizer Organisation übernimmt ihre eigenen.

Jede Messgrösse erhält einen Ausgangswert. Er wird beim Projektstart erhoben, bevor das Projekt das gemessene Niveau verändert. Er belegt, dass das Problem besteht. Ausserdem liefert er den Startpunkt des Gewinns. Ein Wert, der nach Arbeitsbeginn erhoben wird, misst eine Lage, die das Projekt bereits gestört hat: Ein Team, das seine Mitarbeitenden auf dem neuen System schult, leistet während der Schulung weniger. Der später gemessene Gewinn erscheint dann grösser, als er ist.

Jeder Nutzen erhält einen bezifferten und terminierten Zielwert. Solange die Variante nicht gewählt ist, lässt die IPA "noch festzulegen" zu. In dieser Phase werden die vorgesehenen Eigner benannt.

Beziffern und bewerten

Das Team rechnet den quantifizierten Nutzen in Franken um, wo der Gewinn einen bekannten Preis hat. Diese Beträge fliessen in die Kosten-Nutzen-Analyse und in den Business Case ein. Eine frei gewordene Stunde wird nur dann zur Budgeteinsparung, wenn die Organisation die Stelle streicht oder auf eine Ausgabe verzichtet. Wird sie anderen Aufgaben zugewiesen, bleibt sie ein Kapazitätsgewinn. Das Register führt sie als solchen.

Die Falle dieser Praxis ist die Überschätzung. Peppard, Ward und Daniel zitieren eine Umfrage bei den 200 grössten britischen Unternehmen: 47 Prozent der Antwortenden gaben zu, den Nutzen überschätzt zu haben, um die Genehmigung zu erhalten. Der Eigner, der den Zielwert unterschreibt, entschärft diese Falle, weil er nach dem Abschluss dafür einsteht.

Realisierung planen

Der Realisierungsplan legt für jeden Nutzen fest, wer misst, mit welcher Quelle, wie oft und vor welchem Gremium. Die nötigen Daten gehen in die Systemanforderungen und in die Verträge mit den Lieferanten ein. Einen Indikator, dessen Extraktion niemand vorgesehen hat, kann nach der Inbetriebnahme niemand messen. Die Abhängigkeiten des Nutzens kommen ins Projektregister für Risiken, Massnahmen, Probleme und Entscheide. Die Risiken für einen Nutzen fliessen wie jedes andere Risiko in die Risikoanalyse und das Risikomanagement ein.

Vor der Übergabe genehmigt das Gremium, das den endgültigen Business Case genehmigt, auch den Plan mit den Kosten der Messung, den Rollen und der Governance. Ist seit dem Projektstart viel Zeit vergangen, werden die Ausgangswerte neu erhoben.

Der Nutzenmanagementplan des PMBOK Guide enthält den angestrebten Nutzen, die strategische Ausrichtung, den Zeitrahmen der Realisierung, den Nutzeneigner, die Metriken, die Annahmen und die Risiken. Der PMBOK Guide hält fest, dass dieser Plan iterativ erarbeitet und nachgeführt wird.

Realisieren

Bei der Übergabe unterschreiben der Auftraggeber und jeder Eigner das Übergabeprotokoll. Damit geht die Verantwortung für den Nutzen vom Projekt an die Linienverantwortlichen über. Danach löst sich das Projekt auf. Ohne diese Unterschrift liest niemand mehr das Register.

Eine Teillieferung erzeugt manchmal schon während des Projekts Nutzen; er wird mit den Kosten und Meilensteinen verfolgt. Der übrige Nutzen wird so bald wie möglich nach der Lieferung gemessen. Ändert die Veränderung die Arbeitsweise, rät die IPA, mindestens sechs Monate bis zu den ersten Messungen zu warten. Eine zu früh erhobene Messung erfasst die Lernphase. Sie erklärt eine Veränderung für gescheitert, die noch nicht gegriffen hat.

Die Berichte gehen an ein Gremium, das einen realisierten Nutzen bestätigen und eine Korrekturmassnahme finanzieren kann. Ein Ausschuss ohne Handlungsbefugnis nimmt die Zahlen zur Kenntnis und ändert nichts. Jeder Bericht ergänzt die Daten mit einem Kommentar: warum die Abweichung, welche Massnahme, welche nächste Messung. Der Projektstatusbericht übernimmt diese Zahlen, solange das Projekt besteht.

Leistung beurteilen

Die Berichte laufen weiter, bis jeder Nutzen erreicht oder aufgegeben ist. Eine Überprüfung nach der Inbetriebnahme beantwortet die Fragen der IPA. Wurde der Business Case eingehalten? War der Prozess des Nutzenmanagements wirksam? War sein Aufwand angemessen? Waren die Modelle und Annahmen zutreffend? Welche Lehren lassen sich ziehen? Die Messwerte ersetzen dann die Schätzungen in den Nutzenmodellen, die den nächsten Business Cases dienen.

In der Schweiz sieht HERMES 2022 diese Kontrolle vor. Die Projektschlussbeurteilung bestimmt Inhalt und Termine der Projekterfolgskontrolle. Einige Zeit nach dem Abschluss kann die Anwendungsorganisation prüfen, ob die Wirkung eingetreten ist, die der Auftraggeber erwartete.

Die Falle der Überprüfung ist die Alibiübung. Die IPA nennt Openreach, deren Vorlage für den Business Case verlangt, zwei Fälle aus Lessons Learned anzuführen. Das Team, das den nächsten Business Case schreibt, muss die früheren Überprüfungen lesen. Damit hört die Überprüfung auf, eine Formalität zu sein.

KI-Überlegungen

Ein Sprachmodell beschleunigt die Dokumentationsarbeit. Es zieht aus einem Business Case und aus Workshopnotizen eine erste Liste von Nutzen, trennt sie von den Liefergegenständen und schlägt für jeden Nutzen einen Indikator und eine Datenquelle vor. Es liest das Register und meldet Zeilen ohne Eigner, ohne Ausgangswert oder ohne Datum. Es entwirft den Kommentar eines Berichts aus den Zahlen des Monats und fasst die Befunde mehrerer Überprüfungen nach der Inbetriebnahme zusammen.

Es legt weder einen Zielwert noch einen Eigner fest. Der Zielwert ist eine Verpflichtung, die der Eigner unterschreibt; ein Wert, den ein Modell vorschlägt, verpflichtet niemanden. Ebenso wenig entscheidet es, ob eine Abweichung vom Projekt stammt oder von einem anderen Faktor wie einem Bevölkerungswachstum oder einer Gesetzesänderung. Diese Zuordnung verlangt Kenntnis der Verhältnisse vor Ort. Ein Modell übernimmt zudem den Optimismus des vorgelegten Textes und bringt ihn in Form. Schliesslich betreffen Messdaten oft Personen: Dossiers von Einwohnerinnen und Einwohnern, Bearbeitungszeiten je mitarbeitende Person. Ein Unternehmen oder die Bundesverwaltung wendet das Datenschutzgesetz des Bundes (DSG) an. Eine Gemeinde oder ein Kanton wendet das kantonale Gesetz an; im Kanton Waadt ist es das LPrD. Das jeweilige Gesetz bestimmt die Bedingungen für eine Übermittlung an einen gehosteten Dienst.

Beispiele

Nach dem Projektende führt der Eigner das Nutzenprofil nach und vergleicht darin jede Messung mit dem Ausgangswert und dem Zielwert. Eine Waadtländer Gemeinde schaltet die Zuzugs- und Wegzugsmeldung online. Das fiktive Profil des Nutzens B-03 deckt das erste Jahr nach der Inbetriebnahme ab.

Das Profil verbucht die frei gewordenen Stunden als Kapazitätsgewinn. Zu Franken werden sie nur, wenn die Gemeinde eine Stelle streicht oder auf eine Ausgabe verzichtet. Der Business Case hat das nicht vorgesehen. Der Nachteil lag nach sechs Monaten über seiner Obergrenze und fiel danach wieder darunter: Ohne diese Zeile hätte der Ausschuss nur den Rückgang der Besuche gesehen.

Visualisierungen

Der Zyklus ordnet die Praktiken vor, während und nach dem Projekt an. Das Übergabeprotokoll markiert darin den Moment, in dem die Verantwortung in andere Hände übergeht. Die Kurve des Beispiels zeigt die Verzögerung zwischen der Inbetriebnahme und dem Nutzen. Sie verortet die monatlichen Schalterbesuche zwischen Ausgangswert und Zielwert.

Kosten

Werkzeuge

Für das Register und die Profile eines mittelgrossen Projekts genügt eine Tabellenkalkulation: eine Zeile je Nutzen, eine Spalte je datierte Messung. Eine geteilte Liste in SharePoint oder einem ähnlichen Werkzeug hält das Register für die Eigner zugänglich, nachdem sich das Projektteam aufgelöst hat. Werkzeuge für das Projektportfoliomanagement führen Nutzenregister, die mit Projekten und Programmen verknüpft sind. Sie lohnen sich, wenn mehrere Projekte zum selben Nutzen beitragen. Beim Abschluss übergibt das Team das im Portfoliowerkzeug geführte Register an die Linienverantwortlichen. Ohne diese Übergabe geht das Register verloren, sobald sich das Team auflöst.

Die Messungen stammen aus den Fachanwendungen: Warteschlangensteuerung, ERP, Gesuchsverwaltung. Ein Dashboard-Werkzeug wie Power BI oder Tableau liest diese Quellen und erzeugt die Kurven der Berichte.

Quellen

• HM Government, Infrastructure and Projects Authority, Guide for Effective Benefits Management in Major Projects, Oktober 2017: die Definition von Nutzen, Nachteil und Nutzenmanagement (§3); die sechs Praktiken des Zyklus, ihre Wiederholung in jeder Etappe, der Ausgangswert, der Zielwert, der Plan, die Übergabe, die Frist von sechs Monaten vor der Messung und die Überprüfung nach der Inbetriebnahme (§7); die Rollen (§8); die Dokumente (§9); der Fall Openreach.
• Joe Peppard, John Ward und Elizabeth Daniel, "Managing the Realization of Business Benefits from IT Investments", MIS Quarterly Executive, 6(1), 2007: die Grundsätze des Nutzenmanagements, die Verantwortung der Linienverantwortlichen, die sieben Fragen des Plans, der Fall der Bank und die Umfrage zur Überschätzung des Nutzens (Ward, Taylor und Bond, 1996, von den Autoren zitiert).
• PMI, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8. Auflage, Abschnitt 4 Inputs and Outputs: der Nutzenmanagementplan, seine Elemente, sein iterativer Charakter und seine Stellung als Geschäftsdokument neben dem Business Case.
• Schweizerische Eidgenossenschaft, Bundeskanzlei, HERMES 2022, Referenzhandbuch Projektmanagement: die Aufgabe 5.4.3.35 Projektabschluss vorbereiten für die Erfolgskontrolle nach dem Abschluss; das Ergebnis 4.4.1.35 Projektschlussbeurteilung für deren Inhalt und Termine; die Entscheide des Auftraggebers (5.1.2.2 und 7.4.1) für die Phasenfreigabe.