Braucht es noch Projekte – oder sind Projekte ein alter Zopf von gestern?
In dieser Episode geht Uwe Mierisch dem großen Dilemma der Mechatronikentwicklung auf den Grund: klassisches Projektmanagement auf der einen Seite, agile Methoden auf der anderen.
Anhand einer typischen – und schmerzhaft vertrauten – Geschichte aus der Fahrzeugentwicklung zeigt er, warum weder der rein klassische noch der rein agile Ansatz für mechatronische Produkte funktioniert, und was stattdessen die Lösung ist.
Das lernst du in dieser Episode:
Warum mechatronische Projekte immer wieder in die gleiche Stressfalle tappen
Was ein mechatronisches Produkt grundlegend von rein mechanischen oder rein digitalen Produkten unterscheidet
Warum klassisches Projektmanagement in der Mechatronik strukturell scheitert
Warum rein agiles Arbeiten ebenfalls keine Lösung ist – und wo es seine Grenzen hat
Welche zwei konkreten Merkmale der Hardwareentwicklung ein rein agiles Vorgehen verhindern
Wie das hybride Modell des New PDP funktioniert und aus welchen vier Ebenen es besteht
Warum die Umsetzung des New PDP eine klare Führungsaufgabe ist
Inhalt der Episode
Das typische Szenario (ca. Min. 0–5) Uwe schildert den klassischen Ablauf eines Fahrzeugprojekts: monatelange Verhandlungen, ein zusammengestauchter Zeitplan, teure Hardware-Prototypen – und dann der Schock, wenn das Fahrzeug nicht fährt, weil die Software nicht fertig ist. Die darauffolgende Heldenphase kurz vor dem Serienanlauf, in der alle zusammenrücken und die Krise mit letzter Kraft abwenden, ist symptomatisch für eine strukturell fehlerhafte Vorgehensweise.
Was ist ein mechatronisches Produkt? (ca. Min. 5–8) Hardware und Software sind untrennbar miteinander verbunden. Erst gemeinsam liefern sie den Kundennutzen. Am Beispiel des modernen LKW – mit Systemen zur Verbrauchsoptimierung, Fahrerassistenz und Flottenmanagement – wird deutlich, warum solche Produkte ohne Software schlicht nicht mehr denkbar sind.
Warum klassisches Projektmanagement nicht ausreicht (ca. Min. 8–11) Das sequenzielle Aneinanderreihen von Hardware- und Softwareentwicklungsphasen führt zu Projektzeitplänen, die wirtschaftlich unrealistisch sind. Die Folge: Pläne werden gestaucht, was kein echtes Projektmanagement mehr ist – und dessen Erfolg von Zufall abhängt.
Warum rein agiles Vorgehen ebenfalls scheitert (ca. Min. 11–14) Zwei grundlegende Merkmale der Hardwareentwicklung verhindern ein rein agiles Arbeiten:
Hardware ist nur eingeschränkt inkrementell entwickelbar – ein halbfertiges Produkt kann nicht an Kunden übergeben werden.
Hardwareentwicklung braucht langfristige Planung – Fertigungseinrichtungen, Werkzeuge, Validierungsumgebungen (Sommer/Winter-Tests, geteilte Ressourcen) müssen weit im Voraus koordiniert werden.
Die Lösung: Der New PDP (ca. Min. 14–17) Das hybride Modell besteht aus vier Ebenen:
Programmmanagement – alle Produktveränderungen werden aufeinander abgestimmt und in einen gemeinsamen Rhythmus gebracht
Projektebene – der essentielle Ablauf vom Start bis zur Kundenauslieferung mit klaren Meilensteinen
Drum Beat – ein kurzzyklischer Rhythmus für Detailplanung, Ergebnisreviews und die Reaktion auf Unvorhergesehenes
Wochensprint-Umsetzung – Teams erledigen Aufgaben, das Management steuert Ressourcen
Der entscheidende Punkt: Führung ist gefragt (ca. Min. 17–18) Der New PDP funktioniert nur, wenn Hardware- und Softwareentwickler gemeinsam und konsequent den gesamten Prozess leben. Das ist eine Umgewöhnung für beide Seiten – und damit eine klare Führungsaufgabe.
Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe
