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?
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?
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 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 verursacht erhebliche finanzielle 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 gäbe.
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.
Wollen Sie gemeinsam mit uns das Potential in Ihren Daten zum Leben erwecken? Dann sollten wir reden!
Sichere Datenverwaltung mit der Databricks Plattform: Best Practices Das Verständnis von Datensicherheit spielt eine entscheidende Rolle beim Schutz vor Bedrohungen wie Datenübernahmen oder -lecks. Die
Fabric vs. Databricks: Ein Umfassender Vergleich für Datengetriebene Unternehmen In der sich ständig weiterentwickelnden Landschaft der Datenverarbeitung und -analyse stehen Unternehmen vor der Herausforderung, die
Neue Funktionen der AI/BI Dashboards von Databricks im Detail Databricks hat mit der Einführung seiner Data Intelligence Platform einen bedeutenden Schritt unternommen, um die Interaktion
