Change Management IT-Projekte

Change Management – Die 5 größten Fehler in IT-Projekten und wie Entscheider sie vermeiden können

Durch konstruktives Change Management Fehler vermeiden

Ein weiterer wichtiger Punkt bei der Umsetzung von IT-Projekten ist die Behandlung von Änderungswünschen während der laufenden Projektphase. In den letzten Jahren habe ich kein Projekt erlebt bei dem der Projektbesitzer nicht mehrfach besprochene Anforderungen komplett entfernt oder signifikant angepasst hat. Dies kann je nachdem welche Abhängigkeiten bestehen und wie einzelne Komponenten des Projekts aufgebaut sind (Datenbank, Backend, Frontend) zu umfangreichen Verwerfungen führen. Generell gilt – je mehr Abhängigkeit zwischen Komponenten und Bausteinen eines Projekts herrscht, desto eher können Planungsänderungen mit viel Aufwand verbunden sein. Viel Aufwand ist daraufhin meistens auch mit viel Kosten oder nervenaufreibenden Diskussionen verbunden, die selten zielführend sind.

Ergebnis ist nämlich, dass die Entwickler entweder (deutlich) mehr Geld bekommen und das Projektbudget überschritten wird (wenn dies überhaupt finanziell möglich ist), die Entwickler einknicken und für den Rest des Projekts komplett demotiviert sind oder das Projekt scheitert und im schlimmsten Fall noch ein Rechtsstreit entbrennt, dessen Ausgang niemand vorhersehen kann. Allein die dabei entstehenden Nebenkosten für Gutachter und ähnliches können schnell sogar das eigentliche Projektbudget übersteigen. Daher ist es für beide Parteien immer empfehlenswert sich gütlich zu einigen. Aber wie sollte man jetzt eigentlich mit Änderungen an den Anforderungen umgehen?

Perfektionismus vermeiden

In vielen Lebenslagen kann Perfektionismus eine nützliche Eigenschaft sein. Bei IT-Projekten ist es ein guter Ratgeber um sich möglichst leicht in die Insolvenz zu treiben. Wichtig ist zu wissen, dass jedes zusätzliche Feature und jede Anpassung, selbst wenn Sie klein erscheinen, umfangreiche Arbeit nach sich ziehen können. Beispielsweise möchte ich als Auftraggeber, dass Benutzer in einer Lokal-App für Städte lokale Events sehen können. An sich keine wilde Sache, aber was ist eigentlich die Konsequenz daraus?

  • Erweiterung und Anpassung der Datenbank. Eventuell müssen bestehende Tabellen angepasst werden was weitere Adjustierung in von der Aufgabe völlig unabhängigen Funktionen nach sich zieht.
  • Der Designer für das Projekt muss hinzugezogen werden um sich zu überlegen wie man das Feature am besten darstellt. Absprache und Beratung zwischen Entwickler, Designer und Auftraggeber nötig.
  • Umsetzung des Designs im Frontend auf Code Ebene (responsiveness / Benutzbarkeit der Komponenten)
  • Umsetzung der Logik (Einbindung von Text, Titel, Bild, Anpassung der Bildgröße, korrekte Darstellung und Berechnung der visuellen Darstellung für Teilnehmer, Bewertung etc.)
  • Erstellen eines Backends in welchem Events gelöscht, bearbeitet und erstellt werden können (Drei komplett neue und eigenständige Funktionen)
  • Schnittstellen Anbindung an Facebook oder andere Plattformen um aktuelle Daten zu bekommen
  • Logik die verhindert das bearbeitete und gelöschte Events nochmal vom Crawler der die Daten von anderen Plattformen holt überschrieben werden.
  • Funktion für Benutzer um zuzusagen / abzulehnen
  • Testen der Funktionalität an verschiedenen Stellen und mit unterschiedlichen Szenarien
  • Eventuell sogar Eingliederung in bestehendes Berechtigungskonzept in der Verwaltung der Events (welcher Admin / Backend Nutzer darf was)
  • Eventuell Eingliederung in ein Sprachsystem
  • Anpassung des Designs für IOS und Android

Wenn man genauer darüber nachdenkt und den technischen Überblick hat, kommt man schnell auf sehr viele Punkte die an so einer eigentlich simplen Funktion dranhängen. Bei diesem Beispiel ist es noch möglich die Funktion unabhängig von anderen Parts der App einzubauen. Stellt man sich nun vor, dass bestehende Komponenten noch umgeschrieben werden müssen kann man schnell mal über einen Monat Entwicklungszeit in so ein Feature stecken. Dies geht mit einem späteren Launch, eventuell gebrochenen Vereinbarungen, mehr Kosten u.v.m. einher.

Nun sollte man sich sehr gut überlegen ob man diese Funktion wirklich hier und heute jetzt gleich zum ersten Launch der App benötigt oder ob die Benutzer nicht auch erstmal gut ohne leben können und sich später über eine Erweiterung der App freuen können

Das Zauberwort heißt hier MVP (minimal viable product) – soweit man nicht mit umfangreichen Ressourcen gesegnet ist um ein mehrköpfiges Entwicklerteam über lange Zeit ohne Bedenken zu unterhalten, sondern auf Einnahmen aus dem Projekt oder Investoren angewiesen ist. Man sollte sich immer Gedanken machen wo rationalisiert werden kann, welche Features wirklich zum aktuellen Zeitpunkt nötig sind und was für Auswirkungen eine Änderung auf den Projektverlauf hat.

 

Software-Architektur im Fokus

Software-Architektur ist der Punkt an dem meiner Erfahrung nach am ehesten gespart wird und das mit fatalen Folgen. Ich kann ein Projekt schlampig aufsetzen ohne das der Benutzer überhaupt etwas davon merkt. Darum kann auch das von der Funktionalität her absolut gleiche Projekt für 10.000€ und für 30.000€ umgesetzt werden und die 30.000€ sind hierbei kein überteuerter Preis, sondern kommen einfach daher, dass man sich genug Zeit nimmt um es vernünftig zu machen.

Da der Auftraggeber dies jedoch nicht sehen oder anfassen kann und dadurch oft Phasen entstehen in denen nichts Neues das direkt visuell erkennbar ist vorgestellt werden kann wird hier gerne gespart. Oft weil der Auftraggeber schlichtweg kein Verständnis für die Folgen und Unterschiede hat da Ihm das technische Know-How fehlt. Dies kann man Ihm auch gar nicht vorwerfen. Das Ergebnis ist jedoch, dass es spätestens wenn es zu komplexen Fehlern, neuen Funktionen die so am Anfang noch gar nicht bedacht waren oder Änderungen bestehender Funktionalitäten kommt ernsthafte Probleme entstehen. Diese kann man in der Regel nicht mehr in den Griff bekommen außer man startet das Ganze Projekt nochmal neu. Man könnte sagen: Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende.

Jedoch trifft der Auftraggeber meist die Entscheidung das kaputte Sofa über Jahre hinweg zu flicken und zusammenzuhalten anstatt ein neues zu kaufen. Dies geschieht und erheblichen finanziellen Aufwendungen die sinnvoller investiert werden könnten und hat fast immer negative Auswirkungen auf den Zeitplan. Man wird träge und teuer. Besonders in Großkonzernen sind solche Projekte gang und gebe.

 

 

Wenn sie erfahren möchten, wie Sie katastrophale Fehler in Ihren IT-Projekten vermeiden können, dann holen Sie sich kostenlos unser Whitepaper mit erprobten Best-Practice-Lösungen. Mit regelmäßigen Inhalten, die Ihren Projektalltag erleichtern.

Melden Sie sich zu unserem Newsletter an

Ich möchte den Newsletter erhalten (Sie können Ihn jederzeit abbestellen)

0 Kommentare

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar