Episode-Beschreibung

„Andere entwickeln komplett neue Fahrzeuge in 48 Monaten. Finde heraus, wie das geht, und führe es bei uns ein."

Dieser Auftrag führte mich zu einer Erkenntnis, die mich selbst überrascht hat: Für ein komplett neues Fahrzeug in 48 Monaten gibt es genau eine mögliche Vorgehensweise. Eine einzige. Wenn das aber so ist, dann kann man sie aufschreiben und immer wieder anwenden.

Daraus entstehen die Learning Standard Routines, das zweite Element des NewPDP.

Nicht der Inhalt definiert das Projekt, sondern die Zeit. Und was stabil und wiederholbar ist, wird nicht jedes Mal neu erfunden, sondern standardisiert, kontinuierlich verbessert und von zugeordneten Experten erledigt.

In drei Schritten zur Perfektion: Templates, standardisierte Prozesse, zugeordnete Experten. Und am Ende die Frage, was das alles mit KI zu tun hat. Die Antwort fällt anders aus als erwartet.

Inhalt der Episode

Zwei Wirkprinzipien stehen hinter allem: Standardisierung ermöglicht Verbesserung, und Fokus schafft Professionalität.

Für einen festen Zeitraum gibt es nur eine sinnvolle Vorgehensweise. Diese wird aufgeschrieben und immer wieder anwenden.

Umkehr der Planungslogik: Nicht der Inhalt definiert das Projekt, sondern die Zeit. Zeit und Geld stehen zuerst fest, der Inhalt wird passend dazu ausgewählt.

Standardvorlagen statt Einzelfallplanung: Mit jedem Durchlauf sinkt die Fehlerwahrscheinlichkeit, steigt die Liefertreue und wächst der realisierbare Inhalt. Der Zeitplan wird nicht mehr verhandelt, sondern angewandt.

Zweigeteiltes Vorgehen: Volatiles wird kurzzyklisch und situationsbezogen entschieden, Stabiles wird standardisiert und kontinuierlich verbessert. Ein hybrides System aus agilen und klassischen Prinzipien.

Ebene 1, Projekt- und ITEM-Templates: ein Katalog von Zeitvorgaben, zum Beispiel 48, 36, 24 und 12 Monate. Ein Template ist ein Gerippe, kein Masterplan. Es enthält, was zum Erreichen der Zeitvorgabe nötig ist, und nichts weiter. Die Feinplanung bleibt beim Drum Beat.

Ebene 2, standardisierte Prozesse: aus den Templates herausgelöst und eigenständig gepflegt. Aufnahmekriterium ist wiederholtes Auftreten bei stabilem Umfeld. Fehlt eines von beidem, gehört der Ablauf ins Drum Beat System.

Abgrenzung zum Agilen: Agil standardisiert den Meta-Prozess und lässt den Fachprozess offen. Im hybriden System standardisieren wir beides. Wiederholbare Fachprozesse jedes Mal neu zu erfinden ist keine Anpassungsfähigkeit, sondern Verschwendung.

Ohne Standard kein KVP. Der Standard ist verbindlich, aber nicht endgültig. Weiterentwickelt wird er von denen, die mit ihm arbeiten.

Ebene 3, zugeordnete Experten: feste Gruppen für einen oder mehrere Standardprozesse, idealerweise in eigenen Organisationseinheiten. Wiederholung erzeugt Professionalität.

Der Abbau von Expertengruppen ist eine Scheineinsparung. Die Stelle verschwindet, die Arbeit nicht. Sie wandert zu Laien, und der Mehraufwand taucht in keinem Budget auf. Ebene 3 dreht das um und macht die Arbeit wieder sichtbar.

Zuordnung und Dokument gehören zusammen: Die Zuordnung der Mitarbeiter erzeugt die Verbesserung, das Prozessdokument sichert sie ab. Keine der beiden Hälften funktioniert allein.

KI-Assistent: Die Standardroutinen liefern die Datenbasis. Der Assistent senkt die Hürde, den passenden Standard zu finden und anzuwenden, und macht Lessons Learned praktikabel.

KI-Agent: dokumentiert, immer gleich ablaufend, einer festen Gruppe zugeordnet. Das sind genau die Bedingungen, unter denen KI einen Ablauf vollständig übernehmen kann.

Die Reihenfolge ist entscheidend: erst der Standard, dann die Automatisierung. Wer es umgekehrt versucht, automatisiert das Chaos.

Für wen ist diese Episode relevant?

Entwicklungs- und Projektleiter.

Führungskräfte, die Effizienz in den Projekten und Abläufen schaffen wollen.

Prozess- und Methodenverantwortliche.

Alle, die KI in der Produktentwicklung einsetzen wollen und sich fragen, wie das geht.

Organisationen, die agile und klassische Prinzipien nicht gegeneinander ausspielen wollen

Weitere Informationen

Die Learning Standard Routines sind das zweite der sieben Elemente des NewPDP. Sie bauen auf dem Drum Beat System auf, zu dem es eine eigene Episode gibt. In den nächsten Wochen folgen Episoden über die weiteren Elemente.

„Warum schlagen die mir das alles zur Entscheidung vor, wenn sie es dann doch nicht schaffen?" und gleichzeitig: „Wenn der Chef nicht weiß, was wichtig ist, dann mache ich eben irgendwas."

Beide Sätze hat Uwe Mierisch gedacht. In derselben Firma, zur selben Zeit, in zwei Rollen. Aus diesem Dilemma ist das Drum Beat System entstanden — das erste Element des NewPDP.

Innovationen entstehen nicht durch Eingebung. Innovationen zu entwickeln ist Handwerk, das man lernen kann und muss. Und deshalb funktionieren viele Methoden aus der Produktion auch in der Entwicklung.

Diese Episode beschreibt das Problem, bevor sie die Lösung beschreibt: das Auftragsdauerfeuer, die Illusion der Priorisierungsliste und warum kein Chef diese Entscheidung allein treffen kann.

Episode-Beschreibung

„Das ist alles viel zu komplex, das versteht keiner. Nimm den Drum Beat raus und lass den Rest weg." — dieser Satz fiel im Hinterhof eines italienischen Restaurants in Untertürkheim. Er ist der Anlass für diese Episode.

Uwe Mierisch gibt den Überblick über den NewPDP, ein Entwicklungsmodell für mechatronische Produkte: vier Arbeitsweisen, drei Voraussetzungen, vier Jahre Arbeit. Warum jedes einzelne Element gebraucht wird, in welcher Reihenfolge es drankommt — und warum nichts davon weggelassen werden kann.

Der Auftrag der Old Economy ist unbequem: heute Rendite liefern und gleichzeitig die Zukunft finanzieren. Mehr entwickeln ohne mehr zu brauchen.

Themen dieser Episode

Das doppelte Problem: Wir sind nicht nur zu langsam — wir fangen auch zu spät an. Langsamkeit lässt sich bekämpfen, verlorene Zeit nicht zurückholen

Der Sandsack der Old Economy: Warum Wettbewerber ohne Profitabilitätsdruck einen strukturellen Vorteil haben — und welche Vorteile dagegen stehen

Der Aufbau des NewPDP: Vier Practices (Arbeitsweisen) in bewusster Reihenfolge, drei Enablers (Voraussetzungen) parallel

Drum Beat System (DBS) — Im Takt zusammenarbeiten: Das fehlende Wort für den Zeitraum zwischen den Quality Gates. Granatapfelbaum-Modell und universeller 4-Takt-Zyklus. Die eine Regel: Ein Drum Beat wird nie gedehnt

Learning Standard Routines (LSR) — Fokus schafft Professionalität: Können entsteht durch Wiederholung. Warum das nur zur Hälfte Taylorismus ist

Hardware Light Development (HLD) — Virtuell vor materiell: Nicht Hardware abschaffen, sondern mit minimalstem Hardwareeinsatz dieselbe Qualität erreichen

Predictive Technology Readiness (PTR) — Reif, wenn es gebraucht wird: Zu spät entscheiden ist teuer, zu früh investieren erzeugt Bestand. Und Bestand verdirbt

Leadership (L) — Klare Richtung, ein Team: Führung heißt mitarbeiten. Wer nur entscheidet, führt nicht

Organisation (O) — Struktur folgt dem System: Die Matrix überlebt keine dritte Achse. Welches Prinzip führt künftig?

Architektur (A) — Modularer Fortschritt: Was die Hardware von der objektorientierten Programmierung noch lernen muss

Warum nichts weggelassen wird: Die sieben Elemente stehen nicht nebeneinander, sie greifen ineinander

Key Takeaways

✓ Zu spät anfangen ist schlimmer als zu langsam sein — vergangene Zeit holt niemand zurück

✓ Der Auftrag lautet: mehr entwickeln ohne mehr zu brauchen. Das geht nur mit grundlegender Transformation

✓ Priorisiere die Themen mit dem höchsten Wertzuwachs jetzt — und die mit dem größten Wertverlust, wenn sie liegen bleiben

✓ Der Drum Beat ist der Schmierstoff für alles andere. Darum kommt er zuerst

✓ Ein Drum Beat wird nie gedehnt. Sonst verhandeln wir wieder Termine statt Inhalte

✓ Man kann mit einem Element anfangen — man muss sogar. Aber mit einem allein kommt man nicht ans Ziel

Für wen ist diese Episode relevant?

Führungskräfte und Manager in der Produktentwicklung mechatronischer Produkte

Alle, die vor einer Transformation ihres Entwicklungssystems stehen

Prozess- und Methodenverantwortliche, die über Quality Gates hinausdenken wollen

Systems Engineers, die um die Rolle der Funktionalität in der Organisation ringen

Unternehmen der Old Economy im Wettbewerb mit Start-ups und geförderten Playern

Weitere Informationen

In den nächsten Wochen nimmt Uwe Mierisch jedes der sieben Elemente einzeln auseinander. Newsletter oder Podcast abonnieren, um die ganze Serie mitzubekommen.

Welches der sieben Elemente ist in Ihrer Organisation das größte Problem? Und welches wäre am schnellsten zu haben? Schreiben Sie es in die Kommentare oder direkt als Nachricht.

Hashtags

#NewPDP #Produktentwicklung #DrumBeat #Transformation #SystemsEngineering #HardwareLightDevelopment #TechnologyReadiness #Leadership #Organisation #Architektur #Mechatronik #Effizienz

Verwandt: [[P11 - NewPDP]] · [[NewPDP - Drum Beat System (DBS)]] · [[NewPDP - Learning Standard Routines (LSR)]] · [[NewPDP - Hardware Light Development (HLD)]] · [[NewPDP - Predictive Technology Readiness (PTR)]] · [[NewPDP - Enabler Führung]] · [[NewPDP - Enabler Organisation]] · [[NewPDP - Enabler Architektur]] · [[Show Notes - Der blinde Fleck]]

Effizienz in der Wissensarbeit ist ein blinder Fleck. Warum können Ingenieure den Wirkungsgrad einer Maschine präzise messen und optimieren, während Manager in der Entwicklung völlig im Dunkeln tappen? In dieser Episode erklärt Uwe Mierisch, wie die beiden Modelle Granatapfelbaum-Modell und Universeller 4-Takt-Zyklus Effizienz und Effektivität in Organisationen messbar und steuerbar machen.

Ein Ingenieur-Ansatz für das Management: Struktur statt Glück. Erfolg, der reproduzierbar ist.

Themen dieser Episode

Wirkungsgrad: Der grundlegende Begriff aus dem Ingenieurwesen und seine Anwendung auf Wissensarbeit

Effizienz vs. Effektivität: Der kritische Unterschied zwischen "die richtigen Dinge tun" und "Dinge richtig tun"

Das Granatapfelbaum-Modell: Wie man die Effektivität in einer Organisation erhöht durch bewusste Priorisierung

Der Universelle 4-Takt-Zyklus (DCVI): Die Methode, um Fehler zu vermeiden und effizienter zu arbeiten

Das Zusammenspiel: Warum beide Modelle zusammen funktionieren und sich gegenseitig verstärken

Ressourcen-Management: Wann und wie man Ressourcen wirklich reduzieren kann

Arbeitskultur & Systeme: Warum Logik allein nicht reicht — es braucht implementierte Systeme und Gewohnheiten

Key Takeaways

✓ Effizienz und Effektivität sind zwei verschiedene Fragen — beides ist notwendig für Erfolg

✓ Das Granatapfelbaum-Modell schafft Transparenz über alle Aktivitäten einer Organisation

✓ Der 4-Takt-Zyklus reduziert systematisch Fehler und unnötige Schleifen

✓ Zusammen schaffen die Modelle Struktur, die Erfolg reproduzierbar macht

✓ Erfolg ist kein Glück — es ist ein System, das implementiert werden kann

Für wen ist diese Episode relevant?

Manager und Führungskräfte in Entwicklung, Innovation und indirekten Bereichen

Produktleiter, die ihre Teams effizienter machen wollen

Organisationen, die zwischen Chaos und Überplanung stecken

Alle, die lernen wollen, wie Engineering-Prinzipien im Management funktionieren

Unternehmer und Geschäftsführer, die ihre Ressourcen optimal nutzen wollen

Weitere Informationen

Dieser Podcast basiert auf einer Serie von Artikeln und tiefer gehenden Analysen zum Thema Wirkungsgrad in der Wissensarbeit. Mehr über die beiden Modelle erfahren Sie in den erweiterten Artikeln zum Granatapfelbaum-Modell und zum Universellen 4-Takt-Zyklus.

Hashtags

#Effizienz #Effektivität #Wirkungsgrad #Wissensarbeit #Management #Produktentwicklung #Leadership #Organisation #SystemsThinking #Engineering #Produktmanagement

Der universelle Viertakt-Zyklus

In dieser Folge stelle ich ein Prinzip vor, das ich seit vielen Jahren in Projekten jeder Größenordnung einsetze: den universellen Viertakt-Zyklus, kurz DCVI. Es beschreibt vier Phasen, die jedes Projekt und jede Aufgabe strukturell tragen, egal ob in der Produktentwicklung, in der Organisation, bei Kostensenkung oder im ganz normalen Alltag.

Die vier Phasen:

Definition: Klarheit schaffen, bevor die eigentliche Arbeit beginnt. Was ist gegeben, was wird gesucht, welche Voraussetzungen müssen erst geschaffen werden, und vor allem: Wie soll das Ergebnis am Ende aussehen und für wen? Diese Phase wird am häufigsten abgekürzt, dabei zahlt sich Sorgfalt hier besonders aus.

Creation: Die Lösung wird Schritt für Schritt entwickelt. Schleifen und mehrere Anläufe sind hier ausdrücklich erlaubt und gehören dazu, ebenso wie enge Teamarbeit statt Alleingänge.

Validierung: Der Beweis, dass die Lösung unter realen Bedingungen tatsächlich funktioniert. Änderungen sind an dieser Stelle nur noch erlaubt, um echte Probleme zu beheben, nicht mehr um zu optimieren.

Umsetzung: Das Ergebnis wird in die Realität geliefert. Eine Lösung zählt erst, wenn sie bei den Menschen ankommt, die sie brauchen, und dort auch wirkt.

Kernaussage: Mit diesem Prinzip wird Erfolg keine Frage von Glück, sondern etwas, das sich gezielt steuern lässt. Das erfordert allerdings Übung und konsequente Anwendung, kein einmaliges Abhaken der vier Phasen.

Nächste Folge: Wie der universelle Viertakt-Zyklus und das Granatapfelbaum-Modell als komplettes System zusammenwirken.

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