Der Teufel steckt im Detail
Probleme in ITSM-Projekten
Der Teufel steckt bekanntermaßen im Detail. Das gilt auch für ProjekteProjekte aus dem Bereich des IT-Service-Managements (ITSM). Detailprobleme, die nicht frühzeitig beachtet werden und ungelöst bleiben, können im weiteren Projektverlauf zu Verzögerungen und schlechteren Ergebnissen führen. Alles zu Projekte auf CIO.de
- Der Teufel steckt bekanntermaßen im Detail
Wenn ein IT-Services-Management umgesetzt werden soll, kommt es immer wieder zu denselben Schwierigkeiten. Wie lassen sie sich umgehen oder beseitigen? - 1. Aufgelaufene Kosten sind kein Argument
Wenn Entscheidungen zum weiteren Verlauf eines Projekts anstehen, werden die bereits investierten Kosten gern als Argument genannt. Das ist nicht zielführend. Es gilt, an den entscheidenden Stellen des Projekts einen zukunftsbezogenen Business Case zu erstellen. - 2. Kein Projekt ohne ausreichende Ressourcen
Nicht nur ITSM-Vorhaben werden häufig ad hoc gestartet. Das heißt: Es sind noch keine ausreichenden Ressourcen verfügbar. Das liegt oft daran, dass die Berechtigungen zur Ausgabe des Projektmandats überhaupt unklar sind. Abhilfe kann die Einführung eines Projekt-Management-Prozesses schaffen. Dabei sollte unbedingt eine Zuständigkeitsmatrix erstellt werden. Sie gibt an, welche "Rollen" einen Projektauftrag erteilen können - und zwar differenziert nach Projektgröße und -typ. - 3. Grundverständnis geht vor Lösungsansatz
Bei der Projektplanung wird zu schnell über konkrete Lösungsansätze und dafür erforderliche Aktivitäten gesprochen - ohne dass ein einheitliches Verständnis hinsichtlich der genauen Ziele besteht. Die Projektplanung sollte konsequent auf die zu liefernden Ergebnisse ausgerichtet sein. Dabei sind diese Ergebnisse möglichst exakt und in einer messbaren Kategorie zu beschreiben (Spezifikation des Ergebnisses, Form, Umfang, Qualität etc.). - 4. Besser Kanban als Bildschirm oder Beamer
Umfangreiche Projektpläne lassen sich nicht am Bildschirm oder über Beamer visualisieren. Stattdessen ist es sinnvoll, die Kanban-Methode zu nutzen. Das heißt: Visualisierung auf großen Wänden und Verwendung von Karten für die einzelnen Tasks. Das hilft, komplexe Zusammenhänge für alle Beteiligten auf den unterschiedlichen Hierarchiestufen darzustellen. - 5. Jeder muss seine Rolle im Projekt kennen
Viele Ansprechpartner sind sich ihrer Rolle in den Projekten nicht bewusst. Sie sollten aktiv in die Vorhaben eingebunden werden - über Use-Case-Definitionen und die gemeinsame Entwicklung eines Kommunikationsplans. - 6. Der Informationsfluss darf nicht stocken
Zu Projektbeginn ist das Team meist relativ gut informiert. Aber mit zunehmender Dauer sowie außerhalb des eigentlichen Projekts fehlt es häufig an Informationen. Um dem abzuhelfen, ist es sinnvoll, zu Projektbeginn eine Stakeholder-Analyse zu erstellen, aus der sich Form und Umfang der nötigen Informationen ableiten lassen. Dort kann auch definiert werden, wie die Akteure eingebunden werden sollen. Auf dieser Basis lässt sich ein Stakeholder-spezifisches Kommunikationskonzept aufsetzen. - 7. Wenn der Fachbereich keinen Input liefert
Immer wieder krankt ein Projekt auch daran, dass der vereinbarte Input aus den Fachabteilungen ausbleibt. Da helfen zwei Maßnahmen. Zum einen müssen eindeutige Verantwortlichkeiten geschaffen werden. Zum anderen muss den Fachbereichen, auch durch Visualisierung über den Produktstrukturplan, eindrücklich klargemacht werden, wie abhängig das Gesamtprojekt von ihrem Input ist und welche Folgen die ausbleibende Lieferung hat. - 8. Es geht einfach nicht ohne formale Anträge
eue Projekte und Serviceänderungen werden "on the fly" und ohne Spezifikationen direkt an einen Mitarbeiter der IT geleitet. Was ist dagegen zu tun? Es muss ein strukturiertes Verfahren zur Projektantragsstellung und -freigabe etabliert werden, verbunden mit der Definition von Verantwortlichkeiten zur Steuerung dieses Prozesses - beispielsweise durch einen IT-Koordinator. - 9. Arbeitspakete beugen Verzögerungen vor
Mit den Kunden sind klare Termine vereinbart, die aber werden immerzu verschoben. Das schreit nach einem Workshop zur Definition der Arbeitspakete mit Abschätzung der Dauer durch Experten. Dabei ist eine genaue Priorisierung vorzunehmen, der Abstimmungsprozess zu überdenken und der Dokumentationsbedarf zu klären. - 10. Alle müssen den Status des Projekts kennen
Während des Projekts ist häufig unbekannt, wo es eigentlich gerade steht. Damit alle Bescheid wissen, empfehlen sich eine kleine Website sowie ein Newsletter mit Reporting. Auf diese Weise kann jeder Stakeholder die Statusinformationen jederzeit abrufen.
1. Aufgelaufene Kosten sind kein Argument
Wenn Entscheidungen zum weiteren Verlauf eines Projekts anstehen, werden die bereits investierten Kosten gern als Argument genannt. Das ist nicht zielführend. Es gilt, an den entscheidenden Stellen des Projekts einen zukunftsbezogenen Business Case zu erstellen.
2. Kein Projekt ohne ausreichende Ressourcen
Nicht nur ITSM-Vorhaben werden häufig ad hoc gestartet. Das heißt: Es sind noch keine ausreichenden Ressourcen verfügbar. Das liegt oft daran, dass die Berechtigungen zur Ausgabe des Projektmandats überhaupt unklar sind. Abhilfe kann die Einführung eines Projekt-Management-Prozesses schaffen. Dabei sollte unbedingt eine Zuständigkeitsmatrix erstellt werden. Sie gibt an, welche "Rollen" einen Projektauftrag erteilen können - und zwar differenziert nach Projektgröße und -typ. Auf Basis dieser Rollenmatrix lassen sich die Verantwortlichkeiten zur Erteilung von Projektaufträgen klar regeln.
3. Grundverständnis geht vor Lösungsansatz
Bei der Projektplanung wird zu schnell über konkrete Lösungsansätze und dafür erforderliche Aktivitäten gesprochen - ohne dass ein einheitliches Verständnis hinsichtlich der genauen Ziele besteht. Die Projektplanung sollte konsequent auf die zu liefernden Ergebnisse ausgerichtet sein. Dabei sind diese Ergebnisse möglichst exakt und in einer messbaren Kategorie zu beschreiben (Spezifikation des Ergebnisses, Form, Umfang, Qualität etc.). Eventuellen Streitigkeiten lässt sich vorbeugen, indem die Abnahmekriterien und -verfahren vorab beschrieben werden.
4. Besser Kanban als Bildschirm oder Beamer
Umfangreiche Projektpläne lassen sich nicht am Bildschirm oder über Beamer visualisieren. Stattdessen ist es sinnvoll, die Kanban-Methode zu nutzen. Das heißt: Visualisierung auf großen Wänden und Verwendung von Karten für die einzelnen Tasks. Das hilft, komplexe Zusammenhänge für alle Beteiligten auf den unterschiedlichen Hierarchiestufen darzustellen.
5. Jeder muss seine Rolle im Projekt kennen
Viele Ansprechpartner sind sich ihrer Rolle in den Projekten nicht bewusst. Sie sollten aktiv in die Vorhaben eingebunden werden - über Use-Case-Definitionen und die gemeinsame Entwicklung eines Kommunikationsplans.
6. Der Informationsfluss darf nicht stocken
Zu Projektbeginn ist das Team meist relativ gut informiert. Aber mit zunehmender Dauer sowie außerhalb des eigentlichen Projekts fehlt es häufig an Informationen. Um dem abzuhelfen, ist es sinnvoll, zu Projektbeginn eine Stakeholder-Analyse zu erstellen, aus der sich Form und Umfang der nötigen Informationen ableiten lassen. Dort kann auch definiert werden, wie die Akteure eingebunden werden sollen. Auf dieser Basis lässt sich ein Stakeholder-spezifisches Kommunikationskonzept aufsetzen.
7. Wenn der Fachbereich keinen Input liefert
Immer wieder krankt ein Projekt auch daran, dass der vereinbarte Input aus den Fachabteilungen ausbleibt. Da helfen zwei Maßnahmen. Zum einen müssen eindeutige Verantwortlichkeiten geschaffen werden. Zum anderen muss den Fachbereichen, auch durch Visualisierung über den Produktstrukturplan, eindrücklich klargemacht werden, wie abhängig das Gesamtprojekt von ihrem Input ist und welche Folgen die ausbleibende Lieferung hat.
8. Es geht einfach nicht ohne formale Anträge
Neue Projekte und Serviceänderungen werden "on the fly" und ohne Spezifikationen direkt an einen Mitarbeiter der IT geleitet. Was ist dagegen zu tun? Es muss ein strukturiertes Verfahren zur Projektantragsstellung und -freigabe etabliert werden, verbunden mit der Definition von Verantwortlichkeiten zur Steuerung dieses Prozesses - beispielsweise durch einen IT-Koordinator.
9. Arbeitspakete beugen Verzögerungen vor
Mit den Kunden sind klare Termine vereinbart, die aber werden immerzu verschoben. Das schreit nach einem Workshop zur Definition der Arbeitspakete mit Abschätzung der Dauer durch Experten. Dabei ist eine genaue Priorisierung vorzunehmen, der Abstimmungsprozess zu überdenken und der Dokumentationsbedarf zu klären.
10. Alle müssen den Status des Projekts kennen
Während des Projekts ist häufig unbekannt, wo es eigentlich gerade steht. Damit alle Bescheid wissen, empfehlen sich eine kleine Website sowie ein Newsletter mit ReportingReporting. Auf diese Weise kann jeder Stakeholder die Statusinformationen jederzeit abrufen. Alles zu Reporting auf CIO.de