Eine falsch gewählte Variante des Go-Live birgt das Risiko, im entscheidenden Moment des Projektes vor einem Trümmerhaufen der bisherigen Arbeit zu stehen. Grundsätzlich bestehen drei Go-Live-Varianten, die abhängig von Parametern, wie z. B. Unternehmensgröße, ihr Wirkungspotenzial unterschiedlich entfalten:

1. Big Bang – Alle Änderungen für alle Benutzer zu einem Stichtag.
2. Migration – Die Implementierung des neuen ITSM Werkzeugs erfolgt seriell über Organisationseinheiten.
3. Go-Live mit Pilotbetrieb – Das neue ITSM Werkzeug wird in Modulen implementiert und im Pilotbetrieb in ausgewählten Organisationseinheiten verprobt.

Die Wahl der Methodik nimmt entscheidend Einfluss auf das Projekt. Der dogmatische Rückgriff auf radikal agile Ansätze, nur weil diese aktuell „en vogue“ sind, sollte kritisch hinterfragt werden. Eine „Überforderung“ der Organisation sowie des Teams ist eine reale Gefahr. Sich daraus ableitende qualitative Einbußen sowie zeitliche Verzögerungen in der Umsetzung, sind nur ein verkürzter Auszug der unerwünschten Nebenwirkungen. Die Praxis zeigt, dass ein hybrider Ansatz, also eine Mischung aus agiler Entwicklung und definiertem Zielzustand (Zeit und Inhalt), solide Projektergebnisse fördert. Letzteres hat positive Auswirkungen auf die Qualität und ermöglicht es, die Stärken des Teams nutzbar zu machen. Die agile Entwicklung fördert die Eigenverantwortung des Projektteams. Konkrete Meilensteine mit definierten Liefergegenständen und fixen Terminen geben Planungssicherheit und stabilisieren den gesamten Veränderungsprozess der Implementierung.

Sollen in dem Projekt die bestehenden Prozesse abgelöst oder auf ein neues ITSM-Tool migriert werden? Eine indikative Überprüfung der Betriebsprozesse und den damit verbundenen Kosten sind Mindestvoraussetzungen für den Business Case. Nur die Transparenz über die Ist-Prozesse ermöglicht die Identifizierung von Prozessredundanzen, Prozesskosten und Automatisierungspotenzial. Alle drei Themenblöcke und deren Ausprägung sind entscheidend für den späteren Projektverlauf und -scope.

Um diesen Stolperstein zu vermeiden ist es empfehlenswert folgende Aspekte beim Projektstart zu beachten:

• Für die Projektlaufzeit müssen alle erforderlichen technischen Experten mit ausreichenden Kapazitäten verfügbar sein, um die angestrebten Veränderungen termingerecht zu realisieren.
• Die Dokumentation der Ist-Prozesse im ITSM ist aktuell und vollständig. Diese bilden zum Projektstart und für den Verlauf eine wichtige Orientierungshilfe zu den umgesetzten Veränderungen und dem angestrebten Zielzustand.
• Der Business Case ist seriös gerechnet. Der Business Case leitet sich aus der Motivation der Stakeholder ab, das Projekt zu initiieren. Sollen primär Kosteneinsparungen und Effizienzsteigerungen mit dem Projekt realisiert werden, müssen alle finanziellen Parameter bewertet werden.
• Die Projektlaufzeit ist realistisch geschätzt. Es ist dringend davon abzuraten, die Laufzeit zu optimistisch zu planen und in der Euphorie eines Vorhabens den Realisierungszeitraum zu sportlich anzusetzen. Zu rasch kann hier eine Projekt- und Betriebsorganisation an den Rand der Handlungsfähigkeit geführt werden.
• Alle Stakeholder sind proaktiv und vor dem Projekt in das Vorhaben eingebunden. So ist es möglich, gemeinsam die Ziele zu erreichen und spätere Interessenskonflikte während der Projektlaufzeit zu vermeiden.