Lücken in der IT-Steuerung – Projektmanagement vs. ITSM-Prozesse

Ein interessante Lücke in der Welt der IT-Frameworks tut sich aus meiner Sicht zwischen ITSM-nahen Management-Systemen und projektnahen Vorgehensmodellen auf.

Verdrängung einer angemessenen IT-Projektkultur im ITSM

Bücher zu ITIL V3 und vor allem die ISO/IEC 20000 schweigen sich weitgehend zur Thematik des Projekt-Managements aus. Projekte klingen im Rahmen des Phasenmodells von ITIL V3 zwar in sekundären Erläuterungen an – viel bemüht wird dabei die Abfolge der sog. Phasen von ITIL V3. Das sieht dann etwa wie folgt aus:

Das wirkt auf den ersten Blick logisch strukturiert. Die Skizze zitiert wichtige Prozessgruppen und bringt sie in eine lineare Reihenfolge. In Wirklichkeit ist jedoch ein Service-Lifecycle gemeint; die Wiederholung wird über neue Business Anforderungen und über eine kontinuierlichen Verbesserungsprozess ausgelöst. Beides führt zu RFCs, die umgesetzt werden.

Die Skizze deutet im unteren Bereich auch an, dass ein Projekt im Lifecycle irgendwie als die Umsetzung eines großen RFCs begriffen wird. Das schließt einen Bündelung kleiner RFCs nicht aus. Wer jedoch den Change-Management-Prozess im ITSM studiert, wird über Projekte leider nichts erfahren. (Wie im ITSM Releases ins Spiel kommen, werde ich in diesem Blog an geeigneter Stelle noch genauer betrachten.)

Nimmt man die obige Darstellung ernst, so weist sie fatale Bezüge zum klassischen linearen V-Modell mit allen Nachteilen auf. Kennt man ITIL V3 genauer, so muss man leider auch feststellen, dass durch die Zuordnung der eigentlich hierarchisch in Gruppen gegliederten ITIL-Prozesse zu aufeinander folgenden Phasen die ganze ITIL-Prozesslandschaft wackelig bis inkonsistent wird. Ich werde auch auf diesen Punkt mal in einem eigenen Artikel im Detail eingehen. Nicht nur ich habe den Eindruck, dass das zyklische Phasenmodell ITIL mit der V3 übergestülpt wurde, um es ein wenig dynamischer erscheinen zu lassen und den sog. „Kontinuierlichen Verbesserungsprozess“ zu unterfüttern.

Zudem macht die Skizze nicht deutlich, wie und aufgrund welcher Kriterien es eigentlich zu einem Projekt kommen sollte; den Prozess-Erläuterungen von ITIL kann man das aber auch nicht entnehmen. Das in der obigen Skizze auftauchende Projekt-Team wirkt insofern irgendwie aufgesetzt. Projekte sind letztlich keine Thema der Prozessgruppen und der dort verankerten Einzelprozesse von ITIL. Man bringt die Prozesswelt von ITIL und Projekte daher keineswegs so einfach zur Deckung, wie die obige Grafik vorgaukelt.

Den Ansatz der ISO/IEC 20000, Projekte vorsichtshalber ganz auszublenden, finde ich deshalb viel konsequenter. Man kann konzidieren: Projektsteuerungsmodelle sind etwas anderes als Ansätze zur Steuerung von Service-Lifecycles. Trotz des Lifecycle-Aspects von IT-Systemen und IT-Services hat das ITSM seinen Fokus klar auf der Steuerung des operativen Betriebs.

Der Übergang in die Welt dynamischer Projekte ist also durchaus problematisch. Das hat natürlich auch damit zu tun, das die Vielfalt der Projektmanagement-Methodiken groß ist. Eine ISO-Norm wird das nicht aufgreifen, um nicht ins Diffuse abzugleiten.

Aber: Viele RFCs verlangen zur Umsetzung Projekte. Und Projekte können nicht Produkte (IT-Systeme, SW) entwickeln, ohne auf Nachhaltigkeit und den nachfolgenden Betrieb zu achten. Daraus ergeben sich u.a. Anforderungen an Dokumentationen und Artefakte eines Configuration Managements, die schon im Projekt zu erstellen sind. Zwischen ITSM-Prozessen und Projekten muss es also Schnittstellen geben.

Ich werde mich in diesem Blog an passender Stelle daher mit dem Thema der Einbettung von Projekten in ITSM-Zyklen etwas genauer befassen. Dabei wird uns das „Release-Management“ zu Hilfe kommen.

Trennung zwischen Projekten und operativem Betrieb in der ISO/IEC 38500

Der Gegensatz zwischen Projekten und Prozessen zur Steuerung des operativen Service-Managements spiegelt sich übrigens auch in der ISO/IEC 38500 zur IT-Governance wider: Dort wird klar zwischen Projekten und operativem Betrieb unterschieden. Zum Ausdruck bringt das u.a. folgende Skizze, die einige Aspekte der Norm erfasst:

Verdrängung des ITSM im IT-Projektmanagement

Was ich oben über eine ungenaue Behandlung bis Verdrängung von Projekten im ITSM gesagt habe, gilt umgekehrt genauso:

Auch Projektmanagement-Methodiken klammern leider allzu oft eine Bezugnahme zu nachfolgenden Prozessen des Live-Betriebes aus.

Man gibt sich damit zufrieden, dass dem Projekt von außen schon vorgegeben werden wird, welche Dokumentationen und Artefakte genau erforderlich werden. Dito für Performance-, Kapazitäts-, Sicherheits- und Kontinuitätsanforderungen.
Klassisch gesteuerte Projekte verdrängen oft viel zu lange, dass eine enge Kooperation mit dem Endverbraucher des zu erstellenden Produkts schon im Projekt für frühzeitiges Feedback höchst sinnvoll wäre. Zudem wird oft viel zu lange verdrängt, wie sich das Produkt unter den Gegebenheiten der Produktivumgebung (inkl. Internet etc.) verhalten wird und welche Probleme dann auf den Betrieb bzw. Support zukommen. Insofern wäre eine sehr frühzeitige Kooperation innerhalb der Projektphase mit den Verantwortlichen des operativen IT-Betriebes wünschenswert – gerade bei komplexen, verteilten Systemen. Statt dessen erlebt man in der Praxis an der Schnittstelle zwischen Projekten und operativem Betrieb eher eine Nabelschau auf beiden Seiten.

Ein guter IT-Projektleiter sollte daher die Prozesse des ITSM kennen und wissen, wie sich sein Projekt bzw. das darüber angestrebte Produkt samt Services in die spätere Betriebsumgebung einbetten wird. Der regelmäßige Austausch zwischen Entwicklern und DevOPs des Betriebes schon zur Projektlaufzeit wäre flankierend zu fördern.

Ich möchte allerdings auch festhalten, dass agile Verfahren wie SCRUM auf der Projektseite diese Sperren durch einen stark produktzentrierten und vor allem kurz getakteten inkrementellen Ansatz zumindest aufweichen. Dennoch ist die Verbindung zwischen SCRUM und ITSM problematisch, denn es stehen sich zwei völlig unterschiedliche Philosophien gegenüber. Ein echter SCRUM Mensch wird ITIL oder gar eine ISO/IEC 200001-Norm wohl eher als Frameworks „von Bürokraten für Bürokraten“ ansehen.

Umso wichtiger wäre es, Brücken zu schlagen. Aus meiner Sicht kann auch hier das Release-Management helfen.

Weiterführende Links

https://www.isaca.org/Knowledge-Center/Documents/COBIT-Focus-ISO-38500-Why-Another-Standard.pdf
https://pmqs.de/index.php/projektmanagement/methoden-pm/18-abgrenzung-it-betrieb-itil-und-projektmanagement
http://www.myitstudy.com/blog/2014/02/itil-and-scrum/
https://blog.itil.org/2014/07/allgemein/integrating-agile-and-itsm/

Schreibe einen Kommentar

Dieser Blog verwendet Cookies. Bei weiterer Nutzung gehen wir von Ihrem Einverständnis aus. Optionen/Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen