Wie wird implementiert? Zwischen methodischem Dogmatismus und „einfach fertig machen“.
Im letzten Artikel wurden die unterschiedlichen Szenarien des Go-Live eines IT-Service Management (ITSM) Tools beschrieben. Die Chancen und Risiken wurden bewertet und eine Einschätzung abgegeben, bei welchen Unternehmenstypen die einzelnen Varianten zum Einsatz kommen können. In diesem Beitrag sollen nun zwei idealtypische, methodische Vorgehen, die in einem ITSM-Projekt zum Einsatz kommen können, beleuchtet werden: Wasserfall und Agil.
Die Wasserfall-Methode
Der Klassiker unter den Projektmanagementmethoden ist der Wasserfall. Noch immer findet dieses Vorgehen in den meisten Implementierungs- und Transformationsprojekten Anwendung. Folgende vier Grundvoraussetzungen sollten erfüllt sein, um die Wasserfallmethode erfolgreich anzuwenden:
Erstens muss das Projektziel benannt sein. Es folgen drei generische Ziele, die im Einzelfall noch konkretisiert werden müssen.
- Ziel 1: Mit der Einführung des neuen ITSM-Tools werden die in dem Tool vorgegebenen Standardprozesse genutzt. Bereits im Unternehmen vorhandene Prozesse müssen angepasst werden.
- Ziel 2: Mit dem neuen Tool sollen im Unternehmen etablierte ITSM-Prozesse bestmöglich abgebildet werden. Anpassungen am Tool sind erwünscht, um die existierenden Prozesse nicht modifizieren zu müssen.
- Ziel 3: Mit Tool-Einführung sollen bereits vorhandene Prozesse optimiert und effizienter gestaltet werden. Anpassungen an Tool und Prozessen sind zur Zielerreichung vorzunehmen.
Zweitens sollte die Projektlaufzeit kurz, d. h. unter 12 Monaten liegen. Dadurch liegt die Realisierung innerhalb der jährlichen Budgetplanung und es ist möglich, parallellaufende Projekte in Abstimmung zu bringen. Längere Laufzeiten bergen das Risiko, dass der Go-Live zeitlich sehr weit vom Start entrückt ist. Damit kann das eigentliche Projektziel bei den Stakeholdern in Vergessenheit geraten.
Drittens sollten in der ersten Projektphase die Anforderungen der Fachbereiche an das ITSM-Tool exakt spezifiziert werden. Anforderungen, die erst später im Verlauf des Projektes identifiziert werden, können nur schwer bzw. mit erheblichen Mehraufwänden (Kosten, Zeit und Nerven) berücksichtigt und umgesetzt werden. Erfahrungsgemäß ist die Spannweite hier recht groß: Benutzerspezifische Ansichten wurden vergessen, Schnittstellen sind übersehen worden, Genehmigungsstrukturen fehlen oder Anforderungen an das Reporting wurden nicht formuliert.
Sofern im Unternehmen ein starres Release- und Deployment Management existiert, ist man gewissermaßen gezwungen, die Wasserfallmethode einzusetzen, da es feste Vorgaben gibt (z. B. aus der IT-Governance), wann und wie Releases produktiv gesetzt werden. Ein iteratives Vorgehen ist unter diesen Voraussetzungen auszuschließen. Zudem gibt es auch Abhängigkeiten zwischen der eingesetzten Methodik und dem anvisierten Go-Live-Typ der ITSM-Lösung (siehe hierfür Artikel 1): In der Regel folgt auf die Wasserfallmethodik der „Big Bang“, mit dem das ITSM-Tool in einem Schwung in Betrieb genommen wird.
Liegt die angestrebte Projektlaufzeit für die Einführung eines ITSM-Werkzeugs über 12 Monaten, wäre die Realisierung mittels Wasserfall gleichzusetzen mit einem langen, endlosen, steinigen Weg. An dessen Ende wartet meistens sprichwörtlich ein „großer Knall“ mit Enttäuschungen und Tränen. Das Projektergebnis entspricht nicht mehr den Wünschen und Erwartungen, die mit dem ursprünglich definierten Projektziel verbunden waren. Das ist der Tatsache geschuldet, dass sich insbesondere bei langen Laufzeiten Anforderungen des Auftraggebers und der zukünftigen Benutzer des ITSM-Tools ändern.
Die agile Methode
Es gibt eine Methodik, welche sich für die Mitigation der oben genannten Probleme der Wasserfallmethode unter Umständen besser eignet: Das agile Framework. Die agile Methode ist anzuraten, wenn die Projektlaufzeit voraussichtlich länger als 12 Monate beträgt. Agilität im Projekt bietet die Chance, in kurzen Iterationen erste Ergebnisse zu präsentieren, welche in den Betrieb eingebracht werden können. Als Abschluss einer agilen Einführung eines ITSM-Werkzeugs bietet sich der Go-Live-Typ „Migration mit oder ohne Pilotbetrieb an."
Eine Grundvoraussetzung für die agile Arbeitsweise ist die Fähigkeit des Auftraggebers und Auftragnehmers, agil zu entwickeln und zu implementieren. Dazu gehören die Bereitschaft mit Zwischenschritten in der Entwicklung „zu leben“ und das ITSM-Produkt in der Projektlaufzeit sukzessive reifen zu lassen. Dafür ist ein kontinuierliches Test-, Release- und Deployment Management zwingend notwendig. Ist dies durch betriebliche Prozesse und die Unternehmenskultur nicht möglich, ist ein agiles Vorgehen an der Stelle nahezu ausgeschlossen.
Fazit: Die gewählte Methodik ist ein kritischer Erfolgsfaktor, aber nicht der Einzige.
Sowohl Wasserfall als auch das agile Manifest sind Idealtypen, deren einzelne Elemente auch miteinander kombiniert werden können. Dieser Mix wird zumeist hybrid genannt. Im Rahmen des Projektes wird versucht, die Realisierung des klar festgelegten Zielzustands agil auszukleiden. Dies ist die Chance, durch einen Kunstgriff im Projektvorgehen, Zwischenergebnisse zu präsentieren.
Egal welche Methode zur Anwendung kommt, zu Beginn des Projektes müssen Scope und Timeline klar definiert sein. Vor allem müssen Auftraggeber und Auftragnehmer das gleiche Verständnis darüber haben. Fehlt dieses, droht eine Verschiebung des Go-Live Termins oder die Qualität des Projektergebnisses leidet. Im Umkehrschluss kann die Methode der Implementierung bei einem klaren, gemeinsamen Verständnis dazu beitragen, das Projektziel in den bekannten Dimensionen Time, Quality und Budget zu realisieren. Die gewählte Methode muss jedoch zur Unternehmenskultur und den Betriebsprozesse von Auftragnehmer und Auftraggeber passen. Die Auswahl der generellen Methoden ist begrenzt: Agil oder Wasserfall – oder eben eine Mischung aus beidem. Die richtige Wahl der Methode ist ein kritischer Erfolgsfaktor und immer im Einzelfall zu bewerten.
Die Entscheidung für eine Methode ist nur eine von vielen kritischen Weichenstellungen. Viel hängt auch davon ab, „was“ abgelöst werden soll. Um das „Was“, also die alte und neue ITSM-Landschaft, geht es im nächsten Artikel.
Die Artikelreihe im Überblick
- Artikel 0:
Im Nachhinein ist man immer schlauer - ITSM Tool Einführung rückwärts gedacht. - Artikel 1:
Go-Live - Muss es immer der große Knall sein? - Artikel 2:
Wie wird implementiert? Zwischen methodischem Dogmatismus und „einfach fertig machen“. - Artikel 3:
„Alte Liebe oder reif für die Entsorgung“ – die alte ITSM-Landschaft zwischen Ablösung und Revitalisierung - Artikel 4:
ITSM, auf die Plätze, fertig, los! Aber was ist noch mal das Ziel? - Artikel 5:
Erkenntnisse der Retrospektive: Hätte, wenn und aber – diese Stolpersteine gilt es zu vermeiden.
Ihre Ansprechpartner für IT-Exzellenz
Wir sind vom Wettbewerbsvorsprung durch adaptive IT überzeugt. Und wir erläutern Ihnen gern, wie sich Ihr Unternehmen hierfür am besten positioniert. Nutzen Sie unser Angebot und sprechen Sie mit einem Cassini-Experten darüber, welche Rolle Ihre IT-Organisation einnehmen könnte.