ToDo Management – Die vierte Ebene des Granatapfel-Baum-Modells

Zusammenfassung

Shopfloor Management ist kein Nice-to-have.

Das lernte ich auf die schmerzhafteste Art. Vor Jahren – es wird mir nicht leicht, das zuzugeben – traf ich eine Entscheidung, von der ich genau wusste, dass sie falsch war. Und ich tat sie trotzdem.

In dieser Episode erzähle ich Ihnen, warum ein ganzes Unternehmen in die Krise läuft, wenn man sein Shopfloor-Team streicht. Und warum ToDo Management – die unterste, konkreteste Ebene des Granatapfel-Baum-Modells – das Fundament ist, auf dem alles andere ruht.

Hier entstehen die Ergebnisse. Hier wird der Wert generiert. Hier, in den Fruchtkernern des Granatapfels.

Kapitel

00:00 – Einstieg Die Geschichte der falschen Entscheidung und ihre Konsequenzen

05:30 – Die Lehre aus dem Fehler Warum Shopfloor Management unersetzlich ist

08:20 – Das Granatapfel-Modell und die ToDo-Ebene Die vierte Ebene und die DCVI-Phasen

12:45 – Die fünf Regeln des ToDo-Managements

Ergebnisorientierung

Organisatorische Verantwortung

Interdisziplinarität

Ergebnisüberprüfung

Methoden-Support

22:10 – Die konkrete Vorgehensweise Wie sieht es in der Praxis aus?

26:30 – Soll der Chef eingebunden sein? Transparenz und Verantwortung

29:15 – Abschluss und Call to Action

Was nehmen wir heute mit?

Shopfloor Management schafft die Struktur, die Ergebnisse überhaupt erst möglich macht. Es ist nicht Bürokratie, es ist Fundament.

Die fünf Regeln sind nicht optional. Ergebnisorientierung, organisatorische Verantwortung, Interdisziplinarität, Ergebnisüberprüfung und echter Methoden-Support – alle fünf müssen gelten.

Dedizierte Ressourcen sind essentiell. Eine Methode verschwindet, wenn man aufhört, in sie zu investieren. Das gilt auch für kleine Unternehmen.

Der Manager muss wissen, wie es läuft. Nicht aus Misstrauen, sondern aus Verantwortung. Transparenz schützt alle.

Jeder ist der Projektmanager seines eigenen Verantwortungsbereichs. Das bedeutet nicht alles selbst zu machen – aber sicherzustellen, dass alles organisiert ist.

Weiterführende Ressourcen

Granatapfel-Baum-Modell: Das Kernmodell für strukturierte Produktentwicklung

Drum Beat: Die dritte Ebene des Modells (vorherige Episode)

DCVI-Phasen: Definition, Creation, Validation, Implementation – der Rhythmus, der auch in ToDo Management gilt

Scrum und Lean Management: Die beiden Quellen, aus denen ToDo Management schöpft

Ihre nächsten Schritte

Haben Sie Fragen oder eigene Erfahrungen mit ToDo Management?

Schreiben Sie mir einen Kommentar hier auf Substack, schicken Sie mir eine Nachricht, oder lassen Sie uns in den Kommentaren chatten.

Nicht verpassen: In der nächsten Episode gehe ich ins operative Detail und zeige Ihnen anhand meiner Datenbank, wie alles konkret funktioniert. Das ist der praktische Teil – die Vorlagen, die Struktur, die Tools.

Abonnieren Sie meinen Podcast oder Newsletter, damit Sie es nicht verpassen.

Falls Ihnen dieser Podcast gefällt: Empfehlen Sie ihn bitte weiter. Das ist für mich das beste Feedback, das es gibt.

Vielen Dank fürs Zuhören. Ich freue mich schon, Sie bei der nächsten Episode wiederzusehen.

Bis dahin: Passen Sie auf sich auf und bleiben Sie innovativ.

Drum Beat – Sachen fertigmachen

Aktivität ist keine Lieferung. Und Berichterstattung ist kein Ergebnis. Wer das nicht versteht, wird ewig Zwischenstände präsentieren – aber nichts fertig bekommen.

Das Shop-Floor-Experiment und sein Scheitern

Uwe hatte einen ungewöhnlichen KPI erfunden: die Aufgabenabarbeitungsgeschwindigkeit. Die Idee war simpel – lieber eine kleinere Aufgabe wählen und abschließen, als an einer großen ewig herumzudoktern. Das Ergebnis? Der KPI lag wie ein Fels auf dem Meeresgrund. Woche für Woche dieselben Punkte, derselbe Status: „in Arbeit." Der Fehler war nicht der KPI – sondern die fehlende Deadline. Eine Lieferung ohne fixiertes Lieferdatum ist keine Lieferung. Es ist nur eine Bestellung.

Der Drum Beat: drei Monate, dann ist Schluss

Der Drum Beat ist die dritte Ebene im Neuen Produktentwicklungsprozess. Wie ein Schlagzeuger, der den gleichmäßigen Takt vorgibt, setzt der Drum Beat einen festen Rhythmus: alle drei Monate werden definierte Ergebnisse geliefert – ohne Ausrede. Drei Monate sind lang genug für etwas Substanzielles und kurz genug, um relevant zu bleiben.

Das Granatapfel-Modell

Der NewPDP hat vier Ebenen – alle im Granatapfel sichtbar: Der Baum steht für die Programmebene, die Frucht für das einzelne Vorhaben (ITEM), die Kammern für die Drum Beats, und die Fruchtkerne für die einzelnen ToDos. Jede Ebene bricht Komplexität auf und macht sie beherrschbar.

Was in den Drum Beat reinkommt – und was bewusst nicht

Deliverables sind keine Aktivitäten, sondern konkrete Ergebnisse. Ausgewählt wird nach zwei Kriterien: Was bringt den größten kurzfristigen Wertzuwachs? Und was verursacht das größte Problem, wenn es jetzt nicht erledigt wird? Wichtiger als die Frage „Was machen wir?" ist: „Was machen wir bewusst nicht?" – denn nur so weiß jeder, worauf er warten kann und worauf nicht.

Planung ist kein Luxus – sondern Pflicht

Die Drum-Beat-Planung findet am Anfang jedes Zyklus statt, mit allen Beteiligten. Am Ende steht ein Commitment: auf die Deliverables, auf das Weggelassene und auf den Liefertermin. Wer nicht mitdenkt, wird zum Problem. Danach gilt: liefern – kein Umplanen, kein „ist mir was dazwischengekommen."

Mehr von Uwe Mierisch: uwemierisch.substack.com · uwemierisch.com

ITEM-Planung

„Der Plan zeigt die Route, nicht die Reise."

🗺️ Worum geht es in dieser Episode?

In dieser Episode tauchen wir eine Ebene tiefer in die Welt der Work-ITEMs ein. Während der Überblick über alle ITEMs Orientierung, Priorisierung und Verständnis von Abhängigkeiten ermöglicht, brauchen wir genau das auch innerhalb der einzelnen ITEMs. Wir schauen uns an, wie ITEMs geplant werden sollten — und warum weder zu viel noch zu wenig Planung zum Ziel führt.

🔑 Kernthemen

Planung — ja oder nein? Ein höchst kontroverses Thema: Manche treiben Planung ins Extrem, andere lehnen sie als unnötige Bürokratie ab. Die Wahrheit liegt — wie so oft — in der Mitte.

Was Helmuth von Moltke uns lehrt Der preußische Generalfeldmarschall und Erfinder der Auftragstaktik liefert die perfekte Denkgrundlage. Sein berühmtes Zitat: „Kein Operationsplan reicht mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus." — Keine Absage an die Planung, sondern ein Plädoyer für ihre richtige Anwendung.

Aufmarsch vs. Auftragstaktik Moltke unterscheidet zwei Phasen: die präzise Vorbereitungsplanung (Aufmarsch) und die flexible Ausführung im Angesicht der Realität (Auftragstaktik). Beides übertragen wir auf modernes Projektmanagement.

Die eigentliche Funktion von Planung Planung ist Vorbereitung, nicht Kontrolle. Sie liefert den theoretisch besten Ansatz und schafft die Voraussetzungen für erfolgreiche Ausführung. Je größer das ITEM, desto mehr Planung ist erforderlich.

Meilensteine statt Aktivitäten Ein Plan beschreibt das Was und das Wann, nicht das Wie. Termine und Ziele bleiben stabil; der Weg bleibt flexibel.

📦 ITEM-Typen & ihre Planungslogik

ITEM-Typ:

Projekte

Klare Fristen & Ziele, Fokus auf Meilensteine statt Aktivitäten

Technologieentwicklung

Größere Volatilität einplanen, kein lückenloses Anschluss-Projekt

Features & Funktionen

Sprint-Planung + DCVI-Meilensteine (Definition, Erstellung, Validierung, Implementierung)

Kundensegmente

Projektcharakter, negatives Ergebnis muss einkalkuliert sein

Problemlösung

Inkrementell starten, Meilensteine planbar (Ursachenanalyse → Maßnahmen → Wirksamkeit)

Prozessentwicklung

Analog zu Projekten, auch ohne formale Struktur mindestens mit Plan

Mitarbeiterentwicklung

Quartalsziele im Fokus, Langfristplan nur bei klar definierter Zielrolle

📌 Die 5 Planungsregeln

Plane, um Erkenntnisse zu gewinnen – der Planungsprozess schafft das vollständige Bild

Schaffe die Voraussetzungen – erst starten, wenn die Grundlagen bereit sind

Halte die Richtung – Plan als Orientierung, nicht als starre Einschränkung

Vertraue den Handelnden – das Wie liegt bei denen, die die Realität sehen

Bewertet die Lage – Fortschritt kontinuierlich mit der Realität abgleichen

💡 Das nimmst du heute mit

Planung ist notwendig — immer.

Sie darf weder zu detailliert noch zu vage sein.

Die richtige Balance ist entscheidend.

Die Art der Planung hängt stark vom ITEM-Typ ab und muss auf den Kontext zugeschnitten sein.

Die Komplexität im Tagesgeschäft beherrschen

Wie man den Überblick behält und das richtige Timing trifft.

In dieser Folge zeige ich dir, wie du die wachsende Komplexität im Tagesgeschäft besser in den Griff bekommst – und gleichzeitig deinen Projekten mehr Raum gibst. Dafür führe ich einen neuen Begriff ein: das ITEM – ein Sammelbegriff für alles, was erledigt werden muss.

Als Orientierungshilfe dient das Granatapfelbaum-Modell: Alles, was auf deinem Schreibtisch liegt, entspricht einem Granatapfel an einem Baum – unterschiedlich groß, unterschiedlich reif.

Die wichtigsten Themen der Episode:

Warum klassisches, agiles und hybrides Projektmanagement allein nicht ausreicht – und warum das wahre Leben sich nicht in Schubladen pressen lässt

Was ein ITEM ist und welche Kategorien darunter fallen: Projekte, Features & Funktionen, Technologieentwicklung, Kundenapplikationen, Probleme, Prozesse und Mitarbeiterentwicklung

Warum ein gemeinsames, großes Backlog für alle ITEMs mehr Transparenz schafft und bessere Priorisierung ermöglicht

Wie ITEM-Management das klassische Multiprojektmanagement erweitert

Warum Daten der Treibstoff für Effizienz sind – und wie eine solide Datenbasis die Voraussetzung für den sinnvollen Einsatz von KI ist

Die zentrale Idee dieser Episode:

Lass uns hybrides Projektmanagement nicht nur auf Projekte beschränken, sondern alles, was erledigt werden muss, in ein gemeinsames großes Backlog schreiben!

Ausblick:

In den nächsten Episoden zeige ich dir, wie das ITEM-Management konkret operativ umgesetzt werden kann – inklusive eines Einblicks in meine eigene Datenbank.

Mach mit!

Welche ITEM-Kategorien fehlen deiner Meinung nach? Schreib es in die Kommentare!

Teile deine Meinung, schick mir eine Nachricht oder chatte mit mir auf Substack.

Wenn dir der Podcast gefällt – empfiehl ihn weiter und abonniere ihn, damit du keine Folge verpasst!

„Wenn die Software den Mehrwert des Produktes definiert"

Worum geht es in dieser Episode?

Die Maschinen lernen denken – und sie werden immer besser darin. Aber was bedeutet das konkret für Produkte, ihre Entwicklung und alle, die daran beteiligt sind?

In dieser Episode beleuchte ich den großen Wandel, den mechatronische Produkte gerade durchlaufen, von der dominanten Mechanik, hin zu Software als zentralem Werttreiber. Und ich zeige, warum das nicht das Ende klassischer Entwicklungsmethoden bedeutet – sondern den Beginn einer neuen, parallelen Welt.

Das lernst du in dieser Episode

Muskeln vs. Gehirn – Wie die Mechanisierung körperlicher Arbeit die Welt verändert hat und warum die Elektronisierung kognitiver Funktionen der nächste große Sprung ist

Warum Mechanik an eine Sättigung stößt – Physikalische Gesetze setzen klare Grenzen; Software hingegen steht noch ganz am Anfang

Das Nervensystem der Maschine – Wie Sensoren, Mikroelektronik und Software Maschinen ein „Gehirn" geben und was das für die Systemarchitektur bedeutet

Software Defined Vehicle & Co. – Was hinter diesem Begriff steckt und warum der Trend weit über die Automobilindustrie hinausgeht

Parallele Entwicklungswelten – Warum es künftig sowohl hybride als auch rein agile Prozesse geben wird – und warum der klassische Ansatz nicht ausstirbt

Industrie 4.0 und Maschinenkommunikation – Was passiert, wenn Maschinen in Millisekunden miteinander reden, Daten teilen und Entscheidungen synchronisieren

Die 4 wichtigsten Erkenntnisse auf einen Blick

Stark physische Produkte → klassischer Entwicklungsprozess bleibt das Mittel der Wahl

Mechatronische Produkte (die Mehrheit) → hybride Vorgehensweise erforderlich

Software Application Layer → wird zunehmend entkoppelt und agil entwickelt

Vernetzte Systeme → Systems Engineering ist unabdingbar

Erwähnte Konzepte & Begriffe

Systems Engineering

Software Defined Vehicle (SDV)

Industrie 4.0 / Over-the-Air-Updates

Hybride vs. agile Entwicklungsprozesse

Zentralisierte Elektronik- und Softwarearchitektur

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.

Warum Softwareentwicklung anders tickt

In dieser Folge wagt sich Uwe Mierisch auf „dünnes Eis“ und blickt zurück auf seine Anfänge mit Fortran und Lochstreifen, um eine Brücke zur modernen, agilen Softwarewelt zu schlagen. Warum scheitern klassische Projektmanagement-Methoden oft an Code, während sie bei Hardware funktionieren?

Die Schwerpunkte dieser Episode:

Die Komplexitäts-Falle: Warum volatile Ziele, die „Blackbox“ moderner Microservices und tückische Heisenbugs (Race Conditions) die Planung erschweren.

Vorteil Software: Wie inkrementelles Arbeiten (MVP), die Abwesenheit von physischen Verschleiß und die universelle Einsetzbarkeit von Entwicklern die Time-to-Market verkürzen.

Projekt vs. Agile: Ein direkter Kriterien-Vergleich, der zeigt, warum Agilität bei Software „wie die Faust aufs Auge“ passt – und wo bei großen Systemen (Scaled Agile) das klassische Management doch wieder eine Rolle spielt.

Die klassische Vorgehensweise im Projektmanagement entstammt den Eigenarten und Erfordernissen bei der Entwicklung von Hardwareprodukten. Darum macht es nach wie vor Sinn, diese Vorgehensweise anzuwenden, wenn die Hardware den Schwerpunkt einer Produktentwicklung bildet. Allerdings bieten agile Projektmanagementelemente die Möglichkeit die Schwächen in der traditionellen Vorgehensweise abzustellen und damit die Entwicklung schneller und effizienter zu machen. Diese Form des hybriden Projektmanagements wird in der Zukunft bei Hardwareentwicklungsprojekten den Standard bilden. Hören sie in dieser Episode warum.

Transformation oder Untergang: Produktentwicklung neu gedacht

Die Welt wartet nicht darauf, dass wir unsere alten Arbeitsweisen bequem optimieren. Während neue Akteure aus Asien den Markt radikal verändern, müssen wir in Europa und Nordamerika unsere Wettbewerbsfähigkeit durch drastische Veränderungen sichern, um nicht "die Entwicklungsländer von morgen" zu werden.

In dieser Episode stelle ich den NewPDP (New Product Development Process) vor – ein Framework, das auf aktuellen Marktstudien und 30 Jahren Praxiserfahrung basiert, um Entwicklungsprozesse auf Geschwindigkeit, Effizienz und Zukunftssicherheit zu trimmen.

Die Kerninhalte dieser Folge:

Der NewPDP: Warum wir keine schrittweise Evolution, sondern einen radikal neuen Prozess brauchen.

4 Säulen der Transformation: *

Zusammenarbeit (Drum Beat): Wie wir durch Synchronisation einen maximalen „Wirkungsgrad“ menschlicher Energie erreichen.

Prozesse (Evolving Standard Procedures): Warum konsequente Standardisierung die Basis für Geschwindigkeit ist.

Technologie (Proaktive Technologiereifung): Der intelligente Umgang mit KI und Elektrifizierung

Werkzeuge (Hardware Light Development): Die gigantischen Effizienzsprünge durch virtuelle Prototypen und das Metaverse.

3 Katalysatoren: Warum neue Organisationsformen, moderne Führung und Software-zentrierte Produktarchitekturen unverzichtbar sind.

Kapitelmarken (Time-Stamps):

00:26 – Die industrielle Vorherrschaft des Westens bröckelt.

01:53 – Die Entstehung des NewPDP aus der Praxis.

04:48 – Säule 1: Zusammenarbeit & der „Drum Beat“.

06:39 – Säule 2: Prozesse & Standardisierung

08:38 – Säule 3: Proaktive Technologiereifung.

11:19 – Säule 4: Hardware Light Development.

13:08 – Die Katalysatoren: Organisation, Führung und Architektur

17:34 – Ausblick und Einladung zum Austausch.

Diskutieren Sie mit!

Der NewPDP ist ein lebendes Framework. Ich lade Sie herzlich ein, Ihre Perspektiven, kritischen Meinungen oder Fragen in den Kommentaren auf Substack zu teilen oder mir eine persönliche Nachricht zu schicken.

Abonnieren Sie diesen Podcast, um keine der kommenden Detail-Folgen zu den einzelnen Transformationsfeldern zu verpassen.