Stell dir vor, du hast 50.000 Euro in die Hand genommen, um ein Team auf ein komplexes technologisches Nischenprojekt anzusetzen, das intern nur als The Dark Side Of The Moon bezeichnet wird. Du hast drei Monate geplant, die besten Leute eingekauft und ein schickes Dashboard erstellt. Nach sechs Wochen stellst du fest: Die Schnittstellen passen nicht, die Datenqualität ist unterirdisch und dein Chef fragt, warum bisher nur Powerpoint-Folien existieren. Ich habe dieses Szenario in den letzten zehn Jahren bei großen Mittelständlern und Konzernen immer wieder erlebt. Meistens liegt es daran, dass die Verantwortlichen glauben, man könne unbekanntes Terrain mit den gleichen Methoden verwalten wie das Tagesgeschäft. Sie planen linear, wo Chaos herrscht, und wundern sich dann, wenn das Geld weg ist, bevor das erste echte Ergebnis steht. In meiner Erfahrung ist der größte Kostentreiber nicht die Technik selbst, sondern die Arroganz zu glauben, man hätte alles unter Kontrolle, bevor man überhaupt angefangen hat.
Der Irrglaube an die perfekte Planung von The Dark Side Of The Moon
Einer der häufigsten Fehler, den ich sehe, ist die Erstellung von riesigen Gantt-Charts für Projekte, die eigentlich Forschungscharakter haben. Wenn du versuchst, jeden Schritt für ein Vorhaben auf der Schattenseite der Erkenntnis festzulegen, lügst du dich selbst an. Ein Projektleiter verbringt dann 80 Prozent seiner Zeit damit, einen Plan zu aktualisieren, der sowieso nicht mehr stimmt. Das kostet nicht nur seine Arbeitszeit, sondern lähmt das gesamte Team, weil alle auf Freigaben für Schritte warten, die längst hinfällig sind. Verpassen Sie nicht unseren letzten Artikel zu diesen verwandten Artikel.
Warum Meilensteine oft nur Makulatur sind
In der Praxis führen starre Meilensteine dazu, dass Teams Probleme verheimlichen. Wenn der Bonus davon abhängt, dass "Meilenstein 3" am Freitag grün leuchtet, wird das Team alles tun, damit es grün aussieht – auch wenn der Code dahinter Schrott ist. Ich habe Projekte gesehen, die zwei Jahre lang offiziell "auf Schiene" waren, nur um am Tag der Live-Schaltung komplett in sich zusammenzubrechen. Das Problem ist hier die falsche Anreizstruktur. Du solltest nicht den Abschluss eines Plans belohnen, sondern die frühzeitige Identifikation von Risiken. Wer mir nach zwei Wochen sagt, dass der gewählte Ansatz unmöglich funktioniert, spart mir mehr Geld als derjenige, der das Problem erst nach sechs Monaten zugibt.
Die Falle der überdimensionierten Werkzeuge
Oft wird versucht, mangelnde Erfahrung durch teure Software-Lizenzen zu kompensieren. Man kauft die größte Enterprise-Lösung, weil man denkt, dass das Werkzeug die Strategie ersetzt. Das ist so, als würde man sich einen Profi-Rennwagen kaufen, um das Fahren zu lernen. Am Ende verbringst du Monate damit, die Software zu konfigurieren, anstatt am eigentlichen Problem zu arbeiten. Ich habe erlebt, wie Unternehmen sechsstellige Beträge für Beratungsleistungen ausgegeben haben, nur um ein Tool einzuführen, das am Ende niemand bedienen konnte. Für einen weiteren Ansatz auf dieses Ereignis siehe das aktuelle den Bericht von Manager Magazin.
Ein konkreter Vorher/Nachher-Vergleich aus der Praxis
Schauen wir uns an, wie das in der Realität aussieht. Ein mittelständischer Maschinenbauer wollte seine Produktion digitalisieren. Vorher: Die Geschäftsführung kaufte ein umfassendes ERP-System-Modul für 120.000 Euro. Sie beauftragten eine Agentur, die über acht Monate hinweg alle Prozesse dokumentierte. Das Ergebnis war ein 200-seitiges Lastenheft. Als die Implementierung begann, stellten sie fest, dass die Maschinen in der Werkshalle gar nicht die nötigen Schnittstellen hatten. Das Projekt wurde nach 14 Monaten und einem Verlust von über 250.000 Euro abgebrochen. Nachher: Ein Konkurrent mit ähnlicher Ausgangslage ging anders vor. Er nahm 5.000 Euro und kaufte ein paar günstige Sensoren und einen Standard-Mini-Computer. Ein Techniker und ein Werkstudent bastelten in zwei Wochen einen Prototypen für eine einzige Maschine. Sie lernten sofort, wo die physikalischen Grenzen lagen. Nach einem Monat wussten sie genau, welche Daten sie wirklich brauchten. Sie skalierten erst, als das Prinzip bewiesen war. Die Gesamtkosten bis zum Rollout waren nur halb so hoch wie beim ersten Unternehmen, und das System lief nach sechs Monaten stabil.
Die personelle Fehlbesetzung durch Hierarchie-Denken
In Deutschland neigen wir dazu, Projekte nach Dienstjahren zu besetzen. Der erfahrenste Abteilungsleiter bekommt die Führung, auch wenn er von der Materie keine Ahnung hat. Das ist tödlich. Solche Projekte brauchen keine Verwalter, sondern "Trüffelschweine". Leute, die keine Angst haben, sich die Hände schmutzig zu machen und die unbequeme Fragen stellen. Wenn du jemanden an die Spitze stellst, der nur darauf bedacht ist, seinen Status zu wahren, wird er jedes Risiko im Keim ersticken.
Die Gefahr der Ja-Sager
In meiner Laufbahn habe ich oft gesehen, dass kritische Stimmen aus den Projektteams entfernt wurden, weil sie die "Stimmung vermiesen". Aber genau diese Leute sind deine Lebensversicherung. Wenn ein Entwickler sagt, dass die Architektur nicht skalieren wird, dann hör ihm zu. Es ist billiger, jetzt die Architektur zu ändern, als in einem Jahr das ganze System neu zu bauen. Fachkompetenz muss Hierarchie schlagen, sonst landest du in einer Sackgasse, aus der nur ein teurer Rückzug führt.
Unterschätzung der Daten-Realität
Man nimmt oft an, dass Daten einfach da sind. Man denkt, man müsse sie nur "anzapfen". Die Realität ist oft ein Trümmerhaufen aus Excel-Tabellen, verschiedenen Datumsformaten und Dubletten. Wer diesen Teil des Projekts unterschätzt, hat schon verloren. Ich habe Projekte gesehen, bei denen 90 Prozent des Budgets für die Bereinigung von Daten draufgingen, obwohl dafür nur 10 Prozent eingeplant waren. Das führt zwangsläufig zum Scheitern oder zu massiven Nachforderungen.
- Fehler: Annahme, dass vorhandene Daten sofort nutzbar sind.
- Lösung: Eine einwöchige "Data Audit Phase" ganz zu Beginn, bevor überhaupt eine Zeile Code geschrieben wird.
- Fehler: Manuelle Datenpflege als Dauerlösung planen.
- Lösung: Investition in automatisierte Validierungsprozesse, auch wenn das am Anfang langsamer wirkt.
- Fehler: Datensilos ignorieren und hoffen, dass die IT das schon regelt.
- Lösung: Klare Verantwortlichkeiten für die Datenhoheit in den Fachabteilungen festlegen.
Kommunikation als Alibi-Veranstaltung
Viele denken, Kommunikation bedeutet, einmal im Monat einen Newsletter zu verschicken oder einen Lenkungsausschuss einzuberufen. Das ist keine Kommunikation, das ist Reporting. Echte Kommunikation bedeutet, dass die Leute, die am Projekt arbeiten, ständig mit denen reden, die das Ergebnis später nutzen müssen. Wenn die Endnutzer erst beim Go-Live sehen, was gebaut wurde, ist der Widerstand vorprogrammiert. Ich habe Software-Einführungen scheitern sehen, nicht weil die Software schlecht war, sondern weil die Mitarbeiter in der Logistik sich übergangen fühlten und das System boykottierten.
Feedbackschleifen verkürzen
Statt großer Präsentationen solltest du funktionierende Zwischenstände zeigen. Es ist völlig egal, ob das Design noch hässlich ist. Wichtig ist, ob der Prozess funktioniert. Wenn du alle zwei Wochen echtes Feedback einholst, kannst du den Kurs korrigieren, ohne ein Vermögen zu verbrennen. Warte nicht auf Perfektion. Perfektion ist der Feind des Fortschritts und der beste Freund der Budgetüberschreitung.
Fehlende Ausstiegsstrategien und Sunk Cost Fallacy
Das ist vielleicht der schmerzhafteste Punkt. Unternehmen stecken oft immer mehr Geld in ein sinkendes Schiff, weil sie schon so viel investiert haben. Sie können nicht zugeben, dass die Grundannahme von The Dark Side Of The Moon falsch war. Das nennt man Sunk Cost Fallacy. Ein erfahrener Praktiker weiß, wann er den Stecker ziehen muss. Es ist keine Schande, ein Projekt nach 50.000 Euro abzubrechen, wenn man merkt, dass das Ziel nicht erreichbar ist. Eine Schande ist es, 500.000 Euro zu verbrennen, obwohl man es besser wusste.
Wie man den Absprung schafft
Du brauchst klare Abbruchkriterien, die feststehen, bevor das Projekt startet. Wenn Bedingung X nach Zeit Y nicht erfüllt ist, wird das Projekt beendet oder grundlegend neu bewertet. Ohne diese Leitplanken wird das Projekt zu einem Zombie, der Ressourcen frisst, aber nie echten Wert liefert. Ich habe Teams gesehen, die jahrelang an Totgeburten gearbeitet haben, nur weil niemand den Mut hatte, das Offensichtliche auszusprechen.
Realitätscheck
Erfolg in diesem Bereich hat nichts mit Glück zu tun. Er ist das Ergebnis von brutaler Ehrlichkeit gegenüber den eigenen Kapazitäten und den technischen Gegebenheiten. Wenn du denkst, du kannst ein solches Vorhaben nebenbei erledigen oder mit Beratern lösen, die nur Folien produzieren, wirst du scheitern. Es braucht Fokus, eine extrem hohe Fehlertoleranz und die Bereitschaft, Pläne jeden Tag über den Haufen zu werfen.
Du musst verstehen, dass du am Anfang am wenigsten über das Projekt weißt. Deshalb ist es Wahnsinn, am Anfang die größten Entscheidungen unumstößlich zu treffen. Bleib flexibel. Sei skeptisch gegenüber jedem, der dir eine einfache Lösung für ein komplexes Problem verkauft. Es gibt keine Abkürzung durch den Schlamm – du musst durch, aber du kannst entscheiden, wie schwer dein Gepäck ist. Wer mit leichtem Gepäck und offenen Augen startet, kommt am Ende eher an, als derjenige, der mit einem schweren, unbeweglichen Plan im Graben landet. Es kostet Nerven, es kostet Zeit, und ja, es wird wehtun. Aber wenn du die oben genannten Fehler vermeidest, hast du zumindest eine reelle Chance, dass am Ende etwas Brauchbares dabei herauskommt, das den Aufwand wert war.
