Über gescheiterte Software-Projekte wird ungern gesprochen. Dabei sind sie häufiger, als jede Referenzliste vermuten lässt – und die Gründe wiederholen sich so verlässlich, dass sich daraus arbeiten lässt.
Die typischen Muster
Zu viel auf einmal. Alle Anforderungen sollten in Stufe eins hinein. Nach acht Monaten war nichts fertig und die Geduld aufgebraucht.
Kein fachlicher Eigentümer. Es gab eine IT-Ansprechperson, aber niemanden, der fachlich entschieden hat, wie die Prozesse aussehen sollen.
Daten zu spät angefasst. Die Übernahme wurde ans Ende gelegt. Dann stellte sich heraus, dass die Altbestände nicht in der erwarteten Form vorliegen.
Anpassungen ohne Bremse. Jeder Sonderwunsch wurde umgesetzt. Am Ende war das System so speziell, dass ein Update zum Risiko wurde.
Keine Einweisung. Das System war fertig, das Team wusste nicht, warum es damit besser arbeiten sollte. Also arbeitete es weiter mit Excel.
Betreuung eingeschlafen. Der ursprüngliche Partner ist nicht mehr erreichbar, hat das Geschäft aufgegeben oder das Projekt still abgegeben.
Wie wir übernehmen
- Bestandsaufnahme, ohne zu bewerten. Was ist installiert, in welcher Version, mit welchen Anpassungen, Schnittstellen und Lizenzen? Wir dokumentieren den Ist-Stand schriftlich.
- Gespräche mit den Anwendern. Nicht mit der Projektleitung allein. Die Leute, die täglich damit arbeiten sollen, wissen am genauesten, woran es hängt.
- Trennung von brauchbar und ballastig. Vieles aus dem ersten Anlauf ist verwendbar. Manches sollte weg – auch wenn es Geld gekostet hat.
- Ein kleiner, sichtbarer erster Schritt. Nicht der vollständige Relaunch, sondern ein Bereich, in dem nach wenigen Wochen ein Unterschied spürbar ist. Das stellt Vertrauen wieder her, und ohne Vertrauen läuft kein zweiter Anlauf.
- Danach die geplante Reihenfolge. Ab hier gilt das normale Vorgehen der Projektplanung.
Was wir nicht tun
Wir bewerten die Arbeit des Vorgängers nicht öffentlich. Das bringt niemandem etwas, und in den meisten Fällen liegt die Ursache ohnehin nicht bei einer einzelnen Person, sondern in der Konstruktion des Projekts.
Der wichtigste Satz für den zweiten Anlauf: Streichen ist erlaubt. Anforderungen aus dem ersten Versuch sind keine Verpflichtung – oft ist die Hälfte davon nach ein, zwei Jahren gar nicht mehr aktuell.
Auch das gehört dazu
Manchmal zeigt die Bestandsaufnahme, dass die Edition nicht passt. Dann steht ein Upgrade oder Downgrade an – oder es zeigt sich, dass zu viele Lizenzen gebucht sind. Und wenn die Installation technisch am Ende ist, ist ein Update auf cobra 2026 oder ein Serverumzug der ehrlichere Weg als weiteres Herumdoktern.
Erzählen Sie uns, wo es hängt. Das erste Gespräch ist kostenlos, und wir sagen Ihnen offen, ob wir einen Weg sehen.