Wann beginnt ein Projekt zu sinken?
Jedes IT-Projekt beginnt ähnlich. Es gibt ambitionierte Pläne, einen Zeitplan, die Präsentation erster Mockups und die Überzeugung, dass das Unternehmen in wenigen Monaten ein modernes System nutzen wird. Anfangs sieht alles vielversprechend aus, doch mit der Zeit treten die ersten Verzögerungen auf. Der Termin verschiebt sich um eine Woche, später um einen Monat. Die Anzahl der Fehler steigt, die Kommunikation mit dem Auftragnehmer wird immer schwieriger, und die Antworten lauten zunehmend: „Noch einen Moment“, „Das ist nur eine kleine Anpassung“ oder „Wir sind schon fast fertig.“
Irgendwann stellt sich heraus, dass das Unternehmen statt eines fertigen Produkts ein unvollendetes Projekt hat, das niemand übernehmen will.
Das ist ein Szenario, das viel häufiger vorkommt, als man denken würde.
Das größte Problem ist nicht der Code
Die meisten Unternehmer gehen davon aus, dass bei einem nicht funktionierenden Projekt der schlecht geschriebene Code schuld ist. Manchmal ist das auch so. In der Praxis liegt das Problem jedoch wesentlich öfter tiefer.
Es fehlt an Dokumentation. Die Architektur wurde "on the fly" entwickelt. Es gibt keine automatisierten Tests. Integrationen wurden provisorisch umgesetzt. Neue Funktionen wurden ohne Analyse der Auswirkungen auf das Gesamtsystem hinzugefügt. Infolgedessen führt schon eine kleine Änderung zu weiteren Fehlern.
Das ist ein bisschen wie eine Hausrenovierung ohne Plan. Jedes weitere Zimmer lässt sich noch fertigstellen, aber mit der Zeit stellt man fest, dass die Wände nicht dort stehen, wo sie sollten, Installationen zufällig verlegt wurden und der Umbau immer kostspieliger wird.
Wann sollte man „Stopp“ sagen?
Einer der schwierigsten Momente für den Geschäftsinhaber ist die Entscheidung, die Zusammenarbeit mit dem bisherigen Auftragnehmer zu beenden. Viele Unternehmer zögern damit zu lange.
Warum?
Weil das Projekt bereits viel Geld verschlungen hat.
Weil es Zeitverschwendung wäre.
Weil es vielleicht „noch klappen“ könnte.
Die Psychologie nennt das den Versunkene-Kosten-Effekt. Je mehr man bereits investiert hat, desto schwerer fällt es zuzugeben, dass der aktuelle Kurs ins Nichts führt.
Manchmal ist die beste Entscheidung jedoch nicht, weiter Geld in dasselbe Problem zu stecken, sondern das Projekt zu stoppen und die Lage ruhig zu analysieren.
Lässt sich jedes Projekt retten?
Nein. — Und das sollte man ehrlich sagen.
Es gibt Projekte, deren Reparatur mehr kosten würde als eine Neuentwicklung. Es kommt auch vor, dass die verwendete Technologie bereits veraltet ist oder die Architektur so gestaltet wurde, dass eine weitere Entwicklung unmöglich ist.
Deshalb sollte der erste Schritt niemals das Versprechen einer schnellen Lösung sein.
Der erste Schritt sollte ein Audit sein.
Erst nach sorgfältiger Analyse des Codes, der Dokumentation, der Infrastruktur und der Prozesse kann man beantworten, ob es wirtschaftlich sinnvoller ist, die bestehende Lösung zu reparieren oder ein neues Projekt zu starten.
Ein guter Technologiepartner sagt nicht, was der Kunde hören will.
Er sagt, was betriebswirtschaftlich am besten ist.
Wie sieht das Rettungsprojekt in der Praxis aus?
Entgegen der Erwartung beginnt es nicht mit Programmierung.
Zuerst muss verstanden werden, womit wir es zu tun haben.
Wir analysieren die Systemarchitektur, die Codequalität, die Kommunikation zwischen Modulen, den Datenschutz, die Performance und die Möglichkeiten zur weiteren Entwicklung. Wir prüfen die Dokumentation, die Änderungshistorie und die verwendeten Technologien. Oft ist bereits nach wenigen Tagen klar, wo das eigentliche Problem liegt.
Erst dann wird ein Aktionsplan erstellt.
Manchmal reicht es, den Code zu ordnen und einige Schlüsselkomponenten zu verbessern. Ein anderes Mal ist ein Umbau bestimmter Module notwendig. Es kommt auch vor, dass die vernünftigste Lösung darin besteht, ein neues System zu entwickeln und das bereits Erarbeitete zu übernehmen.
Es gibt keine zwei identischen Projekte.
Und es gibt kein Patentrezept, um sie zu retten.
Warum ist die Übernahme eines Projekts schwieriger als eine Neuentwicklung?
Diese Frage hören wir oft von Kunden.
Die Antwort ist einfach.
Wenn wir ein System von Grund auf neu entwickeln, kennen wir jede Designentscheidung. Wir wissen, warum eine bestimmte Lösung gewählt wurde und welche Annahmen zugrunde lagen.
Beim Übernehmen eines fremden Projekts müssen wir dieses Wissen erst rekonstruieren.
Das ist ein bisschen so, wie eine Baustelle zu übernehmen, bei der das vorherige Team den Platz ohne Pläne, ohne Dokumentation und ohne Informationen darüber verlassen hat, was bereits erledigt wurde.
Deshalb erfordert die Rettung von Projekten nicht nur Programmierfähigkeiten, sondern auch architektonische, analytische und konzeptionelle Erfahrung.
Ein Technologiepartner sollte auch dann an Ihrer Seite stehen, wenn Probleme auftreten
Ein guter Software‑House erkennt man nicht daran, wie es ein Projekt startet.
Man erkennt es daran, wie es reagiert, wenn Schwierigkeiten auftreten.
Nicht alles lässt sich vorhersehen. Geschäftsanforderungen, Technologien und Nutzerbedürfnisse ändern sich. Entscheidend ist jedoch, ob das Team in der Lage ist, Lösungen zu finden, Risiken klar zu kommunizieren und gemeinsam mit dem Kunden die besten Entscheidungen zu treffen.
Genau dann wird Vertrauen aufgebaut.
Wie arbeiten wir bei Web24?
Bei Projekten, die übernommen werden müssen, gehen wir mit großer Zurückhaltung vor.
Wir geben keine Versprechungen nach dem ersten Gespräch.
Zuerst analysieren wir die Lage. Wir prüfen, was bereits umgesetzt wurde, was wiederverwendet werden kann und was neu aufgebaut werden muss. Erst anschließend erstellen wir Empfehlungen und einen Plan für die weiteren Schritte.
Unser Ziel ist nicht, weitere tausend Codezeilen zu schreiben.
Unser Ziel ist es, das Projekt dahin zu bringen, wo es das Geschäft wirklich unterstützt.
Zusammenfassung
Wenn Ihr Projekt feststeckt, der Auftragnehmer nicht mehr reagiert, der Zeitplan nur noch theoretisch existiert und jede Korrektur neue Fehler erzeugt, bedeutet das noch nicht, dass alles verloren ist.
In vielen Fällen lässt sich das Problem lösen.
Man muss jedoch mit einem Schritt beginnen - einer gründlichen Analyse der Situation.
Denn bevor man beginnt, ein Projekt zu retten, sollte man zuerst herausfinden, warum es überhaupt zu sinken begonnen hat.
