Das Projekt endet. Die Veränderung nicht. Wer übernimmt jetzt?

In einer Post-Merger-Integration habe ich das Teilprojekt geleitet, das die Finanzprozesse zweier Gesellschaften zusammenführte und in ein neu aufgebautes Shared-Service-Center verlagerte. Das neue Verfahren war vor dem Stichtag von allen Seiten freigegeben. Zwei Jahre lang blieb der Parallelbetrieb trotzdem das beherrschende Thema, und zwar wegen der Fälle, die sich im neuen Verfahren nicht abbilden ließen. Sie tauchten erst im Betrieb auf, und mit jedem stellte sich dieselbe Frage: Nach welchem Verfahren arbeiten wir jetzt?

Meist steht sogar im Abschlussbericht, wer dafür zuständig ist: eine Fachbereichsleitung. Nur hat sie nichts in der Hand, wenn der erste Anruf kommt. Keine Regel, die den Fall abdeckt. Kein Budget, um jemanden damit zu beauftragen. Keine Zahl, an der sie sehen könnte, wie oft das vorkommt. Eine Übergabe kann formal abgeschlossen sein, ohne dass jemand die Verantwortung übernommen hat. Diesen Unterschied macht eine einzige Frage sichtbar: Wenn morgen etwas nicht funktioniert — wen rufen wir an?

Die Regelwerke kennen den Übergang — und delegieren ihn

Der naheliegende Einwand lautet, hier werde eine Lücke erfunden, die es nicht gibt. Die Regelwerke schweigen tatsächlich nicht: Sie beschreiben den Übergang, und eines davon deckt genau diesen Fall ab. In der ICB4 heißt es im Kompetenzelement „Change und Transformation“:

„In vielen Fällen werden aufgrund eines Projekts Veränderungen veranlasst und organisiert. Das Projekt endet dann jedoch, bevor die daraus resultierenden Vorteile nutzbringend eingesetzt werden können.“

PRINCE2 macht im Prozess „Ein Projekt abschließen“ die Abnahme durch die Betriebs- und Wartungsumgebung zur Bedingung, gibt offene Punkte als Empfehlungen für Folgeaktionen weiter und setzt Termine für Nutzenüberprüfungen nach Projektende. Das IT-Service-Management hat für diese Phase seit ITIL v3 einen eigenen Begriff: Early Life Support, mit Abnahmekriterien für den Betrieb und einer benannten Rolle, dem Service Owner. Die Modelle des Veränderungsmanagements enden nicht mit der Einführung, sondern mit dem Verankern: bei Lewin das Wiedereinfrieren, bei Kotter das Verankern in der Kultur, bei Prosci die Phase „Sustain Outcomes“ samt Übertragung der Verantwortung. Und das Programmmanagement hat dafür eine Rolle: den Business Change Manager aus dem Fachbereich.

Wer hier eine Beschreibungslücke behauptet, hat nicht gelesen. Die Lücke liegt woanders: beim Empfänger. Jedes Prozess- und Rollenmodell benennt einen Empfänger, und keines kann diese Rolle selbst besetzen; die ICB4 als Kompetenzstandard definiert hingegen keine entsprechende Empfängerrolle.

Warum die Empfängerrolle im Einzelprojekt unbesetzt bleibt

PRINCE2 sieht die Übergabe an eine Betriebs- und Wartungsumgebung vor und benennt mit dem Benutzervertreter (Senior User) sogar eine Person, die den Nutzen nach dem Abschluss verantwortet. Nur ist das eine Rechenschaftspflicht gegenüber dem Unternehmens- oder Programmmanagement; Budget und Weisungsrecht in der Linie bringt die Rolle nicht mit, und die Nutzenüberprüfung nach Projektende liegt ebenfalls dort. Ist das Projektergebnis kein System, sondern ein Verfahren in der Sachbearbeitung, gibt es eine solche Betriebsumgebung häufig nicht. Das IT-Service-Management setzt eine Service-Management-Organisation voraus, mit Servicedesk und Service Owner. Diese Struktur müsste für ein Verfahren in der Sachbearbeitung erst geschaffen werden. Die Modelle des Veränderungsmanagements übergeben die Verantwortung an die Linie. Die gibt es; doch das Mandat derer, die die Veränderung verankern sollen, endet oft mit der Projektlaufzeit. Der Business Change Manager schließlich braucht ein Programm, nicht nur ein Projekt; Übergang und Folgekosten sind dort im Business Case eingeplant.

Vier benannte Empfängerrollen, von denen im Einzelprojekt keine zuverlässig besetzt ist, ergeben in der Praxis keinen Empfänger. Das Problem heißt Delegation ohne Empfänger.

Man könnte sagen: Dann muss das Projekt die Struktur eben schaffen. Doch kein Regelwerk schreibt das in den Projektauftrag; jedes setzt die Struktur als vorhanden voraus. Hineinschreiben kann diese Aufgabe nur, wer den Auftrag erteilt. Die ICB4 bestätigt das von der anderen Seite. Die Aufgabe, eine Veränderung aufrechtzuerhalten und einen Rückfall zu verhindern, steht dort ausdrücklich (4.5.13.4). Einen Übergang von Verantwortung beschreibt sie dagegen nur für den Vertragsfall, vom Auftragnehmer auf den Projekteigner (4.5.10.6). Wer die Veränderung innerhalb der eigenen Organisation weiterträgt, bleibt unbenannt; ein Kompetenzstandard muss das auch nicht leisten.

Am deutlichsten wird die Leerstelle an einem Punkt, der in keiner Übergabeliste steht: an der Messung. Für einen IT-Service gibt es sie meist schon. Das Ticketsystem erzeugt Zahlen, ohne dass jemand sie erheben müsste, der Servicedesk ist der Kanal, und der Service Owner liest sie. Das hat die Organisation für den Service eingerichtet; ein neues Verfahren in der Sachbearbeitung hat nichts davon: Es erzeugt keine Tickets, und einen Servicedesk gibt es nicht. Wer nach drei Monaten wissen will, ob es funktioniert, hat keine Quelle, es sei denn, das Projekt hat eine geschaffen. Deshalb gehört zur Übergabe: eine Anlaufstelle für Rückfragen, eine Zählung der Fälle, die am neuen Verfahren vorbei bearbeitet werden, und eine Person, die beides dauerhaft verantwortet. Fehlen sie, bleibt die im Abschlussbericht terminierte Nutzenüberprüfung eine Verabredung ohne Datengrundlage.

Die Übernahmeprüfung: fünf Punkte vor dem Abschluss

Vor dem Abschluss lässt sich das prüfen. Die Reihenfolge der fünf Punkte folgt einer Prüflogik: Wer beim Geld anfängt, verhandelt Beträge für eine Aufgabe, die noch keinen Träger hat. Als erfüllt gilt ein Punkt nur mit Nachweis, und ein Nachweis besteht aus drei Teilen: einem Dokument, in dem die Aufgabe steht, einer benannten Person, die die Stelle tatsächlich innehat, und einer Vertretung. Eine Zuständigkeit, die nur einer Organisationseinheit oder einer unbesetzten Stelle zugeordnet ist, genügt der Form, klärt aber nicht, wer morgen den Anruf entgegennimmt.

Prozessverantwortung. Wer verantwortet das Verfahren dauerhaft? Steht die Aufgabe in einer Stellenbeschreibung, mit Vertretung — und was ist dafür weggefallen? Die Nachfrage, die in Abschlusssitzungen fehlt: Wer geht ans Telefon, wenn diese Person im Urlaub oder krank ist, und kennt die Vertretung die Regel?

Regel. Wo ist das neue Verfahren verbindlich beschrieben, und ab welchem Datum gilt das bisherige nicht mehr? Solange die Dienst- oder Prozessanweisung noch abgestimmt wird: Was gilt bis zur Unterschrift? Und wer darf die Regel später ändern, ohne dass ein Gremium oder die Personalvertretung erneut zustimmen muss? Hat die aufnehmende Seite das Mandat, das bisherige Verfahren außer Kraft zu setzen — auch gegen eine operative Leitung, der das gerade ungelegen kommt?

Geld. Welches Produktkonto, welcher Haushaltstitel oder welche Kostenstelle trägt die laufenden Kosten? In öffentlichen Verwaltungen gehört diese Frage in die Haushaltsanmeldung und nicht an das Projektende; wer sie später stellt, findet die Mittel dafür erst im Haushalt des Folgejahres. Soll externe Unterstützung nach dem Abschluss abrufbar bleiben, gehört das Stundenkontingent als Option in Ausschreibung oder Rahmenvertrag; nachträglich ist es nur über eine Auftragsänderung oder eine eigene Vergabe zu haben.

Betrieb. Wer nimmt Rückfragen entgegen, und wer bearbeitet die Fälle, die nicht ins neue Verfahren passen? In welcher Frist kommt eine Antwort? Wer weist neue Mitarbeitende ein, wenn das Projektteam abgezogen ist? Und wer entscheidet verbindlich, wenn die prozessverantwortliche Person und die Anlaufstelle unterschiedlicher Meinung sind?

Messung. Woran lässt sich ablesen, wie viele Fälle am neuen Verfahren vorbeilaufen? Wer wertet diese Zahl aus, und zu welchem Termin wird der Nutzen überprüft?

Diese fünf Fragen lassen sich in jeder Abschlusssitzung stellen. Wirkung entfalten sie erst, wenn jemand den Nachweis verlangt und einen Ausnahmefall durchspielt, statt sich Zusagen anzuhören: „Nennen Sie einen Fall, den das neue Verfahren nicht abdeckt. Wer entscheidet dann, auf welcher Grundlage, und wer verantwortet die Entscheidung anschließend?“ Ohne diese Probe bleibt es bei der Formel „das macht künftig der Fachbereich“.

Zwei Festlegungen für den Projektauftrag

Aus der Übernahmeprüfung folgen zwei Festlegungen. Beide gehören in den Projektauftrag, weil sie sich am Projektende nicht mehr nachholen lassen.

Die Anlaufphase wird geplant, nicht nachgeschoben. In der IT heißt diese Zeit Hypercare oder Early Life Support. In HERMES unterstützt das Projekt die Problembehebung noch während der ersten Betriebszeit, bevor abgenommen wird. Wer diese Phase erst nach der Übergabe ansetzt, muss das Projekt verlängern und stößt auf drei berechtigte Einwände: Die Mitarbeitenden sind anderweitig verplant, das Budget ist geschlossen, und das Portfolio führt das Vorhaben noch als offen. Deshalb gehört die Anlaufphase von Beginn an in den Plan, mit eigenem Budget und eigenen Toleranzen. Dann steht sie im Genehmigungsbeschluss, und das Projekt endet am Tag der bestätigten Übernahme und nicht am Tag der Einführung.

Wann diese Phase endet, sollte messbar sein. Ein Kriterium dieser Art wäre: Über vier Wochen werden weniger als fünf Prozent der Fälle am neuen Verfahren vorbei bearbeitet. Wer stattdessen verlangt, dass sich ausnahmslos alle umgestellt haben, beendet die Phase nie.

Ein offener Punkt braucht einen Namen und einen Termin. Fehlt bei einem der fünf Punkte der Nachweis, kann der Lenkungsausschuss den Abschluss trotzdem freigeben, aber als bewusst akzeptierte Abweichung mit zuständiger Person und Termin. Das ist nötig, weil sich der Lenkungsausschuss mit dem Abschluss auflöst. Dafür braucht es eine Stelle, die bleibt: Das PMO legt den offenen Punkt zum vereinbarten Termin dem Portfoliogremium vor. Die Antworten auf die fünf Fragen stehen im Abschlussbericht selbst, nicht in einer Anlage. Was nicht im Bericht steht, taucht in der Portfoliosteuerung nicht auf.

Wo es ein PMO gibt, braucht es dafür keine neue Methode. Zwei Einträge in vorhandene Vorlagen genügen: ein Pflichtabschnitt „Übergabe ins Tagesgeschäft“ im Projektauftrag und die Übernahmeprüfung in der Abschlusscheckliste des Portfolios. Als Sperre taugt die Prüfung nicht — ein PMO, das Abschlüsse blockiert, verliert die Unterstützung, auf die es angewiesen ist. Als benannte Abweichung wirkt sie besser: Dann entscheidet der Lenkungsausschuss und nicht das PMO, und der Punkt kommt in jeder Portfoliositzung wieder auf den Tisch. Das PMO verantwortet den Betrieb nicht. Es zeigt an, wenn die Übernahme noch offen ist.

Was im Abschlussbericht stehen müsste

In den meisten Abschlussberichten steht ein Name. Seltener steht dabei, was diese Person in der Hand hat: ein Dokument, eine Vertretung, eine Kostenstelle. Und fast nie eine Zahl, an der sich ablesen lässt, ob das bisherige Verfahren noch läuft.

Wo Nachweis und Zahl fehlen, wurde keine Verantwortung übernommen, sondern eine Aufgabe offen gelassen. Ein Lenkungsausschuss darf ein Projekt abschließen und offene Punkte an die Linie übertragen. Er darf die Verantwortung nur nicht unsichtbar machen.

Die Regelwerke beschreiben den Übergang. Die Rolle besetzen und mit einem Mandat ausstatten kann nur, wer den Projektauftrag unterschreibt. Sichtbar bleibt der Übergang, wenn die fünf Punkte in Auftragsvorlage und Abschlusscheckliste stehen — in größeren Häusern Sache des PMO, im Mittelstand die Geschäftsführung selbst.

Sonst weiß morgen niemand, wen er anrufen soll.