Von der Idee zur Serienreife: wie Entwicklungsprojekte in der Praxis aus dem Ruder laufen

Kategorie: Branchen-Guides

An welcher Stelle verliert ein Entwicklungsprojekt die Kontrolle?

Nicht am Anfang. Die Idee ist begeisternd, das Konzept plausibel, das erste Muster funktioniert. Aus dem Ruder läuft ein Entwicklungsprojekt typischerweise zwischen dem ersten Funktionsmuster und der Serienfreigabe, also in der Phase, in der niemand mehr über Funktion diskutiert, sondern über Toleranzen, Lieferanten, Prüfzeugnisse und Werkzeugstände. In dieser Phase kostet jede Woche Verzug ein Vielfaches dessen, was sie in der Konzeptphase gekostet hätte.

Wen betrifft das, und wie sieht der Schaden konkret aus?

Betroffen sind Unternehmen, die Produkte entwickeln, aber kein durchgängiges Projektsystem einsetzen. Der Ablauf wird in Terminlisten, Excel-Tabellen, Konstruktionsplänen und E-Mail-Verläufen geführt. Jede dieser Quellen ist für sich richtig. Keine davon gibt Auskunft über den Gesamtzustand.

Der Schaden entsteht dreifach. Erstens als Zeit: Der Marktstart verschiebt sich, die Konkurrenz ist zuerst da, ein Kundenauftrag bindet sich an einen Wettbewerber. Zweitens als Kosten: Sonderfahrpläne, Expressfertigung, Werkzeugänderungen und wiederholte Prüfläufe. Drittens als gebundene Kapazität: Das Entwicklungsteam bleibt im alten Projekt, während das nächste bereits terminiert ist. Das dritte Element wiegt am schwersten, weil es sich auf jedes Folgeprojekt überträgt.

Die administrative Last verstärkt den Effekt. 55 % der Manager verbringen mindestens 8 Stunden pro Woche mit administrativen Aufgaben, 54 % nennen schlechte Kommunikation und wiederholte Fehler als größtes Problem (Formstack, State of Workflow Automation 2018). Wissensarbeiter verwenden 19 % ihrer Zeit auf Informationssuche und 28 % auf E-Mail (McKinsey Global Institute, The social economy 2012). In einem Entwicklungsprojekt bedeutet das: Ein erheblicher Teil des Projektleiteraufwands fließt in die Rekonstruktion eines Status, der bereits irgendwo existiert.

Was belegen Studien über den typischen Verlauf?

Die Abweichung ist die Regel, nicht die Ausnahme. Flyvbjerg beziffert für Großprojekte: 9 von 10 überschreiten Kosten und Zeit (Flyvbjerg, Oxford Global Projects). Die Standish Group weist für 2020 31 % erfolgreiche, 50 % „challenged" und 19 % gescheiterte Projekte aus; kleine Projekte erreichen rund 90 % Erfolg, große unter 10 % (Standish Group, CHAOS 2020). Für große Technologieprojekte liegt die durchschnittliche Budgetüberschreitung bei 45 %, der realisierte Wert 56 % unter Plan (McKinsey / Universität Oxford 2012).

Der Ursprung liegt früh. Kahneman und Tversky beschrieben 1979 die Planning Fallacy: Dauer und Aufwand werden systematisch unterschätzt, auch bei vorliegender Erfahrung (Kahneman & Tversky 1979). Entscheidend ist, wie lange die Unterschätzung unentdeckt bleibt. Nur 42 % der Unternehmen erkennen veraltende Pläne unmittelbar (techconsult, Project Performance Index). PMI beziffert den Verlust durch schlechte Projektperformance auf 9,9 % jedes investierten Dollars, also 99 Mio. $ je 1 Mrd. $ (PMI, Pulse of the Profession 2018), und für 2020 auf 11,4 % der Investition; Organisationen ohne Projektmanagement als strategische Kompetenz verzeichnen 67 % mehr komplett gescheiterte Projekte (PMI, Pulse of the Profession 2020). In technisch komplexen Projekten liegt der abgeleitete Budgetverlust bei 37 % [interne Ableitung aus PMI/Standish, Beleg ergänzen], die Mehrkosten durch Ressourcenkonflikte bei 49 % [interne Ableitung aus PMI/Standish, Beleg ergänzen].

Wo kippt der Verlauf Idee → Konzept → Muster → Validierung → Serienfreigabe?

Der Ablauf hat fünf Phasen mit jeweils eigenem Kippmuster. Die folgende Übersicht ist ein konstruiertes Szenario für ein Entwicklungsprojekt mit 1,5 Mio. Euro Budget und 80 Wochen Plandauer; die Kostenwirkung zeigt die typische Größenordnung, nicht gemessene Werte.

Die Progression ist der eigentliche Befund. Derselbe inhaltliche Fehler kostet in der Lastenheftphase einen niedrigen vierstelligen Betrag und im Serienanlauf einen sechsstelligen. Späte Sichtbarkeit ist deshalb kein Reporting-Problem, sondern ein Kostentreiber.

Fünf Auslöser tauchen dabei überdurchschnittlich oft auf:

1. Scope Creep ohne Änderungsentscheidung. Eine zusätzliche Schnittstelle, eine weitere Gerätevariante, ein zusätzlicher Betriebsmodus. Jede Einzelentscheidung wirkt klein, weil sie nie gegen Termin und Budget gerechnet wird. Ohne ECR-Prozess mit Aufwandsbewertung summiert sich der Zuwachs unsichtbar.
2. Späte Anforderungen aus Vertrieb oder Zulassung. Ein Kunde verlangt in Woche 40 eine zusätzliche Schutzart, eine Norm wird in einer neuen Fassung verbindlich. Beides trifft eine bereits eingefrorene Konstruktion.
3. Lieferantenqualifizierung als Nachlauf. Erstmusterprüfbericht, Prozessfähigkeitsnachweis und Serienwerkzeug brauchen zusammen oft 16 bis 24 Wochen. Im Plan steht häufig nur „Lieferant beauftragen".
4. Zulassung und Normen als Blackbox. Externe Prüflabore haben Wartezeiten. Ein Durchfall im Erstversuch bedeutet nicht zwei Wochen Nacharbeit, sondern Nacharbeit plus neuer Prüfslot.
5. Übergabe an die Produktion ohne definierten Abnahmeumfang. Arbeitspläne, Prüfanweisungen, Vorrichtungen, Schulung und Ersatzteilkonzept sind Entwicklungsergebnisse. Fehlen sie, entsteht der Rückstand erst im Anlauf, wenn er am teuersten ist.

Warum entsteht die späte Sichtbarkeit strukturell?

Drei Mechanismen wirken zusammen, unabhängig von der Branche.

Erstens fällt der Zeitpunkt der Festlegung nicht mit dem Zeitpunkt der Kostenentstehung zusammen. Über 70 % der Herstellkosten werden in Konzept und Konstruktion festgelegt [Quelle ergänzen], ausgegeben werden sie im Anlauf. Wer nur den Mittelabfluss verfolgt, sieht ein ruhiges Projekt, während die teuren Entscheidungen längst getroffen sind.

Zweitens liegt die Information verteilt. Der Konstruktionsstand steht im CAD/PLM, die Stückliste im ERP, die Lieferzeiten in der Einkaufsmail, der Prüfstatus im Laborbericht, der Termin in der Projektliste. Keine dieser Quellen ist falsch, aber keine kennt die anderen. Eine Änderung an der Stückliste erzeugt deshalb keine automatische Terminwirkung, sondern erst dann eine, wenn ein Mensch beide Quellen nebeneinanderlegt. Genau das passiert in der Regel im Monatsreview, also mit Wochen Verzögerung.

Drittens sind die Entscheidungen, die den Verlauf bestimmen, formal keine Projektentscheidungen. Ein Konstrukteur wählt ein anderes Zukaufteil. Ein Vertriebsmitarbeiter sagt eine Variante zu. Ein Einkäufer verschiebt eine Bestellung, um einen Rahmenvertrag abzuwarten. Jede dieser Handlungen ist im jeweiligen Fachbereich korrekt und wird dort nicht als Terminrisiko protokolliert. Erst ihre Summe verschiebt den Serienstart.

Hinzu kommt der Portfolioeffekt. Entwicklungsteams arbeiten fast nie an einem Projekt. Prüfstände, Zulassungsbudgets und erfahrene Entwickler sind über mehrere Vorhaben geteilt. Verschiebt sich ein Projekt, verschieben sich die anderen mit, ohne dass dies in einem Einzelprojektplan auftaucht. Die TU Berlin stellt in ihrer Benchmarking-Studie zum Multiprojektmanagement fest, dass nur 12 von 100 Unternehmen das richtige Maß bei Projektauswahl und Priorisierung finden (TU Berlin, Benchmarking-Studie Multiprojektmanagement).

Wie halten Sie den Verlauf steuerbar?

Der Hebel liegt nicht in mehr Planungstiefe, sondern in früherer Sichtbarkeit. Sechs Maßnahmen, die ohne neues Vorgehensmodell umsetzbar sind:

1. Anforderungen versionieren und klassifizieren. Jede Anforderung bekommt Status, Quelle und Verbindlichkeitsgrad. Neue Anforderungen nach Konzeptfreigabe laufen ausnahmslos als Änderung mit Aufwands- und Terminbewertung.
2. Gate-Kriterien als Nachweise formulieren. Ein Gate ist passiert, wenn benannte Verifikationen vorliegen, nicht wenn ein Datum erreicht ist. Zwei bis vier harte Kriterien je Gate genügen.
3. Beschaffungs- und Prüfzeiten aus Ist-Daten ableiten. Nutzen Sie die tatsächlichen Wiederbeschaffungszeiten der letzten drei Projekte je Teileklasse und die realen Wartezeiten der genutzten Prüflabore. Das ersetzt Optimismus durch Erfahrungswerte und wirkt direkt gegen die Planning Fallacy.
4. Lieferantenqualifizierung als eigenen Projektstrang führen. Start spätestens mit dem B-Muster, mit eigenen Meilensteinen für Erstmusterprüfbericht und Prozessfreigabe.
5. Normkonformität vorziehen. Vorprüfungen an A- und B-Mustern kosten einen Bruchteil einer gescheiterten Endprüfung und decken die teuren Befunde auf, solange Änderungen noch günstig sind.
6. Produktionsübergabe als Lieferergebnis definieren. Eine feste Liste aus Arbeitsplänen, Prüfanweisungen, Vorrichtungen, Schulung und Ersatzteilkonzept wird ab Validierungsstart mitgeführt und im Gate vor Serienfreigabe geprüft.

Dazu gehört ein Steuerungstakt, der schnell genug ist. Ein monatlicher Statusbericht kann eine Verschiebung, die durch eine 16-Wochen-Lieferzeit entsteht, erst melden, wenn sie unumkehrbar ist. Ein wöchentlicher Abgleich auf wenige zählbare Größen ist wirksamer als ein umfangreicher Monatsbericht: offene Anforderungen, offene Änderungen, belegte Prüfkapazität, qualifizierte Lieferanten.

Praxisbeispiel: Mechatronik-Entwickler, 140 Mitarbeiter, Budget 1,5 Mio. Euro

Ein Hersteller mechatronischer Antriebsmodule entwickelt eine neue Baureihe. Budget 1,5 Mio. Euro, Plandauer 80 Wochen, geplanter Serienstart Woche 80. Geführt wird das Projekt über eine Terminliste und wöchentliche Teamrunden. (Szenario, konstruierte Zahlen.)

Woche 18: Der Vertrieb meldet einen Kundenwunsch für eine zweite Anschlussvariante. Die Entscheidung fällt in der Teamrunde, ohne Aufwandsbewertung. Zusatzaufwand real: 310 Stunden.

Woche 34: Das B-Muster braucht ein Sondergetriebe. Die Bestellung geht raus, die Lieferzeit beträgt 15 Wochen. In der Terminliste stand für den Musteraufbau ein Block von sechs Wochen ohne separaten Beschaffungsvorgang.

Woche 52: Die Sicherheitsprüfung im externen Labor fällt durch, weil eine Kriechstreckenanforderung an der neuen Anschlussvariante verletzt ist. Der nächste freie Prüfslot liegt in Woche 63.

Woche 66: Der Lieferant für das Gehäuse besteht die Prozessfähigkeitsprüfung nicht. Ein Zweitlieferant wird qualifiziert, Dauer 11 Wochen.

Der Serienstart erfolgt in Woche 97 statt 80. Die Abweichung:

344.900 Euro entsprechen 23 % des Budgets. Keiner der vier Auslöser war technisch anspruchsvoll. Jeder war zum Zeitpunkt seines Entstehens bekannt, aber an keiner Stelle als Termin- und Kostenwirkung erfasst. Die Verschiebung um 17 Wochen band zusätzlich vier Entwickler, deren Kapazität im Folgeprojekt bereits verplant war.

Fazit

Entwicklungsprojekte scheitern selten an der Technik. Sie scheitern daran, dass Entscheidungen mit großer Terminwirkung, wie eine zusätzliche Variante, eine Lieferzeit oder ein Prüfslot, nicht als solche erfasst werden und erst in der teuersten Phase sichtbar werden. Wer die Kippstellen jeder Phase kennt und die vier bis fünf zählbaren Größen wöchentlich prüft, verlagert Korrekturen dorthin, wo sie noch vierstellig kosten statt sechsstellig.

Weiterführend: Projektmanagement in der technischen Produktentwicklung: zwischen Engineering und Termindruck · Warum 37 % des Budgets in technisch komplexen Projekten verloren gehen

Mehr zu Projektmanagement für technisch komplexe Projekte: Aligia