Immer wieder werden wir vor allem von Mittelständlern gefragt, wie kann man erfolgreich Releases implementieren, ohne die Betriebsumgebung zu stören bzw. ohne in den ersten Tagen auf massive Schwierigkeiten zu stoßen. Dies ist nicht neu, ist doch die Schnittstelle zwischen den Entwicklungs- und Betriebsabteilungen in einer IT-Organisation immer wieder problematisch und bietet Anlass für handfeste Streitigkeiten (vgl. Disterer).

Warum ist das so? Sind die Menschen zu dumm? Lernen sie nichts aus Erfahrungen?

Ich glaube, das sind die falschen Fragen. Vielmehr sollte man sich die Art und den Umfang der Releases anschauen. ITIL bietet an der Stelle schon eine große Hilfe: Gibt es eine Release Policy? Gibt es Release Pläne? Wie sieht das Release Design aus?

Nähert man sich dem Thema von dieser Seite, kommt man unweigerlich zu dem Ergebnis, dass jedes Release ein Projekt ist. Zur Umsetzung braucht man also Projektmanagement. Am besten eine Methode, die unternehmensweit eingesetzt wird.

Aber hier taucht das nächste Problem auf. Das Gesamtunternehmen verwendet i.d.R. gerne die klassischen Methoden wie PRINCE2, PMI u.ä., die IT setzt bevorzugt auf die agilen Methoden wie Scrum. Diese beiden Ansätze müssen vernünftig auf einander abgestimmt werden. Sie ergänzen sich und schließen sich nicht aus, wie in vielen Unternehmen geglaubt wird. Auf der Unternehmensebene sind die klassischen Projektmanagementmethoden unerlässlich. Nur so lassen sich Governance und Compliance einhalten. Bei der Durchführung und Entwicklung können die agilen Methoden sehr nützlich sein.

Schauen wir uns mal an, was das für unsere Ausgangsfrage bedeutet:

Die Planung eines Releases fängt bereits im Design an. D.h., die grundlegenden Voraussetzungen wie die Release Policy und das generelle Release Design müssen vor der Realisierung schon da sein. In der PRINCE2 Terminologie hieße das, die Managementstrategien (Risiko, Qualität, Konfiguration, Kommunikation), die in der Initialisierung gebraucht werden, sind bereits vorhanden. Das Fehlen dieser Grundlagen führt bei der Produktivsetzung eines Releases bzw. bei der Übergabe einer Änderung an den Betrieb zu hohem Kommunikations- und Koordinierungsaufwand (vgl. Elsässer, S. 72ff)

Voraussetzung für das Release Management ist ein genehmigter Änderungsantrag aus dem Change Management. Er wurde untersucht und bewertet. Es wurde quasi das Release „initiiert“ mit einem Business Case, einem grobem Plan mit Messpunkten und abgestimmten Managementstrategien.

Die Aktivitäten des Service Designs und des Change Managements in diesem Zusammenhang spiegeln die Initialisierung einer Projektmanagementmethode wie PRINCE2 wieder.

Die Realisierung der Arbeitspakete des Releases, Planen, Bauen, Testen, Implementieren, Early Life Support kann dann „agil“ laufen. Gerade für Bauen und Testen bietet sich „agil“ an, wenn die Vorgaben aus dem Change Management und dem Service Design ausreichend sind.

Zusammenfassend lässt sich also sagen, erst die Verknüpfung von ITIL und einer Projektmanagementmethode wie PRINCE2 erlaubt es, Releases ohne Probleme zu implementieren. Beides zusammengenommen berücksichtigt die häufigsten Fehler (fehlendes Anforderungs- und Stakeholder Management) und erzeugt einen Mehrwert, generiert Nutzen. Wichtig ist aber, dass sowohl ITIL als auch die Projektmanagementmethode abgestimmt ist auf das jeweilige Unternehmen. Darin liegt unserer Ansicht nach das Grundproblem: die Anpassung der Best-Practices ITIL und PRINCE2 geht nicht weit genug oder ist nicht aufeinander abgestimmt oder existiert gar nicht.

Autor:

Guido Hoffmann

Quellen:

Georg Disterer

Itil: Zwischen Entwicklung und Betrieb hakt es

26.05.2007

http://www.computerwoche.de/592968

Wolfgang Elsässer

ITIL einführen und umsetzen, München, 2006