0

8 einfache, aber effektive Schritte, die Dir helfen, Dein IT-Projekt erfolgreich abzuschließen

Letzte Woche war ich viel unterwegs. Ich hatte das Glück Kundetermine und interessante Veranstaltungen miteinander verbinden zu können. Am Dienstag wurde in Frankfurt das Buch Perspektivwechsel im IT-Service-Management vorgestellt. Am Mittwoch durfte ich zu Gast beim itSMF Regionalforum Nordbayern/Franken sein. Dort habe ich über OBASHI und meine Anwendungsfälle gesprochen. Den Abschluss bildete das Sommerfest meines Arbeitgebers in Berlin. Thema des Vortrages war „Die Zukunft der IT hat zwei Geschwindigkeiten: agil und stabil“. Genau dort ist es dann passiert: Als ich vor der Veranstaltung in mein Hotel einchecken wollte, dauerte es etwas länger und beim umherschauen blieb mein Blick an einem Schild auf dem Tresen hängen:

Damit war der Übeltäter identifiziert. In dem Moment wollte ich mir gar nicht vorstellen, was am nächsten Morgen passiert, wenn alle auschecken wollen. Das kannst Du Dir sicher auch vorstellen. Da ich das gelesen hatte, konnte ich wenigstens gleich alles für den nächsten Morgen erledigen.

Du möchtest den Artikel als Podcast hören? Klicke hier!

 

Mögliche Ursachen

Ich habe mir Gedanken gemacht, was kann alles schief gegangen sein, damit man als Unternehmen gezwungen ist, seine Kunden über Probleme mit einem IT-Projekt zu informieren. Dir fallen bestimmt auf Anhieb einige andere Gründe dafür ein. Auf folgende bin ich gekommen:

• Nutzer wurden nicht ausreichend geschult
• Funktionen, die häufig gebraucht werden, sind versteckt
• es fehlen Funktionen und es gibt zeitaufwendige Workarounds
• der gewohnte Arbeitsfluss hat sich verändert
• das Programm läuft langsam oder stürzt häufig ab
• Programm nur in Englisch
• Zu viele Neuerungen

Die Liste können wir beide gemeinsam fortsetzten. Sie ist bestimmt nicht spezifisch für dieses Projekt, sondern trifft auf viele andere Projekte zu. Das sind meine Ideen, warum es zu diesem Zettel gekommen sein könnte.

Verschiedene Blickwinkel

Warum hat mich das Erlebnis so bewegt, dass ich darüber schreibe? Dazu darfst Du den Betrachtungspunkt eines Geschäftsführers einer Hotel-Gruppe einnehmen. Du hast dabei vor allem damit zu kämpfen, dass immer noch mehr Hotelbetten in Deutschland entstehen. Dein Problem ist damit eine sinkende Auslastung und somit ein sinkender Erlös pro verfügbarem Zimmer. In der Fachsprache Revenue per available room.

Wechsle jetzt bitte in die Rolle des Gastes. Du stehst auf, gehst frühstücken und dann stehen 15 Menschen beim Auschecken vor Dir. Es kommt Dir vor, als würde jeder ewig brauchen. Bei mir entwickelt sich Gefühl schon, wenn nur zwei oder drei vor mir dran sind. Dann liest Du den Zettel und entscheidest Dich spontan beim nächsten Mal das Hotel nebenan oder gegenüber zu buchen.

Zurück in der Rolle des Hotelmanagers: Da dieses Problem nicht nur ein Hotel, sondern alle Deine über 50 Hotels in Deutschland oder sogar alle mehr als 350 Hotels weltweit betrifft, kann dies zu ernsthaften wirtschaftlichen Problemen führen. Das ist meine Annahme. Das nicht ganz rundlaufende IT-Projekt sorgt aber auf jeden Fall für unzufriedene Gäste.

Ich habe ein wenig recherchiert. Die Hotelgruppe hat in den letzten Jahren im Backend SAP eingeführt und ist nun dabei sein Frontend umzustellen. Ohne Einzelheiten zu kennen, auf jeden Fall ein kompliziertes, wenn nicht gar komplexes Vorhaben.

Das Interessante ist, dass in jeder Projektphase der Grundstein für die aktuellen Probleme gelegt worden sein kann.

Ich möchte jetzt mir die die Projektphasen durchgehen und schauen, welche Fehler vermieden werden können. Natürlich wird die Liste nicht vollständig sein.

1. Warum und was

Bevor es irgendwie losgeht, wird ein Projekt initiiert. Das bedeutet, dass sich vor allem die Business-Seite des Unternehmens Gedanken über die Ziele des Projektes macht. Also mindestens eine der folgenden Fragen beantwortet:

• Warum soll das Projekt durchgeführt werden?
• Was soll mit dem Projekt erreicht werden?
• Welche Veränderungen sollen durch das Projekt initiiert werden?
• Wie merken wir, dass das Projekt erfolgreich umgesetzt wurde?

Ich glaube, dass die Hotelgruppe sich darüber Gedanken gemacht hat. Bei meiner Recherche bin ich darauf gestoßen, dass es ein Ziel ist, die IT-Systeme des Unternehmens effizienter einzusetzen und den Online-Vertrieb zu stärken.

An gleicher Stelle habe ich noch mehr Ziele des Unternehmens gefunden, die die Tragweite des Problems noch deutlicher machen. Man möchte durch erstklassigen Service zur Gästezufriedenheit beitragen. Und sie werden noch deutlicher: Kunden sollen sich auf Reisen fragen, ob sich in der Stadt ein entsprechendes Hotel befindet.

Wenn das mal keine Vision ist! Wie würdest Du als Geschäftsführer auf das schief gelaufene IT-Projekt reagieren – die Vision im Hinterkopf?

Das Beispiel zeigt es ganz deutlich: Jeder Mitarbeiter, auch jeder IT-Mitarbeiter, darf die Vision eines Unternehmens, seine Ziele und seine Prozesse kennen. Nur so, kann er sein Handeln und seine Entscheidungen dagegen prüfen und das Beste fürs Unternehmen erreichen.

2. Gründliche Analyse

Die nächste Phase ist nicht die Anforderungsanalyse, sondern die Business-Analyse. Seitdem ich mich mit diesem Thema auseinandersetze, lege ich darauf sehr viel Wert. Denn, nicht für jedes Problem ist die Lösung ein IT-System. Prozessänderungen, Veränderung der Organisation, umräumen des Arbeitsplatzes oder andere technische Veränderungen sind Beispiele für mögliche Antworten auf ein Problem. Wir tendieren heute sehr schnell dazu, ein neues IT-System einzuführen.

Der erste Schritt ist das Erforschen der Situation. Entgegen unserer grundsätzlichen Lösungsorientierung, beschäftigt sich Business-Analyse ausführlich mit dem Problem. Es wird die aktuelle Situation analysiert. Als Analystechniken kommen zum Beispiel MindMaps oder sogenannte Rich Pictures zum Einsatz. Dabei handelt es sich um die grafische Darstellung von Prozessen, Zusammenhängen und Umfeld. Dies verschafft Klarheit, weil Visualisierung für Transparenz sorgt.

Im nächsten Schritt werden die verschiedenen Perspektiven der Stakeholder eingenommen und das Problem bzw. die Situation aus Ihrer Brille analysiert. Bei der Hotelgruppe sind das auf jeden Fall der Gast, die Rezeptionsmitarbeiter, das Backoffice, die IT, die Geschäftsleitung, der Mensch, der buchen möchte und sicher noch einige andere. Eine Möglichkeit in deren Welt einzutauchen ist das Business Activity Modelling oder die CATWOE-Methode. Zufällig sprechen auch Ingrid und Peter Gerstbach in ihrem aktuellen Podcast über CATWOE – den findest Du hier.

Im nächsten Schritt analysierst Du den Bedarf. Was soll durch das Projekt erreicht oder verändert werden. GAP-Analyse und die Aktivitätsanalyse sind gute Techniken, um den Bedarf der Stakeholder zu verstehen. Darauf folgt die Untersuchung der Möglichkeiten. Es ist wichtig, dass Du hier nicht gleich auf das IT-System abstellst, sondern auch andere Optionen identifizierst. In dieser Phase geht es um den Business Case, Kosten, Nutzen, Auswirkungen und Risiken der einzelnen Optionen.

3. Anforderungsanalyse

Erst danach darfst Du die Anforderungen aufnehmen und definieren. Normalerweise überspringen wir die vorgenannten Phasen und kommen gleich nach Projektstart zur Anforderungsanalyse oder Englisch dem Requirements-Engineering.

Viele Probleme am Ende eines Projektes können durch dieses Vorgehen vermieden werden. Fehlende Funktionen, das Verstecken der wichtigen Funktionen, fehlende Programmsprachen oder unrunde Arbeitsabläufe gehören dazu. Dazu biete die Disziplin Business-Analyse viele Werkzeuge. 

Spätestens in der Phase der Aufnahme der Anforderungen empfehle ich den Einsatz von Werkzeugen aus dem Bereich Agilität und Lean. Dies trifft auch für die dritte Phase zu – die Realisierung. Egal ob es sich um eine Softwareentwicklung, Customizing oder Konfiguration eines Standardsystems oder eine Mischung aus beidem handelt. Es ist auf jeden Fall eine gute Idee, wenn Du Deine Realisierungsphase in kurze Iterationen teilst. Die Länge hängt dabei vom Kontext ab. Alles zwischen einem Tag und 12 Wochen habe ich bereits erlebt.

4. Iteratives Vorgehen

Jede Iteration besteht aus Anforderungsanalyse, Realisierung, Tests und Abnahme. Grundlage ist die Idee, dass Du Dich zum spätest möglichen Zeitpunkt mit der genauen Definition und Realisierung eines Features beschäftigst. Das erlaubt Dir eine Flexibilität in Bezug auf sich ändernde Rahmenbedingungen und Anforderungen des Kunden. Apropos Kunde, Du definierst natürlich gemeinsam mit ihm die Anforderungen. Zum Abschluss der Iteration demonstrierst Du ihm das Resultat der Arbeit und erfährst so, ob das Ergebnis die Erwartungshaltung trifft. Dazwischen ist das Testen der Funktionen selbstverständlich nicht zu vernachlässigen.

Mit Hilfe dieses Vorgehens stellst Du sicher, dass auch bei langer Projektdauer genau das entsteht, was der Kunde möchte. Durch die Einbindung des Kunden, bekommst Du frühzeitig Feedback und der Kunde ist am Entstehungsprozess beteiligt. Die zeitraubende Testphase am Ende eines Projektes entfällt und vor allem, die damit verbundenen Nachbesserungen sowie die Unzufriedenheit auf beiden Seiten.
Langsame Reaktionen, Funktionen am falschen Platz oder ganz fehlende Funktionen werden so viel früher erkannt, bevor das Produkt zum Live-Betrieb kommt.

Ich habe letzte Woche ein Projekt kennengelernt, welches innerhalb der einzelnen Iterationen nach dem V-Modell gearbeitet hat – auch keine schlechte Idee.

5. Daily Standup

Im agilen Werkzeugkasten gibt es noch viele weitere Praktiken, die Dir helfen ein Projekt zu realisieren. In meinem Whitepaper „7 agile Praktiken für ein besseres IT-Service-Management“ stelle ich Dir unter anderem auch das Daily Standup vor. Grundgedanke hier ist, die Transparenz durch ein festes Kommunikationsritual zu erhöhen. Ein- oder mehrmals am Tag treffen sich alle Teammitglieder vor dem Board und reden über das was sie getan haben, erledigen werden und vor allem über ihre Probleme. So werden diese schnell bekannt und können gelöst werden. Der Projektleiter erhält durch das Standup und das Board einen tiefen Einblick in den Stand des Projektes bei viel weniger Zeiteinsatz. Die restlichen fünf Methoden beschreibe ich Dir im Whitepaper – dieses findest Du hier.

Eine Vorgehensweise mit agilen bzw. lean Werkzeugen sorgt dafür, dass Features viel weniger Fehler aufweisen, viel besser den Vorstellungen des Kunden entsprechen und häufig in kürzer Zeit ausgeliefert werden. Unabhängig von Art und Inhalt eines Projektes kann damit das Risiko stark minimiert und besser beherrscht werden.

6. Ende-zu-Ende-Monitoring

Spätestens in der Transitionsphase bekommst Du die Frage nach dem Sizing der Server, Storage, Netzwerk, Client und WAN-Anbindung gestellt. Gerade in Hinblick auf eine schnelle Reaktion auf Nutzereingaben ist das ein kritischer Punkt. Häufig lässt sich diese Frage aber nicht genau beantworten. Einfach weil viel zu viel Innovation in einem Projektergebnis steckt. Es fehlen Dir die Erfahrungswerte.

Für mich haben sich da zwei sinnvolle Wege bewährt, mit der Unsicherheit umzugehen:

1. Phasenweiser Rollout : Du beginnst mit einer kleinen Gruppe von Nutzer, beispielsweise einem Hotel. Wenn das gut läuft, nimmst Du ein weiteres Hotel dazu. Dabei beobachtest Du die Veränderung im Verhalten des Backends und des Netzwerks. So bekommst Du mit jedem weiteren Schritte ein besseres Gefühl, wie Dein System reagiert. Pass dabei aber bitte auf, dass Du den Rollout nicht ausschließlich in verkehrsschwachen Zeiten durchführst – denn dann kommt das böse Erwachen später. Beispielsweise die Personenkontrolle eines kleinen Regionalflughafens mag zwischen Februar und März ausreichend dimensioniert sein, aber ob sie das wirklich ist, erkennst Du am ersten Tag der Sommerferien.
2. Natürlich kannst Du Dich während eines Rollouts auf Dein Gefühl und die Messwerte der einzelnen technischen Parameter verlassen. Viel besser ist es aus meiner Erfahrung, dass Du die Performance aus Sicht der Anwender im Blick behältst. Dafür kannst Du die wichtige Klickfolgen in der Applikation aufzeichnen und auf einem Robotor-PC in jedem Hotel abspielen. So bekommst Du frühzeitig verlässliche Indikatoren, wie sich die Applikation aus Nutzersicht verhält. Die Technik kannst Du auch schon früh im Projekt für die kontinuierlichen Integrationstests einsetzen. Mögliche Werkzeuge gibt es von Open Source (AutoIT / AutoHotKey / Selenium für Webanwendungen) bis zum professionellen Werkzeug wie CitraTest.

7. Schulung und Begleitung

In die Transitionsphase fällt in der Regel auch die Schulung der Mitarbeiter, die das neue System nutzen sollen. Ein entscheidender Faktor für den Erfolg eines Projektes. Menschen haben unbewusst Angst vor Veränderungen und Neuem. Wenn dann etwas nicht so funktioniert wie erwartet oder gewohnt, dann hat das neue System gleich einen schlechten Stand. Die Einarbeitung dauert dadurch viel länger und die Produktivität sinkt und damit die Zufriedenheit der Hotelgäste.

In der Phase der Business-Analyse hast Du festgestellt, was sich alles ändert. Genau auf diese Änderungen und die neue Software werden die Benutzer geschult. Wie ein konkretes Schulungskonzept aussieht, hängt von den Veränderungen und dem Rahmen ab.

Du kannst die Inbetriebnahme und den Übergang durch eine einfache Maßnahme unterstützen: Stelle für die Zeit des Übergangs einen oder mehrere Kollegen zusätzlich vor Ort zur Verfügung. Diese dürfen die Software und den Prozess in- und auswendig kennen und unterstützen bei Fragen.
Abgewandelt kann es auch bedeuten, dass bei einem stufenweisen Rollout Mitarbeiter der nächsten Rolloutstufe in den aktuellen Rollout involviert sind und so die Mannschaft verstärken. Learning by doing ist immer noch die beste Variante und schafft Selbstvertrauen.

8. Veränderung messen

Hast Du das neue System in den Betrieb überführt, endet in der Regel das Projekt. Leider enden damit auch einige der in der Transitionsphase durchgeführten Maßnahmen wie die Überwachung aus Nutzersicht. Auch die Keyuser, die den Rollout begleitet haben, sollten nicht einfach verschwinden. Beides kannst Du in den Betrieb übernehmen. Beim Ende-zu-Ende-Monitoring ist das klar. Ein Teil der Keyuser könnte im Helpdesk seine Aufgabe weiterverfolgen und bei Fragen viel schneller und kompetenter weiterhelfen als der allgemeine IT-Helpdesk.

Haben das Geschäft und die IT sich im Vorfeld des Projektes Gedanken gemacht, was durch das Projekte erreicht werden soll und wie die Messwerte dazu aussehen, dann kann jetzt in der Betriebsphase überprüft werden, ob der erhoffte Erfolg eintritt. Vor allem kann aber sehr schnell gegengesteuert werden.

Nehmen wir zum Beispiel an, dass das Ziel für das neue Hotelsystem die Steigerung der Buchungsrate über das Internet ist, dann kann das recht einfach ermittelt werden. Zu diesem Thema „Wertbeitrag der IT“ werde ich in der übernächsten Podcastfolge mit Dr. Peter Samulat sprechen. 

Wie ich Dir eingangs schon sagte, habe ich keine Ahnung was wirklich bei der Einführung des Hotelsystems schief gegangen ist. Alles was ich aufgezählt habe, sind Idee, was die Ursache gewesen sein könnte. Für Dich ist wichtig, dass Du von Anfang an ein Projekt gewissenhaft angehen darfst – immer die gewünschten Veränderungen im Blick. In jeder Projektphase gibt es Möglichkeiten, zum Gelingen beizutragen. Einige Anregungen waren für Dich vielleicht dabei. Du hast bestimmt noch einige mehr – nutze bitte die Kommentarfunktion und diskutiere mit mir und den anderen Mitgliedern unsere Community.