Die Entwicklung steckt fest: 4 typische Ursachen, und was bei welcher wirklich hilft

Wenn ein Team anruft, klingt die Beschreibung fast immer gleich. „Wir kommen nicht weiter." Manchmal folgt eine technische Erklärung, manchmal nicht. Was fast immer folgt, ist ein Lösungsvorschlag: ein Workshop, ein Ideen-Sprint, ein externer Impuls. Der Schritt dazwischen, also die Frage, woran es eigentlich hakt, wird übersprungen.

Das ist kein Vorwurf. Der Reflex ist verständlich. Wenn ein Projekt stockt, will man handeln. Und ein Workshop fühlt sich nach Handlung an.

Aber die Wahl der Methode ist zweitrangig, solange die Diagnose fehlt. Zwei Stunden für eine saubere Einordnung sparen regelmäßig zwei Monate Umweg. Dieser Artikel beschreibt vier typische Ursachen, an denen Entwicklungsprojekte feststecken, und was bei jeder davon tatsächlich hilft.

TL;DR

• Die Diagnose kommt vor der Methode. Eine falsch gewählte Methode verschärft eine Blockade, statt sie zu lösen.
• Ursache 1, unscharfes Problem: Jede Lösung wird aus einem anderen Grund abgelehnt. Ideenfindung macht es schlimmer, Problemzerlegung hilft.
• Ursache 2, ungelöster Widerspruch: Die Varianten unterscheiden sich nur noch im Mischungsverhältnis. Weiter optimieren führt nicht weiter.
• Ursache 3, unbekannte Fehlerursache: Maßnahmen wirken mal und mal nicht. Hier gehört eine Ursachenanalyse vor jede Lösungssuche.
• Ursache 4, kein technisches Problem: Die Lösung liegt auf dem Tisch, es passiert trotzdem nichts. Das ist eine Führungsfrage, keine Methodenfrage.

Warum die Diagnose vor der Methode kommt

Jede der vier Ursachen braucht eine andere Antwort. Das klingt banal, hat aber eine konkrete Konsequenz: Eine falsch gewählte Methode kann eine Blockade verschärfen, nicht lösen.

Wer auf ein unscharf formuliertes Problem einen Ideen-Workshop legt, produziert mehr Varianten, mehr Meinungen und mehr Verwirrung. Das Team hat danach nicht weniger Optionen, sondern mehr, und noch keine gemeinsame Vorstellung davon, was eigentlich gelöst werden soll. Das kostet Zeit und Vertrauen. Warum klassische Formate genau daran scheitern, beschreibt der Beitrag Vom Post-it-Friedhof zur Lösungslandkarte.

Die vier Ursachen, die in der Praxis am häufigsten auftreten, sind: ein unscharfes Problem, ein Widerspruch, den alle für unauflösbar halten, eine unbekannte Fehlerursache, und die unbequemste von allen, eine Blockade, die gar nicht technischer Natur ist.

Einen methodischen Überbau zu der Frage, wie man ein technisches Problem überhaupt strukturiert angeht, bietet der Beitrag Technische Probleme systematisch lösen. Die vier Ursachen hier sind eine Verfeinerung dieser Grundhaltung: Diagnose zuerst, Methode danach.

Ursache 1: Das Problem ist unscharf

Das Erkennungsmerkmal ist zuverlässig: Jede vorgeschlagene Lösung wird von jemandem zerredet, und jedes Mal aus einem anderen Grund. Konstruktion optimiert das Gewicht, Fertigung denkt an Toleranzen, Vertrieb meint die Lieferzeit. Drei Beteiligte lösen drei verschiedene Probleme, ohne es zu merken.

In diesem Zustand ist Ideenfindung das Falscheste, was man tun kann. Mehr Ideen bei unklarer Zielbeschreibung erzeugen mehr Reibung, nicht weniger.

Was hilft, ist eine saubere Problemzerlegung. Welche Funktion muss wirklich erfüllt werden? Was ist das beobachtete Symptom, und was ist die eigentliche Anforderung dahinter? Diese Klärung braucht keinen Kreativitätsraum, sondern einen strukturierten Gesprächsrahmen, in dem Konstruktion, Fertigung und Vertrieb dieselbe Frage beantworten.

Das Muster dahinter wiederholt sich in nahezu jeder Branche: Drei Abteilungen benutzen dasselbe Wort für drei verschiedene Anforderungen. Der eine meint Steifigkeit, der andere Verarbeitbarkeit, der dritte Zulassungsfähigkeit. Solange das nicht auf dem Tisch liegt, diskutiert das Team über Lösungen für Probleme, die nicht dasselbe Problem sind. Eine Stunde Problemdefinition legt das regelmäßig offen.

Der Innovation Impulse Day bei Truinorva ist genau für solche Situationen gedacht: nicht um Ideen zu sammeln, sondern um das Problem gemeinsam scharf zu stellen.

Ursache 2: Ein Widerspruch, den alle für ein Naturgesetz halten

Das Symptom ist präzise: Die diskutierten Varianten unterscheiden sich nur noch im Mischungsverhältnis, und irgendwann sagt jemand den Satz „mehr geht physikalisch nicht".

An diesem Punkt lohnt sich eine ehrliche Prüfung. Steht wirklich ein physikalisches Gesetz im Weg, oder ist es eine ungeprüfte Annahme, die sich durch Wiederholung zur Gewissheit verfestigt hat? Das ist kein rhetorischer Trick. In vielen Projekten sind es Konstruktionsgrenzen, Lieferantenstandards oder historische Designentscheidungen, die als Naturgesetz behandelt werden, obwohl sie es nicht sind.

Was hier vorliegt, ist in TRIZ-Begriffen ein technischer Widerspruch: Zwei erwünschte Eigenschaften stehen so zueinander, dass die Verbesserung der einen die andere verschlechtert. Ein physikalischer Widerspruch geht noch einen Schritt weiter. Ein und dasselbe Merkmal müsste gleichzeitig zwei entgegengesetzte Zustände annehmen, etwa steif und flexibel. Beide Formen sind lösbar, aber nicht durch Optimierung im bisherigen Rahmen, sondern durch einen grundlegend anderen Ansatz.

Wer tiefer einsteigen will, wie TRIZ solche Widersprüche systematisch auflöst, findet dazu mehr im Beitrag Was ist die TRIZ-Methode. Für die Einordnung hier reicht die Erkenntnis: Wenn das Team im Kreis optimiert, ist das ein Zeichen, dass der Widerspruch noch nicht benannt wurde.

Zielkonflikte in der Produktentwicklung, die sich nur noch im Mischungsverhältnis unterscheiden, folgen fast immer diesem Muster. Der verlinkte Artikel zeigt, wie sich solche Konflikte einordnen und strukturiert angehen lassen.

Ursache 3: Die Ursache ist schlicht unbekannt

Ein Fehler tritt auf. Maßnahmen wirken mal und mal nicht. Das Team probiert, beobachtet, probiert wieder. Es entsteht kein verlässliches Muster.

Das ist ein Fall für eine Ursachenanalyse.

Wer hier kreativ wird, produziert Zufallstreffer. Vielleicht funktioniert eine Maßnahme, vielleicht nicht. Ohne zu verstehen, warum ein Problem auftritt, kann man nicht sicher entscheiden, was es löst. Das ist der entscheidende Unterschied zu Ursache 2: Dort ist das Problem bekannt, nur der Lösungsweg blockiert. Hier ist das Problem selbst noch nicht verstanden.

Was hilft, ist eine strukturierte Root-Cause-Analyse, bevor überhaupt über Lösungen nachgedacht wird. Die Ursache-Wirkungs-Ketten-Analyse aus dem TRIZ-Umfeld, kurz CECA (Cause-Effect-Chain-Analysis), bildet alle Ursachen als Netz statt als Liste ab. Sie macht sichtbar, wo die eigentliche Quelle des Problems liegt, und unterscheidet Symptome von Ursachen zuverlässiger als eine einfache Fünf-Warum-Analyse. Erst wenn das geklärt ist, macht es Sinn, über Abhilfemaßnahmen zu sprechen.

Ein häufiger Fehler in dieser Situation: Das Team interpretiert das Ausbleiben einer Wirkung als Beweis, dass die Maßnahme falsch war. Oft liegt es daran, dass die Maßnahme zwar richtig war, aber an der falschen Stelle im Ursachennetz angesetzt hat.

Ursache 4: Es ist gar kein technisches Problem

Das ist die unbequemste Ursache. Sie verdient trotzdem eine klare Benennung, auch wenn das bedeutet, dass ein Workshop hier nicht die Antwort ist.

Das Erkennungsmerkmal: Die Lösung liegt seit Wochen auf dem Tisch. Es passiert trotzdem nichts. Die Diskussionen kreisen nicht mehr um Technik, sondern um Zuständigkeit, Budget und Entscheidungskompetenz.

In dieser Situation hilft keine Methode. Was hilft, ist eine Entscheidung: Wer ist zuständig? Wer gibt das Budget frei? Wer trifft die Weichenstellung? Das ist eine Führungsaufgabe, keine Ingenieuraufgabe. Einen Workshop darüber zu legen wäre nicht nur wirkungslos, es würde das eigentliche Problem weiter verschleiern.

Ich beobachte dieses Muster regelmäßig: Teams, die methodisch sehr kompetent sind, aber in Projekten feststecken, weil niemand eine Entscheidung trifft. Die Methode wird dann zum Ersatz für Führung. Das ist keine Kritik an den Beteiligten, sondern ein strukturelles Problem, das nur auf Führungsebene gelöst werden kann.

Diagnose auf einen Blick

Was tun, wenn mehrere Ursachen zusammenkommen?

In der Praxis überlagern sich Ursachen häufig. Ein unscharfes Problem und eine vermiedene Entscheidung treten oft gemeinsam auf. Ein unbekannter Fehler und ein echter Widerspruch können gleichzeitig blockieren.

Für diesen Fall gibt es eine nützliche Reihenfolge. Zuerst prüfen, ob es überhaupt ein technisches Problem ist (Ursache 4). Dann klären, ob das Problem scharf genug formuliert ist (Ursache 1). Dann prüfen, ob die Ursache bekannt ist (Ursache 3). Erst zuletzt fragen, ob ein echter Widerspruch vorliegt (Ursache 2).

Diese Reihenfolge folgt einer einfachen Logik: Spätere Schritte bauen auf früheren auf. Wer einen Widerspruch analysiert, ohne das Problem scharf gestellt zu haben, analysiert möglicherweise das falsche Problem. Das Ziel ist keine perfekte Diagnose, sondern die richtige erste Weiche.

Häufig gestellte Fragen

Woran erkenne ich, ob mein Problem unscharf formuliert ist?
Am zuverlässigsten daran, dass Vorschläge aus unterschiedlichen Gründen abgelehnt werden. Ein guter Test: Bitten Sie drei Beteiligte, das Problem unabhängig voneinander in zwei Sätzen aufzuschreiben, ohne eine Lösung zu nennen. Wenn drei verschiedene Beschreibungen herauskommen, ist die Ursache gefunden.

Was ist der Unterschied zwischen Ursachenanalyse und Widerspruchsanalyse?
Die Ursachenanalyse klärt, warum ein Problem auftritt. Die Widerspruchsanalyse klärt, warum sich ein bekanntes Problem nicht lösen lässt, ohne etwas anderes zu verschlechtern.

Hilft ein Kreativitätsworkshop, wenn die Entwicklung feststeckt?
Nur bei einer der vier Ursachen, und auch dort erst nach der Problemklärung. Bei unbekannter Fehlerursache und bei organisatorischen Blockaden richtet er eher Schaden an, weil er Aktivität erzeugt, wo Klärung nötig wäre.

Wie lange dauert eine saubere Diagnose?
Für eine erste belastbare Einordnung genügen meist wenige Stunden mit den richtigen Beteiligten. Entscheidend ist nicht die Dauer, sondern dass Konstruktion, Fertigung und Entscheidungsträger dieselbe Frage beantworten.

Fazit

Zwei Stunden saubere Diagnose sparen zwei Monate Umweg. Das ist eine Beobachtung aus vielen Entwicklungsprojekten.

Der Punkt ist nicht, welche Methode besser oder schlechter ist. Der Punkt ist, dass jede Methode eine Annahme darüber trifft, was das Problem ist. Wer diese Annahme nicht prüft, riskiert, das Richtige am falschen Problem zu tun.

Wenn Sie gerade vor einer Blockade stehen und sich in einer der vier Ursachen wiedererkennen, ist der sinnvolle nächste Schritt nicht der nächste Workshop, sondern eine ehrliche Einordnung. Genau dafür ist der Innovation Impulse Day gedacht: ein Tag, an dem Problem und Zielbild geschärft werden, bevor über Lösungen gesprochen wird.

Und wenn Sie sich unsicher sind, welche Ursache bei Ihnen vorliegt, ist das selbst schon eine Antwort. Dann lohnt sich das Gespräch, bevor irgendetwas gebucht wird.

Quellen

• VDI 4521 Blatt 1: Erfinderisches Problemlösen mit TRIZ — Grundlagen und Begriffe. vdi.de
• VDI 4521 Blatt 2: Erfinderisches Problemlösen mit TRIZ — Zielbeschreibung, Problemdefinition und Lösungspriorisierung. vdi.de
• Altschuller, G. S. (1984): Erfinden. Wege zur Lösung technischer Probleme. Verlag Technik, Berlin.
• Gadd, K. (2011): TRIZ for Engineers. Enabling Inventive Problem Solving. John Wiley & Sons.