Wann wird aus einem Projekt Betrieb? Vier Merkmale statt eines Stichtags

Am Tag des Go-live wechselt die Verantwortung auf dem Papier. Woran du erkennst, dass sie auch im Alltag angekommen ist – und warum der Weg dorthin zum Projekt gehört.

Wann wird aus einem Projekt Betrieb? Die Frage klingt harmlos, und in vielen Organisationen gibt es eine schnelle Antwort: am Tag des Go-live. Oder mit der Abnahme. Oder wenn das Projekt formal geschlossen ist.

Alle drei Antworten nennen einen Zeitpunkt, und ein Zeitpunkt reicht nicht.

Ein Zeitpunkt sagt, wann die Verantwortung wechseln soll. Ob die Seite, die übernimmt, sie auch tragen kann, sagt er nicht. Deshalb sieht es nach dem Go-live in vielen Projekten so aus: Die Projektleitung ist Monate später noch die erste Anlaufstelle für Störungen. Änderungen laufen „noch schnell über das Projekt“, weil der reguläre Weg zu lange dauert. Der Betrieb hat den Service auf dem Papier übernommen, im Alltag aber nicht. Und irgendwann steht eine „Phase 2“ im Plan, die alles sammelt, was eigentlich zur Übergabe gehört hätte.

Meine Antwort ist kein Datum. Betrieb ist ein Zustand, und der lässt sich an vier Merkmalen prüfen. Solange eines fehlt, hast du ein Projekt mit Nutzern, aber noch keinen Betrieb. Bis dieser Zustand erreicht ist, vergeht nach dem Go-live eine Anlaufphase. Sie gehört zum Projekt, nicht in die Zeit danach.

Das betrifft Projektleitungen, die etwas bauen, das anschließend jemand anderes betreiben muss, die Teams, die es übernehmen sollen, und Führungskräfte, die beide Seiten steuern und sich wundern, warum ein abgeschlossenes Projekt weiter Leute bindet.

Drei Welten, drei Antworten

Wer Projektmanagement, Service Management und DevOps nebeneinander unterrichtet, merkt schnell: Die drei Welten beantworten die Frage unterschiedlich, und jede Antwort hat einen blinden Fleck.

Die klassische Projektwelt – PRINCE2, die IPMA Competence Baseline (ICB) – kennt den Projektabschluss als eigenen Schritt. Die Produkte werden abgenommen und übergeben, offene Punkte werden zu Empfehlungen für die Zeit danach, das Projekt wird geschlossen. PRINCE2 verlangt ausdrücklich eine Abnahme durch Betrieb und Wartung und legt schon in der Projektproduktbeschreibung fest, wie abgenommen wird. In der Praxis prüft die Abnahme trotzdem meist nur, ob das Ergebnis seiner Beschreibung entspricht, und nicht, ob jemand es betreiben kann. Der Betrieb unterschreibt dann eine Liste, die er unter Zeitdruck gelesen hat.

Service Management nach ITIL setzt beim Service an und beschreibt, was zu seinem Betrieb gehört: Der Service steht im Katalog, Störungen haben einen festgelegten Weg, Änderungen laufen über einen geregelten Change-Prozess, und das Wissen liegt dort, wo der Service Desk es braucht. Damit bekommt der Übergang eine Struktur. Der blinde Fleck liegt in der Umsetzung: Aus der Struktur wird eine Betriebsabnahme mit achtzig Prüfpunkten, der Betrieb lehnt ab, das Projekt eskaliert, und die Übergabe wird zur Verhandlung zwischen zwei Abteilungen statt zu gemeinsamer Arbeit.

DevOps scheint die Frage aufzulösen. „You build it, you run it“, sagte Werner Vogels 2006: Wer baut, betreibt auch. Dann gibt es keinen Übergang, weil es keine zweite Seite gibt. Das funktioniert dort, wo ein Team beides kann und beides darf. In vielen Organisationen gibt es ihn trotzdem, nur an anderer Stelle: zum Netzwerk, zur Datenbank, zum Service Desk, zur Lizenzverwaltung, zu dem Team, das nachts Rufbereitschaft hat. Abgeschafft ist er damit nicht, nur unsichtbar geworden, und für einen unsichtbaren Übergang ist niemand verantwortlich.

Alle drei haben recht, und keine reicht allein. Die klassische Welt sagt, dass der Abschluss geplant werden muss. ITIL sagt, was der Betrieb braucht. DevOps sagt, dass der Übergang so klein wie möglich sein sollte. Was fehlt, ist eine prüfbare Antwort darauf, wann aus dem Projekt Betrieb wird.

Betrieb ist ein Zustand, kein Zeitpunkt

Für die Antwort genügen vier Merkmale. Sie hängen nicht davon ab, mit welcher Methode das Projekt gelaufen ist, und sie lassen sich an einem Nachmittag prüfen.

1. Störungen haben einen Empfänger, der zugestimmt hat

Wenn der Service ausfällt, weiß der Service Desk, an wen er die Störung gibt. Es gibt eine Rufbereitschaft oder feste Supportzeiten, und wer dort Dienst hat, gehört nicht zum Projektteam. Entscheidend ist, dass der Empfänger zugestimmt hat. Ein Eintrag in einem Zuständigkeitsverzeichnis, von dem das Betriebsteam erst am Montag erfährt, ist keine Zustimmung. Und der Empfänger ist eine benannte Person mit Vertretung, keine Abteilung: Es muss feststehen, wer ans Telefon geht, wenn diese Person im Urlaub oder krank ist.

Die Prüfung: Melde beim Service Desk eine als Test gekennzeichnete Störung für diesen Service und verfolge, wohin sie geht. Heißt es dann „da müssen wir mal das Projekt fragen“, ist Merkmal 1 nicht erfüllt.

2. Änderungen gehen den Betriebsweg

Eine Änderung am Service läuft über denselben Weg wie jede andere Änderung im Betrieb. Kleine, wiederkehrende Änderungen sind als Standard Changes beschrieben und freigegeben. Es ist geklärt, wer die Regeln für diesen Service künftig ändern darf. Und niemand sagt mehr: „Das macht noch schnell das Projekt, bevor wir den Change-Prozess bemühen.“

Dieses Merkmal bleibt am längsten offen. Der Projektweg ist eingespielt und schnell, der Betriebsweg wirkt langsam. Solange es den schnellen Weg gibt, wird er genutzt. Und solange er genutzt wird, lernt der Betrieb nicht, mit Änderungen an diesem Service umzugehen.

3. Gemessen wird am laufenden Betrieb

Ein Projekt misst Meilensteine, Budget und Fortschritt. Der Betrieb misst Verfügbarkeit, Störungszahlen, Lösungszeiten und die Durchlaufzeit von Änderungen. Taucht der Service in keinem Betriebsbericht auf, ist er nicht im Betrieb, egal wie viele Menschen ihn nutzen.

Dieses Merkmal fällt am wenigsten auf und wirkt am stärksten. Was im Betriebsbericht steht, bekommt Aufmerksamkeit, Budget und Zeit. Was dort fehlt, wird nebenbei erledigt. Wer die Übergabe ernst meint, trägt den Service in die Berichte ein, bevor das Projektteam geht.

4. Das Wissen liegt dort, wo die Störung ankommt

Es gibt eine Betriebsdokumentation, mit der jemand aus dem Betrieb schon gearbeitet hat. Bekannte Fehler stehen mit ihren Umgehungslösungen in der Wissensdatenbank. Zugänge, Berechtigungen und Ansprechpartner stecken nicht im Kopf einer einzelnen Person aus dem Projekt.

Entscheidend ist auch hier, dass schon jemand damit gearbeitet hat. Eine Dokumentation, die noch niemand aus dem Betrieb gebraucht hat, ist eine Vermutung darüber, was der Betrieb brauchen wird. Den Beweis liefert erst die erste Störung, die der Betrieb ohne das Projektteam löst. Bis dahin ist Merkmal 4 eine Hoffnung.

Sind alle vier Merkmale erfüllt und hat der Betrieb die Übernahme bestätigt, ist das Ergebnis im Betrieb, ganz gleich, was im Projektplan steht. Fehlt eines, ohne dass der Lenkungsausschuss das als Abweichung mit Person und Termin akzeptiert hat, ist das Projekt nicht zu Ende, auch wenn es formal geschlossen wurde.

Direkt öffnen, ohne Konto

Die Entscheidung fällt am Anfang, nicht am Ende

Geprüft werden die vier Merkmale am Ende. Ob sie sich erfüllen lassen, entscheidet sich am Anfang.

Wer betreibt das Ergebnis? Diese Frage gehört in die erste Woche des Projekts, nicht in die letzte, denn sie bestimmt, welche Anforderungen überhaupt gestellt werden. Überwachung, Sicherung, Protokollierung, Berechtigungskonzept, Wartungsfenster, Dokumentation: Das sind Anforderungen des Betriebs, und in einem Anforderungsworkshop ohne den Betrieb kommen sie nicht vor. Der Betrieb ist vom ersten Tag an Stakeholder. Wer ihn erst zur Abnahme einlädt, bekommt die fehlenden Anforderungen dort nachgereicht und hält das dann für Widerstand.

Dasselbe gilt für das Geld. Ein Business Case, der nur die Projektkosten enthält, erfasst den kleineren Teil. Lizenzen, Personal für den Support, Wartung und Weiterentwicklung fallen jedes Jahr an, solange der Service läuft. Wer das nicht vorher auf den Tisch legt, führt die Diskussion später, wenn das Projektbudget aufgebraucht ist und der Betrieb Stellen beantragen muss, die niemand eingeplant hat.

Ansehen und starten, Konto kostenlos

Die Anlaufphase gehört zum Projekt

Zwischen „das Projekt liefert“ und „der Betrieb trägt“ liegt eine Zeit, in der der Service schon läuft und das Projektteam noch da ist. In der IT heißt diese Zeit Hypercare, ITIL nennt sie Early Life Support.

Diese Anlaufphase ist Teil des Projekts, nicht seine Verlängerung. Sie steht von Anfang an im Projektplan, mit eigenem Budget und eigenen Toleranzen, und das Projekt endet erst am Tag der bestätigten Übernahme, nicht am Tag des Go-live. Wer sie erst nach dem Go-live einplant, muss das Projekt verlängern und stößt auf drei berechtigte Einwände: Das Team ist schon anderweitig verplant, das Budget ist geschlossen, und im Portfolio steht das Vorhaben noch als offen.

Drei Dinge müssen feststehen, bevor die Anlaufphase beginnt.

Die Rollen. In der Anlaufphase steht der Betrieb vorn, das Projektteam unterstützt. Störungen gehen an den Betrieb und werden dort bearbeitet. Das Projektteam hilft, wenn es gefragt wird. Nicht umgekehrt. Bleibt das Projektteam vorn, lernt der Betrieb den Service nie kennen, und die Phase findet kein Ende.

Der Rückfallweg. Was passiert, wenn der Service in dieser Phase ausfällt und niemand ihn retten kann? Zurück zum alten Stand, von Hand weiterarbeiten, abschalten? Unter Druck lässt sich das nicht mehr entscheiden. Die Entscheidung fällt vorher und wird aufgeschrieben.

Die Ausstiegskriterien. Die Phase endet nicht nach vier Wochen, sondern wenn prüfbare Bedingungen erfüllt sind. Zum Beispiel: Der Betrieb hat drei Störungen ohne Rückfrage beim Projekt gelöst, die erste Änderung ist über den regulären Change-Prozess gelaufen, der Service steht im Betriebsbericht, und der Service Desk hat bei zwei bekannten Fehlern die Umgehungslösung selbst angewendet. Das sind die vier Merkmale, als Kriterien formuliert. Wer stattdessen verlangt, dass nie wieder eine Frage beim Projekt landet, beendet die Phase nie.

Sind die Kriterien zum geplanten Ende nicht erfüllt, gibt es zwei ehrliche Wege. Entweder läuft die Anlaufphase weiter, sichtbar und mit Begründung, und damit auch das Projekt. Oder der Lenkungsausschuss schließt das Projekt trotzdem ab, als bewusst akzeptierte Abweichung: Jeder offene Punkt bekommt eine zuständige Person und einen Termin, an dem er wieder auf den Tisch kommt. Dass die Projektleitung still weitermacht, ist kein dritter Weg.

Die Dauer sagt dabei nichts über die Qualität. Eine Anlaufphase, die nach zwei Wochen mit erfüllten Kriterien endet, ist besser als eine, die drei Monate dauert, weil niemand Kriterien festgelegt hat.

Ansehen und starten, Konto kostenlos

In dieser Phase fällt vieles an, das später gebraucht wird: welche Störungen es gab und wie sie gelöst wurden, was als bekannter Fehler eingetragen wurde, welche Fragen noch beim Projektteam gelandet sind. Wer das nicht festhält, hat am Ende ein Gefühl, aber keinen belegten Stand. Dafür eignet sich ein Agent, der ein Logbuch führt: Er bekommt Störungstickets, Protokolle und Notizen, hält fest, was der Betrieb allein gelöst hat und was nicht, und zeigt jeden Tag, welche Ausstiegskriterien erfüllt sind.

Ansehen und starten, Konto kostenlos

Woran du merkst, dass es schiefläuft

Die Warnzeichen ähneln sich von Organisation zu Organisation. Diese sehe ich am häufigsten:

• Die Projektleitung ist ein halbes Jahr nach dem Go-live noch erste Anlaufstelle. Nicht, weil sie es sein will, sondern weil alle ihre Nummer kennen.
• Es gibt eine „Phase 2“, die alles sammelt, was dem Betrieb noch fehlt. Dokumentation, Überwachung, automatisiertes Deployment: alles, was im Projekt als „nicht-funktional“ zurückgestellt wurde.
• Entwickler haben Administratorrechte in der Produktion, „weil es sonst nicht geht“. Das ist nicht nur ein Sicherheitsproblem, sondern der Beleg, dass Merkmal 2 nicht erfüllt ist.
• Die Betriebsabnahme ist eine Liste mit achtzig Punkten, unterschrieben zwei Tage vor dem Go-live. Eine Liste, die unter Zeitdruck unterschrieben wird, prüft nichts. Sie verteilt nur die Schuld für später.
• Der Service steht in keinem Bericht. Nicht im Verfügbarkeitsbericht, nicht in der Störungsstatistik, nicht in der Change-Übersicht. Für die Nutzer existiert er, für die Steuerung nicht.

Keines dieser Zeichen ist die Schuld einer Seite. Sie entstehen, wenn die Frage „Wann wird aus dem Projekt Betrieb?“ mit einem Datum beantwortet wurde und danach niemand mehr nachgeprüft hat.

Was das für drei Rollen bedeutet

Projektleitung: Die Anlaufphase ist ein Arbeitspaket mit eigenem Aufwand und eigenem Budget, nicht der letzte Meilenstein.

Betrieb: Eine Betriebsabnahme passt auf eine Seite, und jeder Punkt darauf ist eines der vier Merkmale oder ein Teil davon. Wer ablehnt, nennt, was genau fehlt.

Führung: Ein Projekt gilt erst als abgeschlossen, wenn der Betrieb die Übernahme bestätigt hat. Ist das Projektteam nach dem Go-live noch monatelang gebunden, zeigt das kein besonders engagiertes Team, sondern eine Übergabe, die nicht stattgefunden hat.

Wo sich die Prüfung verschiebt

Die vier Merkmale setzen voraus, dass es im eigenen Haus einen Betrieb gibt. In drei Fällen verschiebt sich die Prüfung, ohne wegzufallen.

Ein Dienstleister oder ein SaaS-Anbieter betreibt den Service. Dann ist der Empfänger aus Merkmal 1 der Anbieter, gebunden durch ein Service Level Agreement mit Reaktionszeiten und einem Eskalationsweg. Im eigenen Haus braucht es außerdem eine benannte Person mit Vertretung, die diesen Weg kennt und schon einmal gegangen ist. Merkmal 3 und 4 bleiben trotzdem bei dir. Wer den Anbieter nicht misst und dessen bekannte Fehler nicht kennt, hat nicht den Betrieb ausgelagert, sondern die Aufmerksamkeit.

Eine regulierte Umgebung schreibt die Abnahmeliste vor. In der Medizintechnik, der Energieversorgung oder im Finanzsektor sind die achtzig Punkte keine Unsitte, sondern Pflicht. Die vier Merkmale ersetzen diese Liste nicht, sie kommen hinzu: Die Liste belegt, dass die Vorgaben erfüllt sind. Die Merkmale zeigen, ob am Montag jemand den Service tragen kann.

Das Team betreibt selbst. Dann ist Merkmal 1 schnell erfüllt, sobald feststeht, wer im Team Rufbereitschaft hat und wer vertritt. Merkmal 2 ist es oft auch. Merkmal 3 und 4 werden umso wichtiger, weil niemand von außen danach fragt. Ein Team, das baut und betreibt, misst sich schnell nur noch an dem, was es baut, und sein Wissen steckt in Köpfen statt in einer Dokumentation, mit der ein neues Teammitglied arbeiten kann.

Die vier Merkmale im Überblick

1. Störungen haben einen Empfänger, der zugestimmt hat. Eine benannte Person außerhalb des Projektteams, mit Vertretung und bekannter Erreichbarkeit, und der Service Desk kennt den Weg.
2. Änderungen gehen den Betriebsweg. Über den regulären Change-Prozess, mit Standard Changes für das Wiederkehrende, ohne Abkürzung über das Projekt.
3. Gemessen wird am laufenden Betrieb. Verfügbarkeit, Störungen, Lösungszeiten, Durchlaufzeit von Änderungen. Der Service steht im Betriebsbericht.
4. Das Wissen liegt dort, wo die Störung ankommt. Dokumentation, bekannte Fehler und Zugänge liegen beim Betrieb, und der Betrieb hat schon damit gearbeitet.

Dazu die Anlaufphase als Teil des Projekts: mit festgelegten Rollen, einem Rückfallweg und Ausstiegskriterien, die aus diesen vier Merkmalen abgeleitet sind. Das Projekt endet mit der bestätigten Übernahme.

Wenn du das selbst ausprobieren möchtest

Die vier Merkmale im Überblick und die Warnzeichen kannst du so, wie sie dastehen, ins nächste Übergabegespräch mitnehmen, ganz ohne Konto.

Die vier Werkzeuge aus dem Artikel kosten nichts. Auf der öffentlichen Ressourcen-Seite siehst du zu jedem Werkzeug Titel, Zweck und Einordnung, und die Vorlage lädst du dort direkt herunter. Nur die Prompttexte und der Leitfaden selbst brauchen ein kostenloses Konto.

Ressourcen ansehen

Wie viel von der Durchlaufzeit einer Änderung tatsächlich Wartezeit ist und warum vier schnelle Abteilungen zusammen langsam sein können, steht in einem eigenen Beitrag: Flow Efficiency – gibt es einen Normalwert?

Zum Schluss

Wann wird aus einem Projekt Betrieb? Die Frage ist vor allem deshalb schwer zu beantworten, weil sie meistens zu spät gestellt wird. Am Ende, wenn das Budget verbraucht ist und das Team schon im nächsten Projekt steckt, bleibt als Antwort nur noch ein Datum.

Wer sie früh stellt, bekommt eine bessere Antwort: Aus einem Projekt wird Betrieb, wenn die vier Merkmale erfüllt sind und der Betrieb die Übernahme bestätigt hat. Das geschieht am Ende der Anlaufphase, also noch im Projekt.

Ein Projekt ist nicht zu Ende, wenn es geschlossen wird. Es ist zu Ende, wenn jemand anderes den Anruf bekommt und helfen kann.

Ob das gelingt, entscheidet sich in der ersten Woche, wenn jemand fragt, wer das Ergebnis später betreibt. Sichtbar wird es bei der ersten Störung, die der Betrieb löst, ohne das Projekt anzurufen. Besiegelt wird es, wenn der Betrieb die Übernahme bestätigt.

Dieser Tag gehört in den Plan, nur nicht als Datum, sondern als Bedingung.