I have witnessed two major turning points in product development, and we are right in the middle of the second one now.

Subscribe now

I started my career at the drawing board. With pencil and ink on tracing paper, watching older engineers do something I couldn’t yet understand. On the tracing paper appeared three side views, an isometric projection, a few cross-sections, all a single sheet could hold. Where I saw lines I had to piece together one by one, they saw a finished part. They could turn it over in their minds, tilt it, cut it open in a place that wasn’t even drawn, and still know exactly what would be there.

What impressed me even more happened one afternoon when a colleague placed his pencil at the junction with a rib, tapped the paper twice, and said, “It tears there.” No calculation. No proof. He had simply seen it. People called that experience, but it was really a very specific skill, built over years at that exact board, through that exact way of working.

Then the computer replaced the drawing board, and both of those skills, the eye for shape and the eye for stress, were no longer needed. Cross-sections could now be generated inside a 3D model in seconds, and the part could be turned and looked at from any side right there on the screen, instead of being pieced together in your head. Calculation software showed exactly where it would break. What once took a trained eye now took a few clicks. Because they were no longer practiced, those old skills faded away over time, the way a muscle that is no longer used slowly loses its strength. They are nice things to still have, but by now you can get along perfectly well without them.

Something else took its place instead. The new tools did not just do the old work faster, they made things possible that the drawing board never could have handled, and products picked up more features than before, first mechanical, then electrical, then electronic, then networked. Every new feature began interacting with all the others, and a different kind of challenge emerged: understanding what a change would trigger in the whole system, not just in the part itself. Today’s experienced engineer looks at a change request and says, “That conflicts with the heavy-duty version,” with the same certainty my old colleague once tapped his pencil on the tracing paper. No analysis. No proof. He has seen it.

Now the second turning point is underway. Artificial intelligence and virtual development are already reshaping the way an engineer works and thinks, much like the computer once did. Not too far in the future, engineers will no longer look at a 3D model on a flat screen. They will step inside a virtual development environment and interact with the virtual product the same way they interact with the physical one today.

That much I can already picture. What happens after that, I cannot say, any more than I could have predicted today’s world twenty years ago. But I can accompany the way there, with the experience of the past and a vision for what comes next.

One thing is already clear: this time, too, there will be a massive efficiency gain. Somewhere down the road, an engineer will look at something none of us can even picture yet, and just know. It is likely that what makes an experienced engineer today will fade away too, the way a muscle that is no longer used slowly loses its strength. But we will have to develop other skills in its place, because it will be demanded of us.

Bitte jetzt nicht böse auf mich sein, aber genau diese Auffassung hat uns dahin gebracht wo wir heute sind.

Innovationen zu entwickeln ist in erster Linie Handwerk, das man lernen kann und muss!

Es ist eben nicht die überirdische Eingebung oder die Genialität des Individuums.

In dieser Hinsicht unterscheidet sich die Entwicklung von Innovationen viel weniger von der Produktion von Produkten als allgemein angenommen wird.

Und darum sind viele Methoden und Werkzeuge aus der Produktion geeignet auch hier Probleme in den Griff zu bekommen.

Ich will aber nicht gleich auf die Methoden und Werkzeuge eingehen, dafür gibt es eigenen Artikel.

Subscribe now

Ich will erst das Problem beschreiben, das mich dazu gebracht hat, das Drum Beat System zu konzipieren.

Es waren zwei Sätze

Der erste Satz geht so:

Der zweite Satz geht so:

Beide Sätze habe ich gedacht.

Gleichzeitig, in verschiedenen Rollen, in derselben Firma. Einmal als Chef und einmal als Mitarbeiter. Denn auch als Mittelmanager hat man einen Chef, und ist damit auch Mitarbeiter.

Und beide Male hatte ich das Gefühl, im Recht zu sein.

Diese beiden Sätze sind der Ausdruck eines Dilemmas:

Sich verändernde Kundenanforderungen und ein intensiver werdender Wettbewerb erfordern immer mehr Entwicklungen. In kürzerer Zeit, mit den gleichen Ressourcen.

Daraus resultiert:

Das Auftragsdauerfeuer

So habe ich es damals genannt. Ein Maschinengewehr mit einem Magazin, das nie leer wurde. Jede Patrone ein neuer Auftrag.

Jeder, der eine Idee hatte, seiner Meinung nach eine gute, ging damit zum Chef und erklärte ihm, warum sie sofort umgesetzt werden muss.

Am besten hat man einen positiven Business Case dabei. Je größer die Einsparung, je größer das Erlöspotential, desto wahrscheinlicher kommt der Umsetzungsauftrag zurück.

Und dann waren da noch die Ideen der Chefs selbst.

Nicht nur die vom großen Chef. Auch die mittleren und die kleinen Chefs haben Kreativität.

Das Ergebnis war ein Auftragsdauerfeuer, jeden Tag, jedes Meeting kamen neue Aufträge.

Das hat mich fürchterlich aufgeregt. Und mit den Jahren wurde es schlimmer, nicht besser.

Irgendwann kam dann der Ruf nach Priorisierung, weil es einfach nicht alles zu schaffen war.

Dieser Auftrag an den Chef kam zuverlässig und immer wieder und wurde lautstark von der gesamten Belegschaft vorgetragen, die kleinen und mittleren Chefs inclusive.

Und mit ihm kamen die Prio-listen.

Ich sage es hart, weil ich es hart meine: Das ist eine unverschämte Bitte an den Chef.

“Ich schaffe das nicht. Also entscheide du, was wir weglassen. Und trage die alleinige Verantwortung für die Konsequenzen.”

Das Ergebnis war jedes Mal dasselbe: schlechte Stimmung und Misstrauen.

Und die beiden Sätze vom Anfang.

Gerade weil ich gleichzeitig Chef und Mitarbeiter war und beides erlebt und gefühlt habe, kann ich mit voller Überzeugung sagen:

Die Ursache liegt woanders.

Es fehlt ein funktionierendes Steuerungsmodell

Es sind, wie so oft, fehlende Transparenz, fehlende Struktur und ungenutzte Fähigkeiten.

Ohne Transparenz, ohne Struktur und ohne hinreichende Fähigkeiten ist es unmöglich, Wichtiges von Unwichtigem zu unterscheiden.

Wer nicht sieht, was auf der Platte liegt, kann nicht entscheiden, was herunter soll.

Wenn es aber dann ans Weglassen geht, dann ist es keine Verwaltungsaufgabe. Weglassen heißt, Risiken einzugehen.

Risikomanagement ist eine Disziplin, die Struktur in der Vorgehensweise erfordert, sonst sind Risiken nicht quantifizierbar.

Und genau da kommen die Fähigkeiten ins Spiel.

Es braucht ausgeprägte Fähigkeiten, um Risiken überhaupt zu erkennen, um Minderungsmaßnahmen zu definieren und um die Probleme, die unweigerlich trotzdem eintreten, in den Griff zu bekommen.

Und hier rede ich nicht von den Fähigkeiten des Einzelnen.

Ich rede von den Fähigkeiten der Organisation.

Denn hier ergibt 1 plus 1 mehr als 2. Die Fähigkeiten einer Organisation sind um ein Vielfaches größer als die Summe der Fähigkeiten ihrer Individuen.

Deshalb kann der Chef das nicht allein entscheiden. Nicht, weil er zu dumm wäre, sondern weil das Wissen gar nicht bei ihm liegt.

Dann gibt es noch ein weiteres Problem:

Ein Plan ist noch keine Lieferung

Bis hierher ging es ausschließlich um den Plan.

• Was ist wichtig,

• was lassen wir weg,

• welches Risiko gehen wir bewusst ein.

Das ist die Frage nach der Effektivität. Die richtigen Dinge tun.

Nur hat noch kein Plan jemals ein Produkt entwickelt.

Planung ist nicht die Lieferung und Berichterstattung ist nicht das Ergebnis.

Denn nichts frisst so viel Kapazität wie Nacharbeit.

Ein Fehler, der zu spät auffällt, erzwingt eine Schleife.

Und eine Schleife kostet zweimal: einmal die eigene Doppelarbeit und einmal die Doppelarbeit der Kollegen, die mit dem falschen Ergebnis gearbeitet haben.

Wer mühsam Themen weglässt und die gewonnene Kapazität anschließend in Schleifen verbrennt, hat nichts gewonnen.

Also brauchen wir eine zweite Sicherheit.

Das ist die Frage nach der Effizienz. Die Dinge richtig tun.

Und die Hebel sind dieselben wie vorher.

Es braucht Struktur, damit die Voraussetzungen für die Arbeit geschaffen sind, bevor sie beginnt. Fehlende Voraussetzungen sind eine Ursache für verzögerte Lieferung und für fehlerhafte Ergebnisse.

Es braucht Transparenz, wer was von wem braucht und zu welchem Zeitpunkt. Ist das nicht klar, dann entstehen Wartezeiten oder es müssen unsichere Annahmen getroffen werden, die dann wiederum zu fehlerhaften Ergebnissen führen können.

Und es braucht die Fähigkeiten der Organisation, notwendige Kompetenzen zu entwickeln und dort einzusetzen, wo sie gebraucht werden. Statt sie hinterher mühsam zu suchen, wenn die Arbeit schon läuft.

Das Drum Beat System ist das Steuerungsmodell

Das Drum Beat System setzt an genau diesen drei Punkten an.

Transparenz

Fangen wir mit der Transparenz an, weil sie das wichtigste und das am meisten missverstandene Wort in dieser Diskussion ist.

Transparenz klingt nach einer Verwaltungsaufgabe.

• Zusammentragen,

• aufschreiben,

• sichtbar machen.

Für das Was stimmt das auch. Was alles auf der Platte liegt, lässt sich zusammentragen. Das ist der einfache Teil, und genau bis dahin kommen die üblichen Listen.

Und hier liegt häufig eine Ursache für das Problem:

Dieses Warum und dieses Wie liegen nirgendwo herum. Sie existieren noch gar nicht.

Man kann nicht transparent machen, was vorher niemand erarbeitet hat.

Transparenz setzt Inhalt voraus, und dieser Inhalt erfordert Arbeit. Er entsteht nicht dadurch, dass jemand eine Vorlage ausfüllt.

Struktur

Eine KI hat mir eine Definition von Struktur vorgeschlagen, die ich super treffend finde:

Es ist das Gerüst, das immer passt, egal worum es geht.

Sie entsteht aus Erfahrung und Kompetenz.

Wir müssen nicht immer alles neu erfinden, wir müssen nicht jeden Fehler machen, den man machen kann.

Wir suchen funktionierende Muster und wenden sie immer wieder an.

Das Drum Beat System ist keine unerprobte Neuigkeit, sondern es basiert auf jahrzehntelang angewandten, erfolgreichen Prinzipien.

Das Spannende daran ist, dass ich nicht nur die Entwicklung als Inspiration verwende. Ich schaue intensiv in die Produktion.

Ein Fachbereich, in dem Strukturen seit mehr als hundert Jahren etabliert sind und kontinuierlich verbessert werden.

Es startete am 7. Oktober 1913 mit Henry Ford und seinem legendären Fließband. Es fand seine Fortsetzung im Toyota Produktionssystem.

Dabei lohnt ein genauerer Blick auf Ford. Er hat das Fließband nämlich gar nicht erfunden. Das Prinzip kannte er aus den Schlachthöfen von Chicago.

Was Ford erfunden hat, war die Austaktung. Und die entstand nicht am ersten Tag. Es dauerte rund vierzehn Monate mit Stoppuhr und Korrektur, bis aus 12,5 Stunden pro Fahrzeug 93 Minuten wurden.

Warum sollen wir nicht da lernen, wo es langjährige Erfahrungswerte gibt?

Fähigkeiten

Ein Produkt zu entwickeln erfordert eine große Zahl an Kompetenzen. Konstruktion, Berechnung, Versuch, Beschaffung, Fertigungsplanung, Zulassung. Die Liste wird länger, nicht kürzer.

Die eigentliche Frage ist aber nicht, diese Fähigkeiten zu besitzen.

Es ist, sie zum richtigen Zeitpunkt am richtigen Ort zu haben.

Auf dieses Problem höre ich zwei Antworten. Beide greifen zu kurz.

Die erste Antwort heißt Generalisten.

Aus der agilen Welt kommt der Ruf: Spezialisten sind Schnee von gestern, wir brauchen Leute, die alles können.

Was zu Goethes Zeiten ein realistischer Anspruch war, ist heute eine Utopie. Das Wissen in jeder einzelnen Disziplin ist dafür viel zu tief geworden.

Und die Antwort verschiebt das Problem nur. Aus “Ich habe den Spezialisten nicht zum richtigen Zeitpunkt” wird “Es gibt niemanden der es kann”.

Die zweite Antwort heißt künstliche Intelligenz. Die Fähigkeiten bringt künftig die KI an den Tisch, also müssen wir uns darum nicht mehr kümmern.

Diese Antwort halte ich nicht für falsch. Ich halte sie für verfrüht.

Ich glaube, dass wir eines Tages über eine KI verfügen werden, die viel davon leistet. Ich glaube aber auch, dass sie es genau so tun wird, wie wir es die ganze Zeit schon hätten tun sollen.

Also brauchen wir nicht zu warten.

Nicht die Fähigkeiten sind der Engpass. Ihre Verschaltung ist es.

Die meisten Organisationen haben fast alles, was sie brauchen. Sie bringen es nur nicht zum richtigen Zeitpunkt zusammen.

Und jetzt kommt der Punkt, an dem die meisten Steuerungsversuche scheitern.

Diese Verschaltung lässt sich nicht von oben anordnen.

Wer wann was von wem braucht, wissen nur diejenigen, die die Arbeit machen.

Der Chef kann also nicht zuteilen. Er kann nur dafür sorgen, dass die Zuteilung stattfindet.

Genau das leistet das Drum Beat System.

Nicht die Anzahl der Fähigkeiten ist entscheidend, sondern ihr Zusammenwirken.

Damit sind die drei Ursachen benannt, die dafür sorgen, dass wir uns permanent überfordert fühlen. Und in den meisten Fällen auch wirklich überfordert sind.

Bleibt noch die Frage, wie das Drum Beat System diese Ursachen operativ im Tagesgeschäft abstellt.

Zwei Modelle, ein System

Die operative Ausgestaltung übernehmen im Drum Beat System zwei Modelle.

Das Granatapfelbaum-Modell erzeugt die Effektivität, mit ihm steuern wir den Wertfluss und stellen sicher, dass am Wichtigen gearbeitet und das Unwichtige weggelassen wird.

Der Universelle 4 Takt Zyklus erzeugt die Effizienz. Er sorgt dafür, dass Fehler und Entwicklungsschleifen vermieden werden.

Zu beiden Modellen gibt es schon Artikel, die tiefer ins Detail gehen, als ich es hier in diesem Artikel tun kann.

Also lesen oder hören sie sich bitte diese Episoden und Artikel an.

Share Uwe Mierisch

Was nehmen wir heute mit?

• Das Auftragsdauerfeuer ist kein böser Wille und kein Führungsversagen. Es ist die Folge eines fehlenden Steuerungsmodells.

• Priorisierungslisten lösen das nicht. Sie schieben die Verantwortung dorthin, wo das nötige Wissen gar nicht liegt.

• Transparenz ist keine Verwaltungsaufgabe. Man kann nichts sichtbar machen, was vorher niemand erarbeitet hat.

• Struktur ist das, was bleibt, wenn der Inhalt wechselt. Sie entsteht nicht durch Einführung, sondern durch Wiederholung und Korrektur.

• Nicht die Fähigkeiten sind der Engpass, sondern ihre Verschaltung. Der Chef kann sie nicht zuteilen. Er kann nur dafür sorgen, dass die Zuteilung stattfindet.

• Das Drum Beat System ist keine Instanz und kein Verteiler. Es ist ein Rahmen.

Jetzt noch eDas Auftragsdauerfeuer habe ich in verschiedenen Situationen erlebt, in verschiedenen Rollen, zu unterschiedlichen Zeiten. Mich interessiert, wie das anderswo aussieht.

Schreiben Sie mir gern einen Kommentar, wie bei Ihnen entschieden wird, was liegen bleibt. Ich lese jeden einzelnen und antworte darauf.

Leave a comment

Und wenn Sie die weiteren Elemente des NewPDP mitverfolgen möchten, abonnieren Sie den Newsletter.

Subscribe now

Wenn ihnen die Episode gefallen hat, dann teilen sie sie doch bitte mit anderen.

Share

Und wenn ihnen mein Newsletter gefällt, dann empfehlen Sie ihn doch bitte weiter.

Share Uwe Mierisch

It is the first of the seven elements of the NewPDP: the Drum Beat System.

This is the point where I usually lose part of the room. Innovation isn’t produced, people say. Innovation comes from the inspiration of clever people.

Please don’t be angry with me, but that very belief is what got us where we are today.

Developing innovation is first of all a craft.

One that can be learned and has to be learned.

In that respect it differs far less from manufacturing products than is generally assumed, which is why so many tools from production fit our problems.

I won’t go straight to the tools, there are separate articles for those.

Subscribe now

First I want to explain the problem that led me to design the Drum Beat System.

It Was Two Sentences

The first sentence goes like this:

The second sentence goes like this:

I have thought both sentences.

At the same time, in different roles, in the same company.

Once as the boss and once as the employee. Because as a middle manager I also had a boss, which made me an employee too.

And both times I felt I was in the right.

These two sentences are the expression of a dilemma.

Changing customer requirements and intensifying competition demand more and more development. In less time, with the same resources.

What follows from that is this:

Continuous Fire

That is what I called it back then. A machine gun with a magazine that never ran empty. Every round an assignment.

Anyone who had an idea, a good one in their own view, took it to the boss and explained why it had to be implemented immediately.

Ideally with a positive business case attached. The bigger the savings, the bigger the revenue potential, the more likely the go ahead came back.

And then there were the bosses’ own ideas. Not just the big boss. The middle and the small bosses have creativity too.

Every day, in every meeting, new assignments arrived.

It made me furious. And over the years it got worse, not better.

At some point came the call for prioritization, because there was simply no way to do it all.

It came reliably and repeatedly, voiced loudly by the workforce. And with it came the priority lists.

I’ll say it harshly, because I mean it harshly. That is an outrageous thing to ask of a boss.

The message is:

“I can’t manage this. So you decide what we drop. And you carry sole responsibility for the consequences.”

The result was the same every time. Bad mood and mistrust.

And the two sentences from the beginning.

Precisely because I was boss and employee at the same time, I can say this with full conviction:

The cause lies elsewhere.

A Working Control Model Is Missing

As so often, it comes down to missing transparency, missing structure and unused capabilities.

Without transparency, without structure and without sufficient capabilities it is impossible to tell the important from the unimportant.

If you cannot see what is on the plate, you cannot decide what comes off it.

But when it comes to leaving things out, that is not an administrative task. Leaving things out means taking risks.

Risk management is a discipline that requires structure in the approach. Without it, risks cannot be quantified.

And that is exactly where capabilities come in.

It takes strong capabilities to recognize risks at all, to define mitigations, and to handle the problems that occur anyway.

And here I am not talking about the capabilities of the individual.

I am talking about the capabilities of the organization.

Because here one plus one is more than two. The capabilities of an organization are many times greater than the sum of the capabilities of its individuals.

That is why the boss cannot decide this on his own. Not because he is too stupid, but because the knowledge does not sit with him.

A Plan Is Not a Delivery

Up to this point it has been about the plan alone.

• What matters,

• what we drop,

• which risk we take deliberately.

That is the question of effectiveness. Doing the right things.

Only, no plan has ever developed a product.

Planning is not delivery, and reporting is not results.

Because nothing eats capacity like rework.

A mistake that surfaces late forces a loop, and a loop costs twice.

Once as your own duplicated work, and once as the duplicated work of the colleagues who built on the wrong result.

Dropping topics is hard work. Burning the freed capacity in loops makes it pointless.

So we need a second safeguard.

That is the question of efficiency. Doing things right.

And the levers are the same as before.

It takes structure, so that the preconditions for the work exist before the work starts. Missing preconditions are a reliable source of late delivery and faulty results.

It takes transparency about who needs what from whom, and by when. Where that is unclear, people wait, or they make uncertain assumptions that produce faulty results.

And it takes the capabilities of the organization, built and deployed where they are needed. Instead of struggling to find them once the work is already running.

The Drum Beat System Is the Control Model

The Drum Beat System attacks exactly these three points.

Transparency

Let’s start with transparency, because it is the most important and the most misunderstood word in this discussion.

Transparency sounds like an administrative task.

Collect it, write it down, make it visible.

For the What, that is true. Everything on the plate can be collected, and that is exactly as far as the usual lists get.

And here lies a frequent cause of the problem.

That Why and that How are not lying around anywhere. They do not exist yet.

You cannot make anything transparent that nobody has worked out beforehand.

Transparency presupposes content, and that content takes work. It does not appear because somebody fills in a template.

Structure

An AI suggested a definition of structure to me that I find spot on:

It is the skeleton that always fits, whatever the subject.

Structure grows out of experience and competence.

We do not have to reinvent everything every time, and we do not have to make every mistake that can be made.

We look for patterns that work, and we apply them again and again.

So the Drum Beat System is not an untested novelty.

It rests on principles that have been applied successfully for decades, and I do not take them from development alone.

I look hard at manufacturing, a field where structures have been established and continuously improved for more than a hundred years.

It began on 7 October 1913 with Henry Ford and his legendary moving assembly line, and found its continuation in the Toyota Production System.

Ford is worth a closer look, because there is a misunderstanding sitting there. He did not invent the assembly line. He knew the principle from the Chicago meatpacking plants.

What Ford did invent was line balancing. And it was not there on day one. It took roughly fourteen months of stopwatch work and correction before 12.5 hours per vehicle became 93 minutes.

So why should we not learn where decades of experience are already on the table?

Capabilities

Developing a product requires a large number of competences. Design, analysis, testing, sourcing, manufacturing engineering, homologation. The list gets longer, not shorter.

But the real problem is not possessing them. It is having them at the right time in the right place.

I hear two answers to this. Both fall short.

The first answer is generalists. From the agile world comes the call: specialists are yesterday’s model, we need people who can do everything.

What was a realistic ambition in the age of the Renaissance man is a utopia today. The knowledge inside every discipline has become too deep for it.

And the answer only shifts the problem. “I don’t have the specialist at the right time” turns into “I don’t have anyone at all who could do that”.

The second answer is artificial intelligence. AI will bring the capabilities to the table, so we no longer need to worry about them.

I don’t consider that answer wrong. I consider it premature.

One day we will have an AI that delivers much of this, and I believe it will do it in exactly the way we should have been doing it all along. So there is no reason to wait.

Capabilities are not the bottleneck. Their wiring is.

Most organizations have almost everything they need. They simply fail to bring it together at the right moment.

And now comes the point where most attempts at steering fall apart.

This wiring cannot be ordered from above.

Who needs what from whom, and when, is known only to the people doing the work.

So the boss cannot do the allocating. He can only make sure that the allocation happens.

That is precisely what the Drum Beat System does.

What matters is not the number of capabilities, but the way they work together.

That have been the three causes that leave us permanently overloaded.

Which raises the question of how the Drum Beat System removes them in day to day operations.

Two Models, One System

The operational shape is carried by two models.

The Pomegranate Tree Model produces effectiveness. With it we steer the flow of value and make sure that the important gets worked on and the unimportant gets left out.

The Universal 4-Stroke Cycle produces efficiency. It makes sure that errors and development loops are avoided.

I have written and recorded about both models in more depth than I can go into here. You find all those articles in my publication, and they are worth the detour.

Share Uwe Mierisch

What Do We Take Away Today?

• Continuous fire is not ill will and not a failure of leadership. It is the consequence of a missing control model.

• Priority lists do not solve it. They push responsibility to the place where the necessary knowledge does not sit.

• Transparency is not an administrative task. You cannot make anything visible that nobody has worked out beforehand.

• Structure is what remains when the content changes. It does not come from being introduced, it comes from repetition and correction.

• Capabilities are not the bottleneck, their wiring is. The boss cannot allocate them. He can only make sure the allocation happens.

• The Drum Beat System is not an authority and not a distributor. It is a way of organizing work.

One request before I close.

I have lived continuous fire in more than one setup. It never looked exactly the same twice. What interests me is how it looks elsewhere.

So leave me a comment on how it works where you are. I read every one and I answer.

Leave a comment

And if you want to follow the remaining elements of the NewPDP, subscribe to the newsletter.

Subscribe now

If you like this article, please share it with others who might enjoy it too.

Share

And if you like my newsletter please recommend and share with others as well.

Share Uwe Mierisch

Thanks for reading. Take care and stay innovative.

Ich sitze im Hinterhof eines italienischen Restaurants in Stuttgart Untertürkheim und esse Spaghetti aglio e olio. Mit Knoblauch. Der Termin danach ist zum Glück telefonisch.

Mein Bekannter blättert währenddessen in den Unterlagen zum NewPDP.
Dann sagt er:

„Das ist alles viel zu komplex, das versteht keiner. Nimm den Drum Beat raus und lass den Rest weg.”

Diesen Vorwurf höre ich immer wieder. Zu kompliziert, zu viel, zu umfangreich.

Aber, ist eine einfache Transformation überhaupt möglich, wenn man ein ganzes Business System auf den Kopf stellen muss?

Ich glaube nicht. Was sein muss, das muss sein.

In einer Sache hat er allerdings recht.

Der Drum Beat gehört tatsächlich als Erstes angepackt, weil er die Basis für alles andere legt. Genau deshalb habe ich ihn ausdetailliert und operativ anwendbar gemacht, seit ich den NewPDP im Januar in meinem ersten Podcast hier vorgestellt habe. Und genau deshalb werde ich auch weiterhin intensiv auf ihn eingehen.

Nur ist mir dabei der Blick auf das Ganze in den Hintergrund geraten.

Vier Jahre Arbeit stecken in diesem Modell. Und ich habe bisher fast nur über eines seiner sieben Elemente geschrieben.

Vielleicht liegt der Vorwurf also gar nicht am Umfang. Vielleicht liegt er daran, dass ich nie erklärt habe, warum jedes einzelne Element gebraucht wird und in welcher Reihenfolge es drankommt.

Genau das mache ich heute. Und in den nächsten Wochen.

Abonnieren Sie den Newsletter, damit Sie die ganze Geschichte mitbekommen.

Subscribe now

Aber zuerst: Was ist eigentlich unser Problem?

Wir sind nicht nur zu langsam, wir fangen auch zu spät an!

Auf jeder Bühne der deutschen Industrie steht gerade jemand und sagt: Wir sind zu langsam, wir sollten so schnell arbeiten wie die Chinesen.

Aber unsere Langsamkeit ist nicht das einzige Problem. Es ist viel, viel schlimmer: Wir fangen deutlich zu spät an!

Nicht, weil wir es nicht wissen würden, sondern weil wir uns nicht entscheiden können oder wollen.

Langsamkeit kann man bekämpfen und das werden wir hier auch tun. Aber vergangene Zeit kann man nicht zurückholen.

Und wer glaubt, wir holten die Verspätungen noch auf, dem sage ich: Träum weiter. Die Konkurrenz ist nicht nur clever, sie ist auch verdammt schnell.

Ich gehe deshalb beiden Fragen nach.

• Warum tun wir uns mit dem Anfangen so schwer?

• Und wie werden wir schneller?

Mehr entwickeln ohne mehr zu brauchen

Als wenn das nicht schon schwierig genug wäre, muss ich noch eine unangenehme Überraschung auf den Tisch legen:

Wir tragen einen gewaltigen Sandsack auf den Schultern, den viele unserer Konkurrenten nicht schleppen müssen.

Denn viele Wettbewerber sind Start-ups oder Regierungsunterstützte Organisationen. Sie werfen alles Geld und alle Ressourcen auf ein einziges Zukunftsthema.

Profitabilität? Hat morgen noch Zeit.

Ihre Geldgeber warten geduldig, in der Hoffnung, dass der Gewinn dann irgendwann später umso gewaltiger ausfällt.

Ich entstamme der Old Economy.

Da wollen die Investoren heute schon Profit sehen und zwar nicht zu knapp.

Die Aufgabe ist klar: Liefert heute ordentliche Rendite und finanziert gleichzeitig die Zukunft!

Wie die Überschrift sagt: Mehr entwickeln ohne mehr zu brauchen.

Eine Mission Impossible?

Ich glaube nicht, denn die Old Economy hat auch ein paar Vorteile, die wir nutzen können.

Aber eins ist für mich zweifelsfrei klar: Dafür ist eine grundlegende Transformation erforderlich!

Genug mit der Analyse.

Schauen wir uns den NewPDP an, denn er ist als Antwort darauf konzipiert.

Der Aufbau: vier Arbeitsweisen, drei Voraussetzungen

Ihre Reihenfolge ist so gewählt, dass zuerst das angepackt wird, was Grundlage für alles Weitere schafft.

Damit wende ich schon ein Prinzip an, auf das ich zurückkommen werde:

Priorisiere die Themen, die jetzt den höchsten Wertzuwachs bringen und diejenigen, die den größten Wertverlust produzieren, wenn sie nicht jetzt gleich erledigt werden.

Neugierig?

Dann steigen wir kurz in die wesentlichen Merkmale ein.

Wer ungeduldig ist, schreibt mich einfach an, dann gehen wir direkt zum Schwerpunkt Ihrer Wahl.

Die vier Arbeitsweisen

1. Drum Beat System (DBS)

„Wir arbeiten gerade im QGx.”

Diesen Satz habe ich immer wieder gehört.

Er ist sprachlicher Unsinn. In einem Gate kann man nicht arbeiten. Ein Gate ist ein Kontrollpunkt.

Trotzdem sagen ihn alle. Weil unser Prozess nur die Kontrollpunkte benennt und nicht die Zeiträume dazwischen. Es gibt kein Wort für den Zeitraum, in dem tatsächlich gearbeitet wird.

Genau diese Lücke füllt das Drum Beat. System.

• Das Granatapfelbaum-Modell schafft Effektivität durch Ziel Priorisierung und Gleichschritt.

• Der universelle 4-Takt-Zyklus schafft Effizienz durch Fehlervermeidung und strukturierte Arbeitsvorbereitung.

Beide sind Bestandteil des Drum Beat Systems.

Und eine einzige Regel trägt das Ganze:

Ein Drum Beat wird nie gedehnt.

Sobald der Takt verlängert wird sind wir wieder dort, wo wir hergekommen sind. Dann verhandeln wir wieder Termine statt Inhalte.

Das Drum Beat System ist der Schmierstoff für alles andere. Wenn es funktioniert, läuft die ganze Maschine leichter.

Darum fangen wir damit an.

2. Learning Standard Routines (LSR)

Wahrgenommene Komplexität und Volatilität lassen eine Erkenntnis in Vergessenheit geraten:

Nicht jede Tätigkeit ist komplex und nicht das ganze Umfeld ist volatil. Repetitive Tätigkeiten in stabilem Umfeld gibt es, und es wird sie immer geben.

Für sie gilt:

• Identifizieren,

• Vorgehensweise definieren,

• dauerhaft dieselben Leute darauf ansetzen.

• Und diese Leute ihr Vorgehen selbst kontinuierlich verbessern lassen.

Jetzt kommt der Einwand, und er kommt zuverlässig: Das ist doch Taylorismus.

Zur Hälfte ja. Von Taylor bleibt die feste Zuordnung. Was wegfällt, ist die Trennung von Ausführen und Verbessern.

Ich halte das für einen der Vorteile der Old Economy.

Eigentlich wissen wir, wie das geht. Da, wo es sinnvoll ist, müssen wir es wieder kompromisslos tun.

Und ein Aspekt kommt dazu: Standardisierte Prozesse lassen sich einfacher automatisieren und digitalisieren, als unstrukturierte. Das potenziert die Effizienzsteigerung.

Darum kommen die Lernenden Standardroutinen als zweites an die Reihe.

3. Hardware Light Development (HLD)

Digitalisierung ist in aller Munde. Jeder redet über KI, über Virtualisierung, über digitale Zwillinge.

Zu Recht.

Arbeit an echter Hardware ist langwierig und teuer.

Kein Zweifel.

Die Herausforderung steckt in diesem kleinen Nachsatz: was geht.

Auch wenn mir dabei sicher nicht alle zustimmen werden: Solange das Produkt eine Hardware ist, bleibt ein Rest Hardwarearbeit unverzichtbar.

Die entscheidende Veränderung ist nicht auf Hardware komplett zu verzichten.

Sondern mit minimalstem Hardwareeinsatz die gleiche Qualität und Funktionalität zu entwickeln, nur viel schneller und billiger.

Jetzt fragen Sie sich, wie das gehen soll?

Genau das werden wir herausfinden.

4. Predictive Technology Readiness (PTR)

Ich höre häufig: Wir müssen schneller neue Technologien in den Markt bringen.

Meine Beobachtung ist, dass wir uns allzu häufig erst dann für eine Technologieentwicklung entscheiden, wenn wir die Technologie dringend brauchen.

Das ist zu spät!

Es gibt allerdings auch den umgekehrten Fehler. Zu zeitig zu viel in innovative Technologien zu investieren.

Eine Technologie, die fertig im Regal liegt, bevor irgendjemand sie braucht, ist Bestand. Und Bestand verdirbt.

Das Wissen wandert mit den Leuten ab, der Stand veraltet.

Die Herausforderung liegt also nicht nur in der Geschwindigkeit, sondern im richtigen Maß.

Wie managen wir die Entwicklung einer Technologie so, dass sie genau dann reif ist, wenn wir sie brauchen?

Genau damit befasst sich diese Arbeitsweise.

Die drei Voraussetzungen

Leadership (L)

Zum Thema Führung gibt es unzählige Modelle und Meinungen.

Mich interessiert nur eine Frage:

Was muss Führung leisten, damit eine Produktentwicklung schnell und mit minimalem Ressourceneinsatz hervorragende Ergebnisse erzielt?

Eine Antwort vorweg:

• Was entscheidet das Team selbst und wie wird es befähigt, dieser Verantwortung gerecht zu werden?

• Welche Arbeitsaufträge nimmt der Chef vom Team entgegen und wie zuverlässig erledigt er sie?

“Ein Team” ist keine Floskel, es ist eine Einstellung, eine Unternehmenskultur.

Wie im Teamsport gibt es unterschiedliche Spieler mit unterschiedlichen Rollen und die Art des Zusammenspiels muss klar verstanden und trainiert werden.

Und auch da gibt es Standardsituationen.

Und wenn wir das Thema schon mal auf dem Tisch haben, schauen wir uns natürlich auch die Selbstführung an.

Organisation (O)

Solange ich mich erinnern kann, erlebe ich die Debatte, ob Funktionalorganisation oder Divisionalorganisation die bessere Form ist. Das Pendel wechselt regelmäßig die Richtung, am Ende steht fast immer eine Matrixorganisation.

Jetzt kommt das agile Unternehmen in Mode, und gleichzeitig beansprucht das Systems Engineering Einfluss auf die Organisationsform der Entwicklung.

Damit ist das eigentliche Problem benannt.

Die Matrix hat heute zwei Achsen: Kompetenz, also wer es kann und Prozess, also wie es läuft.

Das Systems Engineering bringt eine dritte ins Spiel, nämlich die Produktfunktionalität.

Nur überlebt eine Matrix keine dritte Achse. Drei Zugehörigkeiten, drei Zielsysteme, drei Leute, die über dieselbe Person verfügen.

Abgebildet werden müssen trotzdem alle drei. Aber es kann nur eine Organisation geben, und in ihr ist immer eine Achse führend. Das ist heute schon so, entweder führt die funktionale oder die divisionale.

Darauf brauchen wir eine Antwort, denn ohne geeignete Organisationsform ist schnelles und effizientes Arbeiten nicht möglich.

Architektur (A)

Es ist der Traum jedes Entwicklers, ein vollkommen neues Produkt entwickeln zu dürfen.

Ich hatte diese Chance sogar mehrfach.

Und jedes Mal hat sich die Organisation hinterher geschworen, so etwas nie wieder zu machen.

Unendlich teuer, unendlich langwierig.

Und kaum ist man fertig, ist das Produkt veraltet und die nächsten Wünsche liegen auf dem Tisch.

In der Konsequenz habe ich mich intensiv damit beschäftigt, wie man Hardwareprodukte so modular gestaltet, dass Verbesserungen und neue Funktionalitäten inkrementell entwickelt werden können.

Wer aus der Softwarewelt kommt, erkennt darin das Inkrement.

Dort war es lange genauso. Zu Zeiten des Spaghetticodes musste bei jeder Änderung fast alles neu gemacht werden.

Erst die objektorientierte Programmierung und die Architekturprinzipien danach haben das Inkrement möglich gemacht. Das ist Jahrzehnte her.

In der Hardware steht uns diese Entwicklung noch bevor. Modulare Architekturen gibt es auch bei uns seit über zwanzig Jahren.

Genau darum geht es in diesem Element. Es soll die Lücken füllen, die einer inkrementellen Produktentwicklung in der Mechatronik im Weg stehen.

Wie eine solche Architektur konkret aussieht, definiert der NewPDP nicht. Das wäre zu speziell für ein generelles Framework.

Er definiert, welche Eigenschaften und Prozesse die Architektur aufweisen muss.

Warum ich nichts weglasse

Zurück zum Hinterhof in Untertürkheim. Nimm den Drum Beat raus und lass den Rest weg.

Hier ist meine Antwort.

Die sieben Elemente stehen nicht nebeneinander, sie greifen ineinander. Jedes schafft Voraussetzungen für die anderen, und jedes profitiert von den anderen.

Das ist die Natur eines Systems.

Nehmen Sie sich zwei beliebige davon heraus und fragen Sie sich, was das eine ohne das andere wert ist.

Und der NewPDP ist in dieser Ausprägung schon eine Vereinfachung.

Er konzentriert sich ausschließlich auf die Systemelemente, die bei der Entwicklung mechatronischer Produkte heute den größten Veränderungsbedarf aufweisen.

Man kann mit einem Element anfangen. Man muss sogar. Aber man kommt mit einem allein nicht zum Ziel.

Wenn ich in einiger Zeit wieder einen Überblicksartikel schreibe, ist die Geschichte hoffentlich etwas anders.

Wir werden Probleme gelöst haben, über die wir dann nicht mehr reden müssen, und dafür wird es neue Herausforderungen geben.

Ich schreibe diese Serie nicht, um recht zu haben. Ich schreibe sie, weil ich diese Transformation mit Leuten zusammen mache, die mittendrin stecken.

Wenn Sie Lust haben, machen Sie mit.

Und jetzt bin ich neugierig.

Welches der sieben Elemente ist in Ihrer Organisation das größte Problem? Und welches wäre am schnellsten zu haben?

Schreiben Sie mir das gerne in die Kommentare oder direkt als Nachricht.

Leave a comment

Und wenn Sie vor dieser Transformation stehen und nicht allein anfangen wollen, schreiben Sie mir das auch.

In den nächsten Wochen nehme ich jedes Element einzeln auseinander. Wer die ganze Geschichte mitbekommen will, abonniert am besten den Newsletter oder den Podcast.

Subscribe now

Und wenn Ihnen der Artikel gefallen hat, teilen Sie ihn. Empfehlen Sie den Newsletter weiter, damit auch andere etwas davon haben.

Share

Share Uwe Mierisch

There it goes again.

I am sitting in the back courtyard of an Italian restaurant in Stuttgart Untertürkheim, eating spaghetti aglio e olio. With garlic. Luckily my next meeting is on the phone.

My lunch companion is going through the NewPDP material. Then he says:

“This is far too complex, nobody will get it. Take out the Drum Beat and drop the rest.”

I hear this over and over. Too complicated, too much, too big.

But is a simple transformation even possible when you have to turn an entire business system upside down?

I don’t think so. What must be, must be.

On one point, though, he is right.

The Drum Beat really is the piece to tackle first, because it lays the foundation for everything else.

That is exactly why I have detailed it out and made it operationally usable ever since I introduced the NewPDP here in January, in an article. And it is exactly why I will keep going deeper on it.

Along the way, though, I lost sight of the whole.

Four years of work went into this model. And so far I have written almost exclusively about one of its seven elements.

So maybe the complaint isn’t about the size at all.

Maybe it is about the fact that I never explained why each single element is needed and in what order it comes.

That is what I am doing today. And in the weeks ahead.

Please, subscribe to the newsletter so you get the whole story.

Subscribe now

But first: what exactly is our problem?

We aren’t just too slow, we are also too late!

On every stage in German industry someone is currently saying: “We are too slow, we should work as fast as the Chinese.”

But our slowness isn’t the only problem. It is much, much worse: we start far too late!

Not because we don’t know better, but because we can’t or won’t decide.

Slowness can be fought, and we will do exactly that here. But time that has passed cannot be brought back.

And to anyone who believes we will still catch up, I say: keep dreaming. The competition isn’t just clever, it is also damn fast.

So I will pursue both questions.

• Why do we find it so hard to start?

• And how do we get faster at the same time?

Develop more without needing more

As if that weren’t difficult enough, I have to put one more unpleasant surprise on the table:

We are carrying a huge sandbag on our shoulders that many of our competitors don’t have to haul around.

Because many of our competitors are start-ups or goverment supported. They throw all their money and all their resources at a single topic of the future.

Profitability? That can wait until tomorrow.

Their investors wait patiently, hoping the profit will be all the more enormous somewhere down the line.

I come from the Old Economy.

There the investors want to see profit today, and not a small one either.

The mandate is clear: deliver a solid return today and finance the future at the same time!

As the headline says: develop more without needing more.

Mission impossible?

I don’t think so, because the Old Economy has a few advantages of its own that we can use.

But one thing is beyond doubt for me: it takes a fundamental transformation.

Enough analysis.

Let’s look at the NewPDP, because it is designed as the answer to all of this.

The structure: four practices, three enablers

Their order is chosen so that we first tackle what lays the groundwork for everything else.

In doing so I am already applying a principle I will come back to:

Prioritise the topics that create the highest gain in value right now. And those that produce the greatest loss in value if they are not dealt with immediately.

Here there is no order. Leadership, organisation and architecture can and should be worked on at the same time.

Curious?

Then let’s take a short look at the essential features of each.

And if you are impatient, just write to me and we will go straight to the topic of your choice.

The four practices

1. Drum Beat System (DBS)

“We are currently working in QGx.”

I have heard this sentence over and over.

It is linguistic nonsense. You cannot work inside a gate. A gate is a checkpoint.

People say it anyway. Because our process only names the checkpoints and not the stretches in between.

There is no word for the period in which the work actually happens.

That is exactly the gap the Drum Beat System fills.

• The pomegranate tree model creates effectiveness through goal prioritisation and keeping everyone in sync.

• The universal four-stroke cycle creates efficiency through error avoidance and structured preparation of the work.

Both are part of the Drum Beat System.

And a single rule carries the whole thing:

A Drum Beat is never stretched.

The moment the beat gets extended, we are back where we came from. Then we are negotiating dates again instead of content.

The Drum Beat System is the lubricant for everything else. When it works, the whole machine runs more easily.

That is why we start here.

2. Learning Standard Routines (LSR)

Perceived complexity and volatility have pushed one insight out of view:

Not every activity is complex, and not the whole environment is volatile. Repetitive activities in a stable environment exist, and they always will.

For those, the rule is:

• Identify them,

• define the way of working,

• put the same people on them permanently.

• And let those people improve their own way of working continuously.

Now comes the objection, and it comes reliably: isn’t that Taylorism?

Half of it, yes. What stays from Taylor is the fixed assignment. What goes is the separation of doing and improving.

I consider this one of the advantages of the Old Economy.

We actually know how to do this. Where it makes sense, we have to do it without compromise again.

And one more aspect: standardised processes are easier to automate and digitise than unstructured ones. That multiplies the efficiency gain.

That is why Learning Standard Routines come second.

3. Hardware Light Development (HLD)

Digitalisation is on everybody’s lips. Everyone talks about AI, about virtualisation, about digital twins.

And rightly so.

Working on real hardware is slow and expensive.

No doubt about it.

The challenge sits in that small qualifier: whatever we can.

Even if not everyone will agree with me here: as long as the product is a piece of hardware, a remainder of hardware work stays indispensable.

The decisive change is not to do away with hardware entirely.

It is to develop the same quality and the same functionality with the smallest possible amount of hardware, only far faster and far cheaper.

Now you are asking yourself how that is supposed to work?

That is exactly what we are going to find out.

4. Predictive Technology Readiness (PTR)

I often hear: we have to bring new technologies to market faster.

My observation is that all too often we only decide to develop a new technology once we urgently need it.

That is too late!

But there is also the opposite mistake.

Investing too much in innovative technology too early.

A technology that sits finished on the shelf before anyone needs it is inventory. And inventory ages.

The knowledge walks out of the door with the people, and what is left falls behind.

So the challenge is not only speed, it is the right measure.

How do we manage the development of a technology so that it is ready exactly when we need it?

That is precisely what this practice deals with.

The three enablers

Leadership (L)

There are countless models and opinions on leadership.

Only one question interests me:

What does leadership have to deliver so that product development achieves outstanding results quickly and with minimal resources?

One answer up front:

• What does the team decide for itself, and how is it enabled to live up to that responsibility?

• Which tasks does the boss take on from the team, and how reliably does he deliver them?

“One team” is not a platitude. It is an attitude, a company culture.

As in team sport, there are different players with different roles, and the way they play together has to be clearly understood and practised.

And there, too, you have set pieces.

And while we have the subject on the table, we will of course also look at leading yourself.

Organisation (O)

For as long as I can remember I have watched the debate over whether a functional or a divisional organisation is the better form. The pendulum keeps changing direction, and in the end we almost always land at a matrix.

Now the agile enterprise is coming into fashion, and at the same time systems engineering is laying claim to the organisational form of development.

That names the actual problem.

Today the matrix has two dimensions: competence, meaning who can do it. And process, meaning how it runs. Systems engineering brings a third into play, namely product functionality.

Only a matrix does not survive a third dimension. Three memberships, three sets of goals, three people with a claim on the same person.

All three still have to be represented. But there can only be one organisation, and inside it one dimension always leads. That is already the case today, either the functional or the divisional one leads.

We need an answer to that, because without a suitable organisational form fast and efficient work is not possible.

Architecture (A)

It is every engineer’s dream to be allowed to develop a completely new product.

I even had that chance several times.

And every time, the organisation swore afterwards never to do such a thing again.

Endlessly expensive and endlessly long.

You are barely finished, and the product is already out of date. The next wishes are on the table.

As a consequence I have spent a lot of time on how to design hardware products modularly enough that improvements and new functionality can be developed incrementally.

Anyone coming from the software world will recognise the increment in that.

Over there it was the same for a long time. In the days of spaghetti code, almost everything had to be redone with every change.

It was object-oriented programming and the architectural principles that followed it that made the increment possible in the first place. That was decades ago.

In hardware, that development is still ahead of us.

Modular architectures have existed on our side for more than twenty years too.

That is exactly what this element is about. It is meant to close the gaps that stand in the way of incremental product development in mechatronics.

The NewPDP does not define what such an architecture concretely looks like. That would be too specific for a general framework.

It defines which properties and which processes it has to have.

Why I leave nothing out

Back to the courtyard in Untertürkheim. Take out the Drum Beat and drop the rest.

Here is my answer.

The seven elements do not stand next to each other, they interlock. Each one creates preconditions for the others, and each one benefits from the others.

That is the nature of a system.

Pick any two of them and ask yourself what one is worth without the other.

And in this shape the NewPDP is already a simplification.

It concentrates exclusively on those elements of the system that carry the greatest need for change in mechatronic product development today.

You can start with one element. In fact you have to. But with one alone you will not get there.

When I write another overview article some time from now, the story will hopefully look a little different.

We will have solved problems we no longer need to talk about, and there will be new challenges instead.

I am not writing this series to be right. I am writing it because I do this transformation together with people who are in the middle of it.

Join me.

And now I am curious.

Which of the seven elements is the biggest problem in your organisation? And which one would be the quickest win?

Write it in the comments, or send me a message directly.

Leave a comment

And if you are facing this transformation and would rather not start alone, tell me that too.

Over the coming weeks I will take each element apart on its own. If you want the whole story, the best thing to do is subscribe to the newsletter.

Subscribe now

And if you liked this article, share it.

Share

Pass the newsletter on, so other people get something out of it too.

Share Uwe Mierisch

Sie kennen das noch aus der Schule:

Hier mal ein kleines Beispiel zur Erinnerung:

Ein Motor nimmt z.B. 100 kWh Energie in Form von 10l Diesel auf. Am Ende des Triebstranges kommen 40 kWh nutzbarer Arbeit am Rad auf der Straße an. Damit kann der LKW auf der Autobahn rund 36 km weit fahren.

Der Wirkungsgrad: 40 Prozent.

Meine Aufgabe als Ingenieur war klar und eindeutig: Den Wirkungsgrad kontinuierlich erhöhen.

Wie?
Indem ich penibel Energieverluste aufspüre!

Wo verschwindet die Energie, ohne nutzbare Arbeit zu leisten?
Reibung hier. Wärmeverlust dort.
Ineffizienzen suchen, finden und beseitigen. Das ist die Vorgehensweise.

Wenn die Messwerte dann den geforderten Verbesserungsfaktor zeigen, ist der Ingenieur stolz und der Chef zufrieden. Der Erfolg ist real.

Diese Arbeit ist sehr motivierend, weil Erfolg und Misserfolg klar und zweifelsfrei belegbar sind.

Wissensarbeit geht eigentlich genauso und trotzdem ist es grundlegend anders

Als ich Führungskraft in der Fahrzeugentwicklung wurde, lag der Fokus meiner eigenen Arbeit nicht mehr auf dem Wirkungsgrad des Produktes, sondern auf dem Wirkungsgrad meiner Organisation.

Die Problemstellung war eigentlich gleich, aber trotzdem viel, viel schwieriger zu lösen.

Es gibt einen Aufwand, das sind die Ressourcen, die eingesetzt werden:

• Personal,

• Material,

• Equipment.

Dieser Aufwand ist messbar. Man kann die Mitarbeiter zählen, die Materialkosten erfassen und die Abschreibung auf das Equipment berechnen.

Und es gibt einen Nutzen:

Die Profitabilität des Produktes. Die ist messbar — eigentlich.

Aber hier wird es kompliziert.

Wie übersetzt sich die Leistungsfähigkeit des Produktes in die Zahlungsbereitschaft des Kunden?

• Ist das Produkt nicht gut genug oder hat der Verkäufer schlecht verhandelt?

• Ist die Konjunktur schuld an zu hohen Kosten oder haben die Entwickler zu teure Lösungen gewählt?

Die Faktoren, die den Gewinn beeinflussen sind undurchschaubar und nicht quantifizierbar.

Es ist eine hochkomplexe Problemstellung, die sich einer ingenieurtechnische Analyse entzieht.

Also musste ich einen anderen Ansatz finden.

Ich fand ihn bei Peter Drucker. Und er war gleichzeitig einfach und tiefgreifend:

Effektivität: Die Frage, wofür die Ressourcen eingesetzt werden.

Effizienz: Die Frage, wie viel Ressourcen eingesetzt werden.

Wenn ich den Anteil von Aufwand reduziere, der in Tätigkeiten ohne Nutzen fließt, steigt der Wirkungsgrad.

Wenn ich die Menge an Aufwand reduziere, der in nutzvolle Tätigkeiten fließt ohne das Ergebnis zu beeinträchtigen, auch dann steigt er.

Schaffe ich es diese beiden Effekte systematisch und reproduzierbar zu realisieren, dann kann ich davon ausgehen, dass der Wirkungsgrad steigt.

Dafür brauche ich aber ein System, eine Methode.

Aus dieser Erkenntnis entstanden die zwei Modelle.

Das Granatapfelbaum-Modell — es schafft Effektivität.

Der Universelle 4-Takt-Zyklus — er schafft Effizienz.

Beide kombiniert erhöhen den Wirkungsgrad in der Wissensarbeit.

Und das wunderbare an der Sache ist, dass es nicht nur in der Entwicklung funktioniert, sondern in allen indirekten Bereichen.

Die Wirksamkeit steigern

Um den Wirkungsgrad bei der Arbeit zu erhöhen, beginne ich mit einer gründlichen Wertstromanalyse:

Welche Tätigkeiten haben einen echten Wertbeitrag, und welche nicht?

Doch das ist nur die halbe Wahrheit.

Denn jeder Fehler ist eine Verschwendung. Er führt zu Schleifen, Rücksetzern, Doppelarbeit, Überplanungen, Wiederholungen, verlorener Zeit.

Um das zu verhindern, müssen wir die Trefferwahrscheinlichkeit erhöhen und den direkten Weg gehen: ohne Schleifen, ohne Irrtümer, so geradlinig wie möglich zum Ziel.

Das ist klar die erste Priorität.

Aber da Fehler nicht komplett unvermeidbar sind, müssen wir in der zweiten Priorität erreichen, dass wir, wenn wir schon Fehler machen, diese so zeitig wie möglich machen und so schnell wie möglich erkennen.

Doch nun will ich kurz auf die wesentlichen Aspekte der beiden Modelle eingehen:

Das Granatapfelbaum-Modell kümmert sich um die Effektivität

Mit dem Granatapfelbaum - Modell wird der Wertstrom adressiert.

Über 4 Ebenen wird systematisch bewertet, welche Ziele bzw. Ergebnisse gerade jetzt die wichtigsten sind, um den größtmöglichen Nutzen zu erhalten.

Ressourcen werden immer verbraucht

Ich halte es für wichtig an dieser Stelle eine wichtige Beobachtung zu teilen:

Das ist im Sinne von einem hohen Wirkungsgrad sogar gut und richtig.

Naja.

Mitarbeiter die nichts zu tun haben, schaffen keinen Wert und werden trotzdem bezahlt,
Maschinen, die nicht ausgelastet sind, wurden bezahlt und schaffen weniger Wert.
Selbst beim Geld ist es ähnlich. Geld auf dem Konto, das nicht zur Wertsteigerung eingesetzt wird, verdient vielleicht gerade mal ein paar mickrige Zinsen.

Es geht also darum mit den vorhandenen Ressourcen die maximale Wertsteigerung zu erzielen.

Und das macht das Granatapfel-Modell und zwar über das gesamte Geschäftssystem hinweg.

Ziele und Ergebnisse werden so gesetzt, dass alle Ressourcen immer am maximalen Wertzuwachs arbeiten.

Wie das genau geht können sie in meinem Artikeln nachlesen, im Text zu diesem Podcast finden sie die Liste der Artikel und Podcast-Episoden.

https://uwemierisch.substack.com/p/managing-priorities
https://uwemierisch.substack.com/p/work-with-the-item-list
https://uwemierisch.substack.com/p/project-and-item-planning-
https://uwemierisch.substack.com/p/milestone-planning
https://uwemierisch.substack.com/p/drum-beat-get-things-done
https://uwemierisch.substack.com/p/drum-beat-planning-and-documenting
https://uwemierisch.substack.com/p/todo-management
https://uwemierisch.substack.com/p/the-todo-management-that-transforms

Überflüssige Ressourcen abbauen

Nun will ich aber doch noch einige Worte zum Einsparen sagen, denn auch das hat mich in meinem Berufsleben intensiv beschäftigt.

Ich unterscheide zwei Situationen, in denen Ressourcen reduziert werden müssen.

1. Es sind mehr Ressourcen verfügbar, als zu einer sinnvollen Wertsteigerung notwendig sind.

2. Durch hohe Ineffizienzen in der Organisation werden mehr Ressourcen benötigt, als idealerweise notwendig sind.

Fall Nummer 1 ist Top Managers Liebling, auch wenn es häufig mit unangenehmen Emotionen verbunden ist.

Nicht benötigtes Personal kann abgebaut, nicht gebrauchte Maschinen und Einrichtungen können abgeschafft werden. Budgets werden einfach gekürzt.

Leider ist das Szenario 1 im wahren Leben viel seltener anzutreffen als Szenario 2 und bei dem muss anders vorgegangen werden.

Hier müssen erst die Ineffizienzen beseitigt werden, bevor die Ressourcen reduziert werden.
Tut man das nicht, was ich leider sehr häufig beobachten musste, und reduziert die Ressourcen trotzdem, dann sinkt der Output und es entsteht eine Abwärtsspirale.

Zu einem zu hohen Ressourceneinsatz kommt dann zu allem Unglück noch ein fallender Nutzen hinzu und damit wird der Wirkungsgrad immer schlechter.

Die Ineffizienz besteht aus schlechter Effektivität und schlechter Effizienz und das sind ja gerade die Baustellen an denen wir mit den beiden Modellen arbeiten.

Richtig implementiert und konsequent angewandt schaffen sie die Voraussetzungen für sinnvolle Ressourceneinsparung.

Allerdings ist das dann noch eine zusätzliche Aktivität. Der Ressourcenabbau ist in den beiden Modellen nicht enthalten. Wenn es Sie interessiert, wie das geht, dann schreiben sie mir. Auch dazu kann ich Tipps geben.

Doch nun zum universellen 4 Takt Zyklus.

Der Universelle 4-Takt-Zyklus kümmert sich um die Effizienz

Damit sorgt er für Effizienz.

Die Sachen richtig machen heißt, auf möglichst direktem Wege zum gesetzten Ziel oder Ergebnis zu kommen.

Dafür bedient er sich einer Logik, die so allgemeingültig ist, dass sie in sehr vielen anderen Methoden auch zu finden ist. Es ist eine Art Naturgesetz.

Auch hier begegnet mir wieder die magische Zahl 4, denn er besteht aus 4 Phasen, wie es der Name schon andeutet.

Am Anfang steht eine Phase des bewussten Planens, Analysierens, Vorbereitens, gefolgt von der Phase des Tuns, danach die Phase der Überprüfung des Ergebnisses und der finalen Phase der Sicherstellung der Wirksamkeit.

Die genaue Beschreibung finden sie in einem eigenen Artikel und einer eigenen Podcast Episode und in weiteren Artikeln die ich demnächst schreiben werden.

Also abonnieren sie bitte den Newsletter, falls sie es noch nicht gemacht haben, damit sie nichts verpassen.

Subscribe now

Das Zusammenspiel

Beide Modelle werden gleichzeitig und sich überlagernd genutzt.

Der universelle 4 Takt Zyklus findet auf mehreren Ebenen des Granatapfelmodell statt. Mindestens allerdings zwingend auf Ebene 2 der Meilensteinplanung und Ebene 4 der ToDo Planung.

Es muss darauf geachtet werden, dass jedes ITEM mindestens die 4 Meilsteine aufweist, die den 4 Takten des universellen 4 Takt Zyklus entsprechen.

Ebenso muss jedes ToDo unbedingt alle 4 Takte durchlaufen. Auch wenn, gegebenen Falles, vielleicht ein Takt auch mal nur ein paar Minuten dauert, muss er auf jeden Fall stattfinden.

Bei jeder Planung wird immer betrachtet, in welchem Takt gerade gearbeitet werden muss.

Das klingt durcheinander und kompliziert?

Ist es aber nicht, es ist eine Sache der Gewohnheit. Hat man die Logik einmal intus, dann findet sich das ganz automatisch zusammen.

Effizienz und Effektivität befruchten sich gegenseitig.

Es ist nicht nur Logik sondern auch System

In diesem Artikel habe ich mich darauf fokussiert, wie der Wirkungsgrad bei der Wissensarbeit verbessert werden kann.

Genau wie in der Ingenieurtechnik werden systematisch Verluste reduziert oder eliminiert und damit der Nutzen gesteigert und der Aufwand reduziert.

Und um das zu erreichen müssen Regeln und Prozesse implementieren werden, die genau diese Arbeitskultur vermitteln und die notwendigen Fähigkeiten und Gewohnheiten bei dem Mitarbeitern entwickeln.

Über diese operativen Details schreibe ich in meinen kostenpflichtigen Artikeln. Ich empfehle Ihnen das Abo zu buchen.

Ich halte es für kostengünstig und im schlimmsten Falle können sie es monatlich wieder kündigen, falls es ihnen nicht gefällt.

Im bezahlten Abo ist auch der Chat und meine persönliche Verfügbarkeit für Fragen und Analyse ihrer konkreten Situation enthalten.

Der Vorteil der Methode besteht darin, dass sie nicht an eine konkrete Software gebunden ist.

Sie können die von mir empfohlene Software nutzen oder sie können das System in anderen Tools implementieren.

Wenn Sie möchten helfe ich ihnen auch dabei.

Was nehmen wir heute mit?

• Der Wirkungsgrad ist ein blinder Fleck in der Wissensarbeit. Er wird oft ignoriert, obwohl er entscheidend für den Erfolg der Unternehmung ist.

• Effektivität und Effizienz sind zwei unterschiedliche Fragen: Welche Ziele sind es wert, erreicht zu werden? und Wie stelle ich sicher, dass ich diese Ziele auch tatsächlich erreiche?

• Das Granatapfelbaum-Modell beantwortet die Frage der Effektivität.

• Der Universelle 4-TaktZyklus beantwortet die Frage der Effizienz.

• Es beginnt mit einer ehrlichen Wertstromanalyse: Welche Tätigkeiten haben echten Wertbeitrag? Priorisieren Sie diese, vermeiden Sie alles andere.

• Jeder Fehler ist Verschwendung. Um effizient zu arbeiten, müssen Sie Ihre Trefferwahrscheinlichkeit erhöhen und den direkten Weg gehen – ohne Schleifen, ohne Irrtümer.

• Nicht Logik allein schafft Erfolg. Es braucht Systeme, Prozesse und Regeln.

• Das System wird durch die Mitarbeiter implementiert bis es zur Gewohnheiten geworden sind.

• Effizienz und Effektivität befruchteten sich gegenseitig und werden gleichzeitig angewandt.

Wie schätzen sie sich ein? Wenden sie das Granatapfelmodell und den Universellen 4 Takt Zyklus schon an oder haben sie andere Erfahungen und Vorschläge?

Schreiben sie mir ich lese alles.

Leave a comment

In den nächsten Episoden werde ich weiter in die Details des Granatapfel-Modelles und des universellen 4 Taktzykluses eingehen. Also abonieren sie meinen Podcast, damit sie nichts verpassen.

Subscribe now

Wenn ihnen diese Folge gefallen hat, dann empfehlen sie meinen Podcast doch bitte weiter.

Share

Share Uwe Mierisch

A Career Dedicated to Efficiency

I’m an engineer, and working on efficiency has been my daily bread throughout my career.

Let’s do an example:

An engine takes in 100 kWh of energy in the form of 10 l diesel. At the end of the drivetrain, 40 kWh of useful work arrives at the wheel on the road. With that, the truck can travel about 36 km on the highway.

The efficiency: 40 divided by 100 is 0.4. 40% of the input ends up as useful value.

My task as an engineer was clear and unambiguous: continuously increase efficiency.

How? By meticulously tracking down energy losses.

Where does energy disappear without producing useful work? Friction here. Heat loss there. Find inefficiencies, locate them, and eliminate them.

When the measurement data showed the required improvement factor, the engineer is proud. The boss is satisfied. Success is real.

This work is very motivating because success and failure are clear and indisputably provable.

Knowledge Work is Actually the Same and Yet Completely Different

Then I became a manager in vehicle development, and my focus was no longer the efficiency of the product, but the efficiency of my organization.

The problem was essentially the same, but yet much, much harder to solve.

There is an input. Resources that are deployed:

• Personnel

• Material

• Equipment

This input is measurable. One can count the employees, track material costs, calculate depreciation on equipment.

And there is an output:

The profitability of the product. Also measurable—in theory.

But here it gets complicated.

How does the product’s performance translate into the customer’s willingness to pay?

• Is the product not good enough, or did the salesman negotiate poorly?

• Is the economy responsible for high costs, or did the developers choose expensive solutions?

The factors that influence profit are opaque and not fully quantifiable.

It’s a highly complex problem that resists engineering analysis.

So I had to find a different approach.

I found it in Peter Drucker. And it was both simple and profound: Effectiveness and Efficiency.

Suddenly I was back to efficiency. (Or in german terms “Wirkungsgrad” a word that covers efficiency as well as effectivness.)

If I reduce the share of effort that flows into activities without value, efficiency increases.

If I reduce the amount of effort that flows into valuable activities without minimizing the result, it increases too.

If I can achieve these two effects systematically and reproducibly, then I can assume that efficiency rises. But for that I need a system, a method.

Out of this realization emerged two models.

The Pomegranate Model—it creates effectiveness.

The Universal 4-Stroke Cycle—it creates efficiency.

Both combined increase overall efficiency in knowledge work.

And the wonderful thing about it is that it works not only in development, but in all indirect departments.

Raising “Wirksamkeit”

To increase effectivness in work, we begin with an honest value stream analysis:

Which activities have genuine value creation, and which don’t?

We must prioritize activities with value contribution. All others we should minimize or avoid entirely.

But that’s only half the truth.

Just as important as selecting the right activities is avoiding errors in the work.

Because every error is waste, it causes loops, setbacks, rework, overplanning, repetitions, lost time.

To prevent that, we must increase our hit rate and take the direct path: without loops, without errors, as straight as possible to the goal.

That is clearly the first priority.

But since errors are not completely unavoidable, in the second priority we must ensure that we make errors as early as possible and recognize them as quickly as possible.

The Pomegranate Model—Effectiveness

With the Pomegranate Model, the value stream is addressed.

It is a method of targeted prioritization. Here it’s about doing the right things.

Over 4 levels, it systematically evaluates which goals or results are most important right now to achieve the greatest possible benefit.

Resources Are Always Consumed

I think it’s important to share an observation at this point:

Available resources are always consumed!

In terms of high efficiency, that’s actually good and right.

Well.

• Employees who have nothing to do create no value and are still getting paid.

• Machines that are not utilized have been paid for and create no value.

• Even with money it’s similar—money in the account that isn’t deployed for value creation earns maybe just a few measly interest points.

So it’s about achieving maximum value creation with the available resources.

And that’s what the Pomegranate Model does, across the entire business system.

Goals and results are set so that all resources are always working on maximum value creation.

Do you want to know how that works?

Then read these articles:

Reducing Unnecessary Resources

Now I do want to say a few words about saving, because that also occupied me intensively throughout my career.

I distinguish two situations where resources need to be reduced.

1. More resources are available than necessary for meaningful value creation.

2. Due to high inefficiencies in the organization, more resources are needed than would ideally be necessary.

Case Number 1 is Top Management’s favorite, even though it’s often associated with unpleasant emotions.

Unneeded personnel can be laid off, unused machines and equipment can be disposed of. Budgets can be cut.

Unfortunately, Scenario 1 is much rarer in real life than Scenario 2, and that must be approached differently.

Here, inefficiencies must first be eliminated before resources are reduced.

If you don’t do that—which I’ve often had to observe—and reduce resources anyway, then output falls and a downward spiral begins.

To already high resource consumption comes, to make matters worse, falling output, and with that efficiency becomes ever worse.

The inefficiency consists of poor effectiveness and poor efficiency, and those are precisely the problem areas we work on with the two models. Properly implemented and consistently applied, they create the conditions for resource savings when it makes sense.

However, that’s then another additional activity. Resource reduction is not contained in the two models. If you’re interested in how that works, write me. I can give tips on that too.

But now to the Universal 4-Stroke Cycle.

The Universal 4-Stroke Cycle—Efficiency

The Universal 4-Stroke Cycle is a method with which the probability of error occurrence is reduced.

With that it creates efficiency. Doing things right means getting to the set goal or result as directly as possible.

For this it uses a logic that is so universal that it’s also found in many other methods. It’s a kind of natural law.

Again I encounter the magic number 4, because it consists of 4 phases, as the name already suggests.

At the beginning is a phase of conscious planning, analyzing, preparing, followed by the phase of doing, then the phase of checking the result, and the final phase of ensuring effectiveness. DCVI - Definition, Creation, Validation, Implementation.

The detailed description you’ll find here:

and in further articles that I’ll be writing soon.

So please subscribe to the newsletter if you haven’t already, so you don’t miss anything.

The Interplay—Efficiency in Knowledge Work

Both models are used simultaneously and overlapping.

The Universal 4-Stroke Cycle takes place on multiple levels of the Pomegranate Model. At minimum, however, it must be on Level 2 of milestone planning and Level 4 of todo planning.

Care must be taken that every ITEM has at least the 4 milestones that correspond to the 4 strokes of the Universal 4-Stroke Cycle.

Likewise, every todo absolutely must go through the 4 strokes. Even if, given the circumstances, perhaps one stroke might only take a few minutes, it absolutely must happen.

With every planning, consideration is given to which stroke needs to be worked on right now.

That sounds confused and complicated?

It’s not, it’s a matter of habit. Once you have the logic down, it all comes together automatically.

Efficiency and effectiveness mutually fertilize each other.

Not Just Logic but Also System

In this article I’ve focused on how efficiency in knowledge work can be improved.

Just like in engineering, losses are systematically reduced or eliminated and thereby benefit is increased or effort reduced.

This is about a work culture, about a shared way of thinking and proceeding that must be present synchronously and consistently throughout the entire organization.

To achieve that, rules and processes must be implemented that convey precisely this work culture and develop the necessary skills and habits in employees.

I write about these operational details in my paid articles. I recommend booking a subscription.

I think it’s cost-effective and in the worst case you can cancel it monthly.

The subscription also includes the substack-chat and my personal availability for questions and analysis of your specific situation.

The advantage is that you’re not bound to any specific software.

You can use the software I recommend, or you can implement the system in other tools.

If you like, I’ll help you with that too.

What Do We Take Away Today?

• Efficiency is a blind spot in knowledge work. It’s often ignored, even though it’s crucial to success.

• Effectiveness and efficiency are two different questions: Which goals are worth achieving? and How do I ensure I actually achieve these goals?

• The Pomegranate Model answers the question of effectiveness.

• The Universal 4-Stroke Cycle answers the question of efficiency.

• Effectiveness begins with an honest value stream analysis: Which activities have genuine value contribution? Prioritize these, avoid everything else.

• Every error is waste. To work efficiently, you must increase your hit rate and take the direct path—without loops, without errors.

• Logic alone doesn’t create success. It takes systems, processes, and rules.

• They are implemented by employees until they become habits.

• Efficiency and effectiveness mutually fertilize each other and are applied simultaneously.

What do you think about this system?

Write me a comment or send me a message. I read everything.

Leave a comment

In the next article, I will show how the Universal 4-Stroke Cycle and the Pomegranate-Model work more in detail.

If you don’t want to miss it, please subscribe to the newsletter.

Subscribe now

If you found this article helpful, don’t forget to share it with others who might benefit from it too.

Share

And if you like my newsletter consider sharing it with others as well:

Share Uwe Mierisch

Das meiste, was ich damals gelernt habe, habe ich längst wieder vergessen und vieles davon habe ich nie wirklich gebraucht.

Aber eine Struktur wurde mir so eingebläut, dass ich sie heute noch im Schlaf aufsagen kann.

Egal ob Mathe oder Physik, jede Aufgabe wurde nach demselben Muster gelöst.

Und das Muster lief so ab:

1. Aufschreiben, was gegeben ist. Alle Informationen aus der Aufgabenstellung heraussuchen und klar und explizit auflisten.

2. Aufschreiben, was gesucht ist. Die Fragestellung genau lesen. Was wird wirklich verlangt?

3. Den Lösungsweg Schritt für Schritt aufschreiben. Keinen Schritt auslassen. Wenn man etwas überspringt, kostet es Punkte in der Klausur.

4. Eine Probe machen. Kann das Ergebnis richtig sein, ist es plausibel? Dafür wird ein anderer Ansatz verwendet, der bestätigt, dass das Ergebnis im Bereich des Möglichen liegt. Wenn die Probe passt, kann ich das Ergebnis zweimal unterstreichen.

5. Einen Antwortsatz schreiben, der das Ergebnis in den Kontext der Aufgabenstellung stellt.

Kennen Sie diese Vorgehensweise auch?

Wenn ja, schreib es mir doch in den Kommentar.

Leave a comment

Mich interessiert es, ob diese Vorgehensweise in Deutschland sehr verbreitet war und ob es vielleicht auch außerhalb von Deutschland gelehrt wurde.

Ich hielt das alles für Schikane.

Unnötigen Stress.

Ein Ritual, dass nur erfunden wurde, um Schülerinnen und Schüler zu ärgern. Aber an das man sich aber besser halten sollte, wenn man gute Zensuren bekommen wollte.

Als die Schule dann vorbei war und ich ins echte Leben entlassen wurde, habe ich das ganze System über Bord geworfen.

Ich hatte geniale Ideen im Kopf und wollte sie so schnell wie möglich umsetzen. Ohne Bürokratie und nach meiner eigenen Vorgehensweise.

Leider musst ich dann doch festzustellen: So glatt läuft das nicht mit dem Freestyle. Schleifen. Rückschläge. Falsche Ergebnisse. Ich durchlebte das volle Programm.

Eines Tages wurde mir klar: Die Struktur aus der Schule folgt einem universellen Prinzip. Einem Prinzip, das im echten Leben Wunder wirkt.

Ich nenne es den universellen Viertakt-Zyklus.

Sie merken - Den Fahrzeugentwickler in mir werde ich wohl nie ganz los. Aber glauben Sie mir: Dieses Viertakt-Prinzip funktioniert überall. Nicht nur Motorenbau.

Sie kennen dieses Prinzip

Ich wage eine Vorhersage: Sie kennen dieses Prinzip bereits. Sie wenden es sicherlich schon an.

Während sie das hier hören, denken sie vielleicht: Das ist doch offensichtlich. Das mache ich seit Jahren so. Im Job, in der Freizeit, in Familie und bei anderen Verpflichtungen.

Schauen Sie trotzdem genauer hin. Und frag sie sich ehrlich: Wenden sie es konsequent und bewusst an? Oder nur intuitiv, manchmal?

Ich verspreche eines:

Das ist keine Marketing-Behauptung. Das ist die Wahrheit.

Es braucht Übung und Erfahrung, um die Methode richtig anzuwenden.

Deshalb werde ich diesem Thema mehr als nur diese eine Folge widmen.

Der Teufel steckt wie immer im Detail.

Abonnieren Sie bitte meinen Newsletter oder den Podcast, damit ihnen nichts entgeht.

Subscribe now

Aber fangen wir nicht mit den Details an. Fangen wir am Anfang an.

Was ist der universelle Viertakt-Zyklus?

DCVI

Über DCVI habe ich schon einmal geschrieben, konkret im Zusammenhang mit Produktentwicklung.

Wenn sie den Artikel kennen und mein andere Artikel lesen, finden Sie dieses Prinzip immer wieder. Mal explizit, mal implizit.

Das ist kein Zufall.

Das Prinzip ist universell. Genau deshalb taucht es ständig wieder auf.

Angewendet von mir, und von vielen anderen, die vermutlich nicht einmal meinen Namen dafür kennen.

Die vier Takte im Einzelnen

Definition

Gegeben und gesucht werden herausgearbeitet.

• Welche Informationen, die für die Lösung relevant sind, liegen vor?

• Welche Voraussetzungen müssen geschaffen sein, bevor eine Lösung überhaupt möglich ist?

• Und vor allem: Wie soll das Ergebnis aussehen? Wer braucht es, und wofür?

• Wie müssen Schnittstellen gestaltet sein, sowohl organisatorischen Schnittstellen, als auch inhaltlichen Schnittstellen ?

Wenn die Voraussetzungen fehlen, müssen sie organisiert und bereitgestellt werden, bevor die Arbeit an einer Lösung beginnt.

Im Kern ist das die Planungsphase.

Es gibt viele Werkzeuge und Methoden, die dabei helfen: Systems Thinking, Systems Engineering für Spezifikationen und Schnittstellen, Marktforschung, Design of Experiments, Projektmanagement und viele mehr.

Zu jeder Phase gibt es eine Checkfrage, mit der man feststellen kann, ob die Phase abgeschlossen ist oder nicht.

Die Prüffrage, ob die Definitionsphase abgeschlossen ist lautet:

Die Definitions- Phase wird viel zu oft abgekürzt.

Sie fühlt sich ineffizient an, weil es noch keine Lösung gibt. Der Druck, endlich loszulegen, ist enorm. Also wird die Vorbereitung abgekürzt.

Das ist ein schwerer Fehler.

Der Mut, hier langsam zu sein, zahlt sich vielfach aus.

Die Zeit, die in die Definition investiert wird, spart später weit mehr Zeit ein.

Weil sie die teuren Schleifen und Blockaden vermeidet, die entstehen, wenn man ohne Klarheit startet.

Creation

Schritt für Schritt. Genau wie in der Schule.

Schritte auszulassen, fühlt sich wie eine effiziente Abkürzung an. Ist es aber fast nie.

Die Annahme „Ich weiß doch schon, wie das nächste Ergebnis aussehen wird“ ist häufiger falsch, als man denkt.

Wenn der Fehler dann entdeckt wird, ist bereits Zeit verloren, und die Korrektur bedeutet, im Prozess zurückzuspringen. Das kostet weit mehr Zeit, als den Zwischenschritte sofort zu überprüfen und zu bestätigen.

Aber: Bewusste Schleifen sind in dieser Phase erlaubt.

Es ist richtig und sinnvoll verschiedene Ansätze auszuprobieren, zu bewerten und die beste Alternative auszuwählen, genau dafür ist die Kreationphase da.

Und sie braucht Teamarbeit.

Nicht: „Lass mich in Ruhe, meine Arbeit geht dich nichts an.“

Sondern: volle Transparenz, kollegiale Unterstützung, gemeinsame Entscheidungen. Alle arbeiten gemeinsam an der bestmöglichen Lösung.

Die Prüffrage, ob die Kreationsphase abgeschlossen ist lautet:

Validierung

Jetzt wird überprüft, ob die Lösung in der Realität tatsächlich so funktioniert, wie wir es uns vorstellen.

Dafür wird die Lösung mit der Realität konfrontiert.

Änderungen sind nur erlaubt, wenn Probleme auftreten, die korrigiert werden müssen. Späte Optimierungsänderungen bringen neue Risiken mit sich, und verfälschen das Validierungsergebnis.

Im Ingenieurwesen nennen wir diese Tätigkeit wörtlich Validierung.

Das Produkt wird unter realen oder realitätsnahen Bedingungen getestet und ausprobiert.

In anderen Kontexten geschieht Validierung durch gemeinsame Begutachtung: Die Lösung wird mit Kunden, Nutzern oder Expertinnen und Experten besprochen, die den Anwendungsfall kennen und einen aussagekräftigen Maßstab liefern können.

Die Prüffrage, ob die Validierungsphase abgeschlossen ist lautet:

Implementation

Die Implementation entspricht dem Antwortsatz.

Man könnte es auch Deployment nennen, aber dann würden die 4 Takte DCVD heißen und das gefällt mir nicht.

Jetzt muss es wirksam werden und seinen Zweck erfüllen und das tut es erst, wenn das Ergebnis beim Kunden oder Nutzer angekommen und von ihm akzeptiert worden ist.

In großen Produktentwicklungsprojekten gilt der Abschluss dieser Phase als selbstverständlich.

Kommt das Produkt nicht beim Kunden an, fließt kein Geld.

Die Konsequenz ist offensichtlich.

In vielen anderen Situationen ist das weniger eindeutig.

Ergebnisse bleiben irgendwo liegen.

Sie existieren, kommen aber nicht dort an, wo sie gebraucht werden.

Die Arbeit ist gemacht, aber sie zeigt keine Wirkung.

Ein Ergebnis, das nicht an seinem Ziel ankommt, ist kein Ergebnis. Es ist unfertig.

Selbst wenn der Kopf schon beim nächsten Projekt ist, verdient diese Phase dieselbe Disziplin wie die Phasen davor.

Die Prüffrage, ob die Umsetzungsphase abgeschlossen ist lautet:

Warum diese Vorgehensweise universell ist

Ich habe DCVI viele Jahre in der Produktentwicklung bei Mercedes-Benz Trucks eingesetzt.

Erst intuitiv, dann zunehmend bewusst und strukturiert, bis ich ihm einen Namen und eine Prozessbeschreibung gegeben habe.

Große Projekte. Hunderte Beteiligte. Investitionen in Millionenhöhe.

Wo es angewendet wurde, gab es gute Ergebnisse. Wo es vernachlässigt wurde, traten Probleme auf.

Dieses Prinzip eignet sich nicht nur bei Produktentwicklungsprojekten. Ich habe es auch in vielen anderen Zusammenhängen beobachtet und angewendet.

Ob eine Organisation modernisiert, die IT verbessert, Prozesse optimiert, Kosten gesenkt oder die Strategie überarbeitet wird: Der universelle Viertakt-Zyklus macht jede Initiative strukturell solide und unabhängig vom Zufall.

Was nehmen wir heute mit?

• DCVI, also Definition, Creation, Validatrion, Implementation, ist ein universelles Prinzip. Es gilt für jedes Projekt, jede Aufgabe, jede Initiative, im Beruf wie im privaten Leben.

• Es macht Ergebnisse verlässlich und wirksam.

• Wie beim Viertaktmotor braucht es alle vier Phasen.

• Es ist eine sequentielle Abfolge. Jede einzelne Phase muss abgeschlossen sein, bevor die nächste beginnt.

• Es ist ein sich wiederholender Zyklus, der sich kontinuierlich abläuft, im Detail wie im größeren Zusammenhang.

• Definition und Implementierung werden am häufig unzulässig verkürzt, dabei sind genau sie es, welche die Effizienz bringen.

• Mit diesem Prinzip ist Erfolg keine Frage von Glück mehr. Er wird zu etwas, das sie steuern können. Aber es braucht Übung und konsequente Anwendung.

Wie schätzen Sie das ein?

Wenden Sie den universellen Viertakt-Zyklus schon an, oder sehen sie noch Raum für Verbesserung?

Schreiben sie mir, ich lese alles.

Leave a comment

In der nächsten Folge zeige ich, wie der universelle Viertakt-Zyklus und das Granatapfelbaum-Modell als komplettes System zusammenwirken.

Wenn Sie das nicht verpassen wollen, abonnieren sie meine Newsletter oder meinen Podcast.

Subscribe now

Und wenn ihnen diese Folge geholfen hat, dann teile sie sie gerne mit anderen, die auch davon profitieren könnten.

Share

Share Uwe Mierisch

The time when I went to school is a long, long time ago.

Most of what I learned back then I’ve long forgotten. A lot of it I never needed.

But there was one structure that was drilled into me so thoroughly that I can still recite it in my sleep.

Whether math or physics, every problem was solved the same way:

1. Write down what is given. Extract all information from the problem statement and list it clearly and explicitly.

2. Write down what is being asked. Read the question carefully. What exactly is required?

3. Describe the way of creating the solution step by step. Don’t skip steps. That costs points in the exam.

4. Check your result. Does it make sense? Try a different approach to estimate whether the result could be correct. If the check confirms the result, underline it twice.

5. Write a concluding sentence that puts the result back into the context of the problem statement.

Do you know it too? If so, write it in the comments.

Leave a comment

I thought it was harassment. Unnecessary stress. A ritual that was invented only to annoy the students but is necessary to get the marks.

The moment I entered real life, I threw the whole system overboard.

I had some brilliant ideas in mind and wanted to put them into action as soon as possible, without bureaucracy and red tape.

Only to find out it didn’t go as smoothly as expected. Loops. Setbacks. Poor results. The full program.

Until one day I realized: the structure from school is built on a universal principle. One that works miracles in real life.

I call it the Universal 4-Stroke Cycle.

I can’t quite shake the automotive engineer in me — but trust me. This 4-stroke principle works everywhere. Not just in engineering.

You Already Know This Principle

I’ll make a prediction: you already know this principle. You already apply it.

After reading this article — or maybe even while reading it — you’ll say to yourself: “That’s obvious. I’ve been doing this for years. At work, in my free time, in my personal and family commitments.”

Look at it anyway. And ask yourself honestly: do you apply it consistently and deliberately? Or only intuitively, sometimes?

I promise you this:

That is not a marketing claim. It is the truth.

It takes practice and method to get there, which is why I will be spending more than just this one article on the topic. The devil, as always, is in the detail.

Subscribe so you don’t miss what’s coming.

Subscribe now

But let’s not start with the details. Let’s start at the beginning.

What Is the Universal 4-Stroke Cycle?

DCVI.

I have written about DCVI before, specifically in the context of product development.

If you’ve read that article and go back through the others, you’ll find this principle appearing again and again, sometimes explicitly, sometimes implicitly.

That’s not a coincidence. It’s universal. Which is exactly why it keeps showing up. Applied by me, and by many others who don’t even know the name.

The Four Strokes

Definition

“Given” and “sought” are worked out.

• What information is available that’s relevant to solving the problem?

• What prerequisites need to be in place before a solution is even possible?

• And most importantly: what should the outcome be?

• Who needs it, and what for?

If the prerequisites aren’t there, they need to be organized before the search for a solution begins.

This is, in essence, the planning phase.

There are many tools and methods that support it: Systems Thinking, Systems Engineering for specifications and interfaces, market research, Design of Experiments, and more.

This phase is cut short far too often.

It feels inefficient because there’s no solution yet.

The pressure to start building is enormous. So the preparation gets shortened.

That is a serious mistake!

The courage to go slowly here pays back many times over.

The time invested in Definition saves far more time later, by avoiding the costly loops and roadblocks that come from starting without clarity.

Creation

Step by step. Just like in school. Skipping steps feels like a shortcut. It almost never is.

The assumption “I already know what the next outcome will look like” is wrong more often than people think.

By the time the error is discovered, time has been lost, and fixing it requires jumping back in the process.

That wastes far more time than simply confirming each intermediate result as you go.

That said: loops are allowed in this phase.

Deliberately exploring different approaches, evaluating them, and selecting the best one is exactly what Creation is for.

And it requires teamwork.

Not: “Leave me alone, my work is none of your business.”

But: full transparency, collegial support, and shared decision-making.

Everyone working toward the best possible solution together.

Validation

Now it’s time to verify that the solution actually works in reality as required.

Changes are only permitted if problems are identified that must be corrected. Late optimization changes introduce new risks, and at this stage, those risks cannot be properly managed.

In engineering, we literally call this activity validation. The product is tested under real or close to realistic conditions.

In other contexts, validation happens through shared review: discussing the solution with customers, users, or experts who know the domain and can provide a meaningful benchmark.

Implementation

Implementation is the concluding sentence.

In large projects, completing this phase is taken for granted.

If the product doesn’t reach the customer, no money flows. The consequence is obvious.

In many other situations, it’s less clear-cut.

Results get left somewhere. They exist, but they don’t arrive where they’re needed. The work is done, but it has no effect.

A result that doesn’t reach its destination is not a result. It is unfinished work.

Even when the mind is already racing toward the next improvement, this phase deserves the same discipline as the ones before it.

Why It Is Universal

I used DCVI in product development at Mercedes-Benz Trucks for many years.

At first intuitively, then increasingly consciously and with structure, until I gave it a name and a process description.

Large projects. Hundreds of people involved. Millions in investment.

It worked where it was applied. It worked less well where it was neglected.

But I have observed and used this principle in many other contexts too.

Whether an organization is being modernized, IT is being improved, processes are being optimized, costs are being reduced, or strategy is being revised, the Universal 4-Stroke Cycle makes every initiative structurally sound and independent of chance.

What Do We Take Away Today?

• DCVI — Definition, Creation, Validation, Implementation is a universal principle that applies to every project, task, and initiative, in business and in life.

• It makes results reliable and effective.

• Like the four-stroke engine, all four phases are required.

• It is a sequence; each phase must be completed before the next one begins.

• It is a repetitive cycle that continuously repeats itself, both in detail and in the broader, overarching context.

• The definition and implementation phases are often overlooked, but they are precisely what drive efficiency.

• With this principle, success is no longer a matter of luck. It becomes something you can control. But it takes practice and consistent application.

What is your assessment? Are you already applying the universal 4-stroke principle, or is there still room for improvement?

Write me a comment or send me a message. I read everything.

Leave a comment

In the next article, I will show how the Universal 4-Stroke Cycle and the Pomegranate Tree Model work together as a complete system.

If you don’t want to miss it, please subscribe to the newsletter.

Subscribe now

If you found this article helpful, don’t forget to share it with others who might benefit from it too.

Share

And if you like my newsletter consider sharing it with others as well:

Share Uwe Mierisch

For many years, my ToDo management was an Excel spreadsheet.

I had to order tasks at the right moment and collect results when they mattered.

One forgotten follow-up could cascade into delays. One missed hand-off could derail a project.

It worked.

But there was one big problem: All responsibility rested on my shoulders.

It was very stressful for me and not really satisfying for my team.

We were driving with an applied brake.

So I built something better. A system that combines agile thinking with lean principles. A method that actually works, even when things get messy.

And now you’re reading this because you want to know what that is.

How to organize tasks systematically?

More specifically: What columns does my SeaTable base have? What’s the structure?

Or are you thinking you should order the ready-made template and apply it directly in your organization?

I get it. You want the answer. Fast. Actionable.

Here’s the problem.

If I show you the table right now, your teams will copy the structure.

They’ll create the columns. They’ll set up the rows. And in two weeks, they’ll abandon it.

Why?

Because your organization is missing the philosophy.

The real system isn’t the table. It never was.

The table is just infrastructure. A tool for support. A framework that guides you.

But the real system — the real power — is in the fundamental approach underneath.

Before the Tool, There’s a Fundamental Approach

What I’m about to share is a philosophy.

A method for organizing work so that what urgently needs to get done actually gets done. Reliably.

The table in the SeaTable base simply supports this framework.

It helps your organization stay on the path. It keeps you from drifting over time.

Without the fundamental approach first, the table is just busy work.

With it? Everything changes.

And there is one more thing.

The potential is enormous.

But the gods have placed sweat before success. So we start small. And then we keep going. Sprint after sprint. Consistent. For a long, long time.

This is not a one-time effort. It is a discipline.

1. This article explains exactly that approach, and gives you the complete system, column by column, ready to implement.

Read more

Und man trifft sie trotzdem.

Kennen Sie das?

Als Direktor für die Gesamtfahrzeugentwicklung war ich für drei Themenbereiche verantwortlich: Fahrzeugkonzept und -architektur, Produktdokumentation mit der Schnittstelle zum Produktionssystem – und die Prozesse in der Produktentwicklung.

Wir waren in einer Krise.

Wieder einmal.

Die Aufgabe war klar:

Jeder Bereichsleiter musste das Personal seiner Organisationseinheit um x Prozent reduzieren. Die Fixkosten des Unternehmens sollten runter.

Das hat mich in das übliche Dilemma gebracht.

Entscheide ich mich für das Gießkannenprinzip – überall ein bisschen kürzen und die verbliebenen Leute effizienter arbeiten lassen?

Oder sollte ich eine Aktivität komplett streichen und die damit beschäftigten Mitarbeiter abbauen?

Ich hielt mich für clever.

Ich fragte in der Organisation: Auf welche unserer Aktivitäten würden unsere internen Kunden am ehesten Verzichten?

Die Antwort hat mich überrascht.

Ich habe den Vorschlag ins Führungskreis-Meeting gebracht.

Wollen wir das wirklich tun?

Ehrlich gesagt war ich zu feige, die Verantwortung für die Entscheidung gegen den Vorschlag selbst zu treffen.

Es hätte bedeutet, dass alle verbleibenden Mitarbeiter in allen Abteilungen mehr arbeiten müssen.

Das Feedback war laut und deutlich: Machen! Das ist eine gute Lösung. Sie hat kaum Konsequenzen.

Kaum Konsequenzen?

Ich hatte danach ein paar sehr schlechte Tage.

Ich erinnere mich noch genau an das Meeting, in dem ich es dem Team sagen musste. Es fühlt sich an wie gestern. Manche Dinge vergisst man nie.

Was waren die Konsequenzen?

Zunächst: keine.

Die betroffenen Mitarbeiter haben die Entscheidung mit Unverständnis aber gefasst aufgenommen. Es waren hervorragende Kolleginnen und Kollegen, die ohne Probleme andere Aufgaben gefunden haben. Einige haben danach eine beeindruckende Karriere gemacht.

Aber fünf Jahre später?

• Alle Projekte stehen permanent im roten Bereich.

• Terminverzögerungen sind die Normalität.

• Jedes Projekt endete in einer Task Force.

• Und in dieser Task Force – wie durch Zufall – finde plötzlich Shopfloor Management statt.

Die Lehre aus dem Fehler

Was habe ich daraus gelernt?

Shopfloor Management ist kein Nice-to-have. Es bildet das Fundament, auf dem Arbeit fließt und Ergebnisse entstehen.

Eine zweite Lektion: Es braucht dedizierte Ressourcen. Konkrete, qualifizierte Menschen, die sich um den Prozess kümmern.

Share

Die ToDos im Granatapfel-Model

In der letzten Episode habe ich Ihnen den Drum Beat vorgestellt.

Er ist die dritte Ebene von meinem Granatapfelmodel, das eine wichtige Säule im Neuen Produktentwicklungsprozesses ist.

Heute gehen wir eine Ebene tiefer.

Das ToDo Management ist ein weiteres Kernelement des Granatapfel-Baum-Modells. Es ist direkt aus meiner Shopfloor-Erfahrung entstanden.

Die Ebenen darüber leiten sinnvolle Ziele ab, priorisieren sie und ordnen sie zeitlich ein.

Die ToDo-Ebene liefert die Ergebnisse.

Im Granatapfel stehen die Fruchtkerne für die ToDos.

Sie verkörpern den echten Wert – sie tragen das Aroma. Sie sind der Grund, warum wir den Granatapfel kaufen und essen.

Die ToDos schaffen die Substanz, den Inhalt. Hier wird gearbeitet.

ToDo Management hat viel mit Scrum aus der agilen Projektwelt gemeinsam – aber auch viel mit dem Shopfloor Management aus dem Lean Management Produktionssystem.

Die Idee ist einfach und klar:

Auch innerhalb dieses kurzen Zeitintervalls gelten die vier DCVI-Phasen:

1. Definition: Die Planung wer macht was bis wann.

2. Creation: Die Arbeit wird erledigt.

3. Validation: Das Ergebnis findet Bestätigung im Team.

4. Implementation: Die Ergebnisse werden an diejenigen übergeben, die damit weiterarbeiten.

Die Creation-Phase dauert am längsten.

Definition, Validation und Implementation gehen schnell. Aber das darf nicht dazu führen, diese Phasen zu überspringen oder als Formalität abzuhaken.

Auch wenn sie schnell abgeschlossen werden können – ihr Zweck muss erreicht werden. Sonst entsteht die gewünschte Effizienz nicht.

Die Regeln des ToDo-Managements

Jetzt legen wir ein paar Regeln fest, die eingehalten werden müssen, wenn wir unseren Zweck wirklich erreichen wollen.

Erste Regel: Ergebnisorientierung

Die ToDos sind an den Drum-Beat-Deliverables ausgerichtet.

· Das Ergebnis ist fix.

· Der Weg dorthin ist flexibel.

Das ist wahrscheinlich eine der anspruchsvollsten Regeln im gesamten Framework.

Ich habe allzu oft gehört:

• Das geht nicht.

• Das kann ich nicht.

• Ich brauche mehr Zeit!

Der Kampf um die Zielerreichung ist selten ein Spaziergang.

In den meisten Fällen braucht es die Bereitschaft zum Kompromiss, den Extraeinsatz über das Normale hinaus oder das Eingehen von Risiken und die Bereitschaft, dafür die Verantwortung zu übernehmen.

Und genau, weil das so schwierig ist, braucht es einen Moderator.

Jemand muss dem Team helfen, diese Kompromisse aus einer neutralen Position heraus zu erarbeiten und einen gangbaren Weg zu finden.

Und oft muss der Chef mit einbezogen werden, helfen oder zumindest seinen Teil der Verantwortung schultern.

Zweite Regel: Organisatorische Verantwortung

In Matrix-Organisationen muss die Verantwortung klar zugeordnet sein:

1. Das Projekt trägt die Verantwortung für das Erreichen der Projektziele.

2. Die Linienorganisation trägt die Verantwortung dafür, dass die Arbeit in der richtigen Qualität und pünktlich fertiggestellt wird.

Nur in diesem Rahmen ist eine realistische Bewertung der verfügbaren Ressourcen und Kompetenzen über alle Projekte und ITEMs hinweg machbar.

Darum geht es nur in der Organisationseinheit und nicht in jedem einzelnen Projekt.

Der Linienmanager trägt und teilt die Verantwortung gemeinsam mit seinem Team. Alle Aktivitäten werden integriert und auf die verfügbaren Ressourcen abgestimmt.

Er ist Teil des Team das spielt und nicht Zuschauer auf der Tribüne!

Dritte Regel: Interdisziplinarität

Zuarbeiten anderer müssen rechtzeitig identifiziert und bestellt werden.

Jeder ist persönlich dafür verantwortlich, die Zuarbeiten zu organisieren, die er von anderen braucht.

Ich habe zu oft solche Aussagen gehört:

• Der Projektleiter muss sicherstellen, dass die Kollegen alles pünktlich fertig haben, was ich brauche.

• Ich habe es den Kollegen in den Plan geschrieben, wenn sie es nicht machen, ist das nicht mein Fehler.

• Es war offensichtlich, dass ich das brauchte – ich sollte das niemandem erklären müssen.

Das bedeutet nicht, alles selbst zu machen.

Aber man muss sicherstellen, dass alles organisiert ist.

In der ToDo-Planung bedeutet das: Aufgaben sind entweder in den Plänen der Kollegen enthalten – oder es wurden Kompromisse gefunden, mit denen die Arbeit erledigt werden kann.

Vierte Regel: Ergebnisüberprüfung

Das Ziel: Alle wissen, was sie wissen müssen, damit die nächste Phase sinnvoll beginnen kann.

Wichtig: In der Ergebnisüberprüfung werden keine Entscheidungen getroffen, und Ergebnisse werden hier nicht bewertet. Wenn das notwendig ist, muss es vorher passieren.

Und dann noch etwas: Das sollte ich eigentlich nicht extra sagen müssen, aber ich habe es zu oft gehört:

„Ich bin fertig, aber ich habe keine Zeit fertig zu melden.“

Pass auf mein Freund: Du bist nicht fertig, bis die Person, die dein Ergebnis braucht, es akzeptiert und damit zu arbeiten begonnen hat.

Ob Du noch nicht fertig bist oder dein fertiges Ergebnis in Deiner Schreibtischschublade verstaubt macht für die Organisation keinen Unterschied!

Das klingt absurd. Aber das Problem ist real. Also bitte – achten Sie darauf.

Fünfte Regel: Methoden-Support bereitstellen

Ab einer bestimmten Größe sollte eine Organisationseinheit eine kleine Anzahl hochqualifizierter Menschen haben, die sich dieser Aufgabe exklusiv widmen.

Ich akzeptiere aber auch das Modell, Mitarbeiter einzusetzen, die diese Aufgabe als Teil ihrer Arbeitszeit übernehmen.

Das hat den Vorteil, mehr Menschen zu haben, die tiefer in ihre jeweiligen Organisationseinheiten integriert sind.

In beiden Modellen muss die notwendige Zeit geplant und investiert werden. Keine Placebo Supporter bitte.

Glauben Sie mir: Die hier investierte Zeit zahlt sich vielfach in der Effizienz der gesamten Organisation aus.

Machen Sie nicht den Fehler, den ich einmal zugelassen habe.

Ja, das gilt auch für kleine Unternehmen! Kein Unternehmen ist so klein, dass es sich leisten kann, ohne Struktur zu arbeiten.

Die konkrete Vorgehensweise

Wie sieht das in der Praxis aus?

Das Team plant gemeinsam für den nächsten Sprint.

Dafür verwendet es ein IT-Tool, in dem der Backlog gepflegt, geplant und Fortschritt sowie Ergebnisse dokumentiert werden.

Die Planung bleibt kurz und fokussiert. Im Idealfall eine Stunde.

Meiner Erfahrung nach sind zwei Stunden realistischer, wenn man wirklich zu einem soliden Plan kommen will.

Es hängt von der Teamgröße ab. Meine Empfehlung: nicht mehr als zehn Personen. Fünf sind ideal.

Der Rhythmus: wöchentlich.

Zuarbeiten mit anderen Organisationseinheiten werden von den Verantwortlichen auf eigene Initiative vor der Planungssitzung koordiniert. Nicht im Meeting. Davor!

Am Ende der Woche gibt es ein kurzes Check-in. Jeder berichtet kurz: Was wurde erledigt. So weiß das ganze Team, wie der Stand der Abarbeitung ist.

Soll der Chef wissen, wie es läuft?

Absolut.

Ich bin ein starker Befürworter von Bereichsmeetings, in denen der Manager mit dem Team die Dinge bespricht, die seine Aufmerksamkeit erfordern.

Ein kurzer Blick auf die Zahlen reicht: Wie viele ToDos wurden geplant? Wie viele abgeschlossen? Wieviel haben Probleme?

Ich weiß: Manche werden jetzt sagen, das ist Micromanagement. Der Chef soll vertrauen, nicht kontrollieren.

Aber ich war lange genug Manager, um es mit Überzeugung zu sagen:

Es gibt nichts Unkomfortableres als nicht zu wissen, ob das Team performt oder geradewegs in eine Krise läuft.

Was nehmen wir heute mit?

Haben Sie Fragen oder eigene Erfahrungen mit ToDo Management? Dann schreiben Sie es mir am besten in Substack in den Kommentar, schicken Sie mir eine Nachricht oder lassen Sie uns in Substack chatten.

Leave a comment

In der nächsten Episode gehe ich wieder ins operative Detail und erkläre anhand meiner Datenbank, wie alles ganz konkret funktionieren kann. Abonnieren Sie also bitte meinen Podcast oder Newsletter, damit Sie es nicht verpassen.

Subscribe now

Wenn Ihnen mein Podcast gefällt, dann empfehlen Sie ihn doch bitte weiter.

Share Uwe Mierisch

Diese Episode können sie mit eine Druck auf diesen Knopf teilen.

Share

Sometimes you know exactly that something is wrong – and do it anyway.

Sounds familiar?

As Director for Entire Vehicle Development, I was responsible for three areas: vehicle concept and architecture, product documentation with the interface to the production system, and the processes in the product engineering organization.

We were in a crisis. Again.

The task was clear: Every division manager had to reduce headcount by x percent to cut the company’s fixed costs.

That put me in the usual dilemma.

Should I apply the watering can principle: cut everywhere a little and make the remaining people work more efficiently?

Or should I cut one activity entirely and let the corresponding people go?

I thought I was being clever.

I asked within the organization: Which of our activities would our internal customers be most willing to do without?

The answer surprised me:

I brought the scenario to the management meeting for discussion.

Do we really want to do this?

Honestly, I was too much of a coward to take responsibility for the decision against the proposal myself. It would have meant: all remaining employees in all line functions would have to work more.

The feedback was loud and clear: Do it. Best solution. Hardly any consequences.

Hardly any consequences?

I had some bad days after that.

I still remember exactly the meeting where I had to tell the team. It feels like it was yesterday. Some things you never forget.

The Consequences?

At first: none at all.

The people landed well. Outstanding colleagues, found new roles without any problems. Some went on and had a very impressive careers.

But five years later:

• All projects are permanently in the red.

• Schedule delays have become the norm.

• Every project ends in a task force.

• And in that task force, as if by coincidence, Shopfloor Management suddenly starts happening.

The Lesson from the Mistake

What did I learn from this?

Shopfloor Management is not a nice-to-have. It forms the foundation on which work flows and results emerge.

A second lesson: It requires dedicated resources. Concrete, qualified people who take care of the process.

Share

The ToDos in the Pomegranate Model

ToDo Management is a core component of my Pomegranate Tree Model. It grew directly from my Shopfloor experience.

The levels above derive meaningful goals, prioritize them, and put them into a timeline.

The ToDo level delivers them.

In the pomegranate, the seeds represent the ToDo’s.

They embody the real value – they carry the flavor. They are the reason we buy and eat the pomegranate.

The ToDos generate the substance, the content. This is where the work gets done.

ToDo Management shares a lot with Scrum from the agile project world – but also a lot with Shopfloor Management from Lean Management.

The idea is simple and clear:

Even within this short time interval, the four DCVI stages apply.

1. Definition: Planning, who does what by when.

2. Creation: The work gets done.

3. Validation: The result finds confirmation in the team.

4. Implementation: The results are handed over to those who need to work with them.

The Creation phase takes the longest. Definition, Validation, and Implementation happen quickly.

But that must not lead to skipping these stages or treating them as trivial.

Even if they can be completed quickly, their purpose must be achieved – otherwise the required efficiency effect never materializes.

My opening example made that clear.

The Rules of ToDo Planning

Let’s set out some rules that must be followed if we truly want to achieve our purpose:

Results orientation

The ToDos are aligned with the Drum Beat deliverables.

• The result is fixed.

• The path to get there is flexible.

This is probably one of the most demanding rules in the entire framework.

I’ve heard it all too often:

• That won’t work,

• I can’t do that,

• there isn’t enough time!

The fight for goal achievement is rarely a walk in the park.

In most cases it requires willingness to compromise, going the extra mile, or accepting a risk and taking responsibility for it.

And precisely because this is so difficult, a moderator is needed.

Someone must help the team work out these compromises from a neutral position and find a way forward.

And often the boss simply has to step in and shoulder at least part of the responsibility.

Organizational ownership

This is a fascinating aspect I’ve already written several articles about, and will probably write more.

In matrix organizations, responsibility should be clearly assigned.

1. The project bears responsibility for achieving the project goals.

2. The line organization bears responsibility for ensuring work is completed with the right quality and on time.

Since I look at not only projects but everything else the organization needs to accomplish with ITEM Management, organizational ownership becomes even more critical.

And that across all projects and ITEMs from which contributions toward the agreed results are required from the team.

The line manager bears and shares the responsibility jointly with the team. All activities are integrated and aligned with available resources.

Interdisciplinarity

Contributions from others must be identified and coordinated in time.

Here I want to address a rule I long considered self-evident, but which perhaps hasn’t always been understood that way more recently.

Everyone is personally responsible for organizing the contributions they need from others.

What do I base that on?

Well, over the years I’ve heard statements like these all too often:

• The project manager needs to make sure the colleagues finish everything I need on time.

• Or: I put it in the plan for the colleagues, if they don’t do it, that’s not my fault.

• Or: It was obvious I needed that, it’s always been this way, I shouldn’t have to explain it to anyone.

That doesn’t mean doing everything yourself, but you must ensure everything is organized.

In ToDo planning, that means making sure tasks are either included in colleagues’ plans or that compromises are found when things don’t work as hoped.

Results review

How detailed this review is in any given case must be decided in context.

The goal: everyone knows what they need to know so the next stage can start meaningfully.

Important: No decisions are made during the results review, and results are not evaluated here. If that’s necessary, it must be done beforehand.

The results must, where necessary, be passed on beyond the boundaries of the organizational unit. What’s finished must also arrive where it’s needed.

I shouldn’t have to say this – but I’ve heard it far too often:

“I’m done, but I don’t have time to report it as done.”

Listen: you’re not done until the person who needs your result has accepted it and started working with it.

Whether you’re not yet done or your finished result is collecting dust in your desk drawer makes no difference to the organization!

It sounds absurd. But the problem is real. So please – pay attention to this.

Support.

My view: above a certain size, an organizational unit should have a small number of highly qualified people dedicated to this role.

I also accept the model of using employees who take on this task as part of their working time. That has the advantage of having more people who are more deeply integrated into their respective organizational units.

In both models, the necessary time must be planned and invested. No placeholder titles, please.

Believe me: the time invested here pays back many times over in the efficiency of the entire organization.

Don’t make the mistake I once allowed to happen.

Organize these employees as a tight-knit team that builds its own identity around keeping ToDo Management running efficiently and at a high operational level in the organization.

Yes, this applies to small companies too! No company is so small that it can afford to work without structure.

The Approach

The team plans together for the next sprint. For this, it uses an IT tool in which the backlog is maintained and progress and results are documented.

The planning stays short and focused. Ideally one hour. In my experience, two hours is more realistic if you truly want to arrive at a solid plan.

It depends on team size. My recommendation: no more than ten people. Five is ideal.

The cadence: weekly. Either at the start of the week or at the end of the previous week.

Contributions with other organizational units are coordinated by the responsible parties on their own initiative before the planning session. Not during the meeting. Before!

At the end of the week there’s a short check-in. Everyone reports briefly: What’s been completed.

That way the whole team knows what’s happening.

Should the Boss Know How Things Are Going?

Absolutely.

I’m a strong advocate of department meetings where the manager discusses with the team the things that need their attention. I’ll examine how often these meetings should take place in a dedicated article.

A simple set of numbers is enough: How many ToDos were planned? How many completed? Where are the problems?

I know: some will now say this is micromanagement. The boss should trust, not control.

But I was a manager long enough to say this with conviction:

There is nothing more uncomfortable than not knowing whether your team is performing or heading straight for a crisis.

What Do We Take Away Today?

• Shopfloor Management and ToDo Management are not bureaucracy. They create the structure that makes results possible in the first place.

• As the fourth and lowest level of the Pomegranate Tree Model, this is where the actual substance – the content of the work – is created. This is where the value that drives the company’s success is generated.

• ToDo Management follows rules and has a structured, defined approach that is carried out with discipline and professionalism.

• To keep the method alive, the organization needs appropriately qualified people who have made this topic their own – people who continuously develop the method further and help colleagues apply it correctly.

• And: The manager can and should know how things are going. Transparency protects everyone, which is why they must be involved in ToDo Management.

Do you have questions or your own experiences with ToDo Management? Feel free to write in the comments or send me a message.

Leave a comment

In the next article I will go into operative detail again and explain, using my database, how everything can work in very concrete terms.

If you dont want to miss it, please subscribe to the newsletter.

Subscribe now

If you found this article helpful, don’t forget to share it with others who might enjoy it too!

Share

Agile has become a buzzword. You can’t go anywhere without running into it.

If you’re not agile, people look at you like you’re hopelessly behind the times. As if you still don’t own a smartphone in 2026. Say you work agile, and you get nods of approval and a pat on the back.

But behind all the agile hype sits an idea that actually works:

In my previous article, “Drum Beat: Get Things Done. Most Important First.”, I explained why this is a critical element for achieving important business goals.

In today's article, I go into the operational details.

Because knowing how things should work is one thing.

The specific mechanics that make the difference between "somewhat helpful" and "this actually makes us more efficient" are another.

So let’s walk through the Drum Beat table, column by column.

Read more

Gleich daneben waren die Fenster, durch die man die Fernverkehrsstraße beobachten konnte, auf der viel LKWs gefahren sind.

Im Herzen von Stuttgart natürlich sehr viele Mercedes LKWs.

Jeden Montag haben wir uns vor der Wand in meinem Büro versammelt und die Aufgaben geplant und die KPIs durchgesprochen.

Ich hatte damals einen sehr ungewöhnlicher KPI auf dem Board, den ich selbst erfunden hatte: Die Aufgaben- Abarbeitungsgeschwindigkeit.

Die Idee war einfach.

Lieber eine kleinere Aufgabe wählen und sie abschließen, als an einer großen lange herumzudoktern.

Das Ziel war es schnell Ergebnisse zu schaffen, die ausgeliefert werden können und mit denen andere weiterarbeiten können.

Es hat nicht funktioniert.

Der KPI kam seinem Zielwert nicht näher.

• Die Mitarbeiter haben ihre Aufgaben aufgeschrieben.

• Jede Woche gab es einen neuen Zwischenstand.

• Und Woche für Woche hatten dieselben Punkte denselben Status: „in Arbeit”.

• Die Aufgabenliste wurde wöchentlich länger und Aufgaben verschwanden meist erst dann von der Liste, wenn sie sich überlebt hatte.

Ergebnisse? — selten.

Der Auftraggeber war weitergezogen, die Frage war nicht mehr aktuell, das Problem hatte sich anders gelöst.

Es war echt frustrierend.

Wie kann es sein, dass man bewusst auf Geschwindigkeit fokussiert und trotzdem weder schneller noch besser wird?

Die Antwort liegt in einem Detail, das ich falsch eingeschätzt hatte:

Ich hatte die Zeit offengelassen.

Wer keine Deadline einfordert, bekommt keine Lieferung.

Solange „fertig” irgendwann in der Zukunft ist, wird an einem beweglichen Ziel gearbeitet.

Es entsteht ein gemütlicher Mittelmaß-Modus:

• Jede Woche reicht ein Zwischenstand,

• jede Woche hat man „etwas getan”,

• aber nichts ist abgeschlossen.

Der Strom an Updates ersetzt das fehlende Ergebnis.

Der Aufgaben-Abarbeitungsgeschwindigkeits-KPI lag wie ein Fels auf dem Boden des Ozeans und bewegte sich keinen Millimeter.

Aktivität ist eben keine Lieferung und Berichterstattung ist kein Ergebnis.

Die harte Regel: drei Monate. Dann ist Schluss.

Was habe ich aus dem Shop-Floor-Experiment gelernt?

Nicht „wir schauen mal, bis wann wir das perfekte Ergebnis schaffen”.

Nicht das Endergebnis hat das Primat, sondern der Liefertermin.

Nimm dir nicht mehr vor, als du in drei Monaten fertigbekommst und liefere dann, ohne Ausrede.

Das ist der Drum Beat.

Der Name ist bewusst gewählt.

Ein Schlagzeuger gibt nicht jede Sekunde einen anderen Takt vor.

Er schlägt im gleichmäßigen Rhythmus und alle orientieren sich daran.

Genau so funktioniert die dritte Ebene meines Neuen Produktentwicklungsprozesses.

• Drei Monate.

• Definierte Ergebnisse.

• Geliefert wird, wenn der nächste Beat fällt.

Warum genau drei Monate?

Warum nicht eine Woche wie in einem Sprint?

Warum nicht ein Jahr, wie viele Konzerne planen?

Drei Monate haben zwei Eigenschaften, die kein anderer Takt mitbringt:

– Es ist lang genug, um etwas Substanzielles fertigzubekommen. Mit drei Monaten verlassen Sie die Klein-klein-Zone.

– Es ist kurz genug, um relevant zu bleiben. Drei Monate sind nah genug an heute, dass die Zukunft vorhersehbar ist.

Das ist der Sweet Spot:

• Groß genug, dass es zählt,

• rechtzeitig genug, dass es noch zählt, wenn es fertig ist.

Wie passt das ins Granatapfel-Modell?

Wer schon einmal einen Granatapfel aufgeschnitten hat, weiß, was ich meine.

Die Frucht ist keine solide rote Masse, sondern eine durchstrukturierte Architektur.

Ich sehe sehr viele Parallelen zu meinem New PDP.

• Der Baum trägt die Früchte und gibt mit seinem Stamm und den Ästen die Struktur.

• Die Frucht ist greifbar und zählbar und stellt einen habhaften Mehrwert dar. Der Granatapfel durchläuft eine Reihe von Entwicklungsstadien, die alle ihre eigenen Merkmale aufweisen.

• Die Kammern geben Struktur, indem sie die Frucht in separate Segmente aufteilen.

• Die Fruchtkerne sind die roten, saftigen Perlen in den Segmenten — sie tragen den eigentlichen Geschmack.

Jede dieser vier Ebenen hat im NewPDP genau eine Entsprechung:

• Der Granatapfelbaum symbolisiert die Programmebene. Er trägt alles, was die Firma beschäftigt und erfolgreich macht. Wofür sie die vorhandenen Ressourcen einsetzt und das Geld investiert wird. Er beinhaltet die Produkte, welche die Kunden begeistern, die Kasse füllen und die Wettbewerber deklassieren.

• Jeder Granatapfel ist ein einzelnes Vorhaben, welches ich ITEM nenne. Hier messen wir die Endergebnisse, jedes für sich ein abgeschlossener greifbarer Mehrwert, ein signifikanter, großer Beitrag zum Unternehmenserfolg. Die ITEMs reifen durch mehrere Reifegrade, die durch Meilensteine gekennzeichnet sind.

• Die Segmente im Granatapfel sind die Drum Beats — in sich abgeschlossenen 3-Monats-Inkremente, in denen priorisierte Zwischenergebnisse geliefert werden, alle Segmente zusammen bilden die komplette Frucht..

• Die Fruchtkerne sind die ToDos — die einzelnen Aufgaben innerhalb eines Drum Beats. Sie liefern die eigentliche inhaltliche Substanz.

Das ergibt eine einfache, gut steuerbare Struktur.

Jede Ebene liefert einen Beitrag die Komplexität aufzubrechen und beherrschbar zu machen.

Deliverables: Was in den Drum Beat reinkommt und was bewusst nicht.

Deliverables sind keine Aktivitäten.

Nicht: „wir arbeiten an X”.

Welche das sind, wird nicht beliebig gewürfelt, sondern bewusst ausgewählt.

Die Regel ist einfach:

In den Drum Beat kommt:

1. Was den größten kurzfristigen Wertzuwachs produziert.

2. Was das größte Problem verursachen würde, wenn es nicht jetzt erledigt wird.

Das heißt automatisch: Nicht alles passt rein.

Drei Monate sind kurz.

Es gibt immer mehr Wünsche als Kapazität.

Genau das macht die Auswahl wertvoll — sie zwingt zum Kompromiss.

Wichtiger als die Frage „Was machen wir?" ist die Frage „Was machen wir bewusst nicht?".

Denn das, was nicht in den Drum Beat reinkommt, wird eben auch nicht geliefert!

Und das müssen alle wissen — niemand soll darauf warten.

Das ist nicht Ehrlichkeit aus Höflichkeit.

Das ist Schutz vor Verschleppung.

Wenn jemand auf ein nicht eingeplantes Ergebnis wartet, wird Zeit und Ressource verschwendet, die eigentlich woanders eingesetzt werden müssen.

Damit das funktioniert, müssen die Konsequenzen mit auf den Tisch.

• Wer braucht das ausgeklammerte Ergebnis bis wann?

• Was passiert, wenn es nicht geliefert wird?

• Wie überbrücken wir den Mangel — Workaround, Aufschub, Kompromiss?

Erst wenn diese Fragen beantwortet sind, ist die Planung belastbar.

Die Drum-Beat-Planung

Diese ganze Auswahl-und-Konsequenz-Arbeit hat einen Namen: die Drum-Beat-Planung.

In der Drum-Beat-Planung machen alle Beteiligten mit.

• Nicht der Projektleiter allein.

• Nicht ein Steering Committee

• sondern das gesamte Team, was danach liefern muss.

Ganz böse Falle!

Jeder Beteiligte sagt zu:

• auf die Deliverables,

• auf das, was bewusst weggelassen wird,

• und auf den Liefertermin.

Wer bei der Planung nicht mitgedacht und verstanden hat, wird unweigerlich zum Problem, wenn es an die Lieferung geht.

Was nach der Planung folgt, ist einfach.

Es wird geliefert.

Kein:”Das müssen wir nochmal überplanen, es ist mir was dazwischengekommen.”

Der Beat steht, jeder gibt sein Bestes.

Am Ende steht die Review

• Hat es gereicht?

• Ist alles so erledigt, wie beabsichtigt?

In der Regel nicht.

Das Leben ist ein Eichhörnchen und hüpft von Ast zu Ast.

Wir wissen aber, dass wir alles getan haben, das Wichtige und das Mögliche zu tun.

Das Erreichte ist nun die Basis für den nächsten Drum Beat, der mit der gleichen Intensität und Ernsthaftigkeit geplant und durchgeführt wird.

Damit ist jetzt alles klar, um los zu legen. Wie das organisiert wird werde ich in der nächsten Episode besprechen.

Wenn sie zum Drum Beat Fragen oder Hinweise haben, dann schreiben sie es mir am besten in Substack in den Kommentar, schicken sie mir eine Nachricht oder lassen sie uns in Substack chatten.

Leave a comment

Im nächsten Artikel werde ich wieder ins operative Detail eingehen und anhand meiner Datenbank erklären, wie man den Drum Beat genau plant. Den Artikel finden sie in meinem englischen Teil des Substack Newsletters.

In der nächsten Podcast Episode gehe ich dann auf die ToDo Ebene ein, also abonnieren sie bitte meinen Podcast oder meinen Newsletter, damit sie es nicht verpassen.

Subscribe now

Was nehmen wir heute mit?

Wenn ihnen mein Podcast gefällt, dann empfehlen sie ihn doch bitte weiter.

Share Uwe Mierisch

Every Wednesday we gathered in front of our Shop Floor dashboard and reviewed tasks and KPIs.

I had introduced one KPI that was unusual at the time, and which I had named: Task Completion Speed.

The idea was simple.

Pick a smaller task and close it rather than fiddle with a huge one.

The goal was to produce shippable results quickly.

Results we could deliver, and somebody else could build on.

It didn’t work.

This KPI Didn’t Help

This is what happened:

• People wrote their tasks on the board.

• Every week, a status update.

• And month after month, the same items showed the same status: “in progress.”

• The list grew week by week, and tasks usually disappeared only after they had outlived themselves.

But, results?

The requester had moved on, the question wasn’t relevant anymore, the problem had solved itself differently.

It was really frustrating.

How can it be that you deliberately optimize for speed and still get neither faster nor better?

The answer lies in a detail I had misjudged:

I had left the time open.

No Deadline, No Delivery

As long as “done” sits somewhere in the future, work behaves accordingly.

A comfortable mediocrity sets in:

• every week a status update is enough,

• every week you’ve “done something,” but nothing is finished.

A flow of updates but still missing results.

The Task Completion Speed KPI remained completely stationary, like a rock on the ocean floor.

Activity is not delivery. A Report is not a result.

The Hard Rule: Three Months. Then It’s Done.

What did I learn from the Shop Floor experiment?

Not “let’s see how far we get toward the perfect outcome.”

The delivery date comes first, not the final result.

Don’t commit to more than you can ship in three months, and then deliver it, no excuses.

That is the Drum Beat.

The name is intentional.

Drummers don’t change the tempo every second.

They hit the beat and everyone else follows it.

That is exactly how the third level of my New Product Development Process works.

• Three months.

• Defined deliverables.

• Delivery happens when the next beat hits.

Why Exactly Three Months?

Why not four weeks like a sprint?

Why not a full year like many corporation’s plan?

Three months have two properties no other rhythm offers:

– Long enough to ship something substantial. Three months take you out of the small-stuff zone.

– Short enough to stay relevant. Three months are close enough to today that the future is still predictable.

That’s the sweet spot of delivery:

• big enough to matter

• small enough that it still matters when you’re done.

The Pomegranate Model

If you’ve ever cut open a pomegranate, you know what I mean.

The fruit is not just a single red mass. It’s designed architecture.

When I think about the New Product Development Process, I think of a pomegranate tree.

• The tree holds all the fruit and supports them by the structure of its trunk and branches.

• The fruit is both touchable and measurable, and provides a tangible value. The pomegranate goes through a number of different maturity stages, each with its own distinctive features.

• The chambers give it structure by dividing it into separate sections.

• The arils are the red, juicy beads inside the chambers — they carry the actual flavor.

Each level of NewPDP has a direct counterpart in this picture:

• The pomegranate tree symbolises the programme level. It holds everything the company busies itself with — everything that makes it successful. It carries the products that delight customers, fill the cash register, and outclass the competition.

• Each pomegranate is a single endeavor, which I call ITEM. This is where we measure the end results, each of which is a tangible piece of value and a significant contribution to the company’s success. The maturity stages are identified by milestones.

• The chambers inside the pomegranate are the Drum Beats, which are self-contained three-month increments in which prioritised interim results are delivered.

• The arils represent the individual tasks, or ToDos, within a Drum Beat. They carry the value.

This gives you a simple, manageable structure.

Each level breaks the complexity down into something you can actually handle.

Deliverables: What Lands in the Drum Beat — and What Deliberately Doesn’t

Deliverables are not activities.

Not “we’re working on X.”

The selection process is not random; it is a deliberate choice.

The rule is simple:

Into the Drum Beat goes

1. whatever produces the biggest short-term increase in value and

2. whatever will cause the biggest problem if it is not done right now.

That automatically means: not everything fits.

Three months are short.

There are always more wishes than capacity.

The selection’s value lies precisely in its ability to force compromise.

The question “What do we deliberately not deliver?” is just as important as “What do we commit to delivering?”, because if something doesn’t go into the Drum Beat, it won’t happen.

Everyone has to know this. No one should be waiting for it.

This isn’t politeness dressed up as honesty.

It’s protection against delay.

If even one person is waiting for an unrealistic outcome, that waiting uses up time and resources that could be used elsewhere.

For this to work, the consequences have to come on the table.

• Who needs the omitted result, by when?

• What happens if it doesn’t come?

• How do we bridge the gap — workaround, deferral, compromise?

Only when these questions are answered is the planning robust.

Drum Beat Planning

All this selection-and-consequence work has a name: Drum Beat Planning.

In Drum Beat Planning, everyone involved participates.

• Not the project manager alone.

• Not an steering committee.

• The team that will actually deliver.

That is a nasty trap that leads to missing commitments and a lack of understanding.

Everyone involved signs off:

• on the deliverables,

• on what is deliberately left out,

• on the delivery date.

Whoever doesn’t think along during planning will inevitably become a problem when it’s time to deliver.

What follows planning is simple.

Delivery happens.

No “let’s re-plan, something came up.”

The beat stands firm. Everyone gives their all until they reach the finish line.

Then comes the review.

• Was it enough?

• Did we achieve everything we set out to do?

Usually not.

Life is a squirrel that hops from branch to branch. But we know we did everything that was important and possible.

What has been achieved becomes the basis for the next Drum Beat, which is planned and executed with the same intensity and seriousness.

Conclusion

Is something still missing for you? Then write it in the comments, sent me a message or let’s chat on substack.

Leave a comment

In the next article I will go into operative detail again and explain, using my database, how everything can work in very concrete terms.

Next is the ToDo level, where we'll discuss how to organize the daily activities that actually get the work done.

If you dont want to miss it, please subscribe to the newsletter.

Subscribe now

If you found this article helpful, don’t forget to share it with others who might enjoy it too!

Share

And if you like my newsletter, I would be grateful if you would share it as well.

You have a goal. You know what you need. Now what?

A clear goal matters — it’s what ensures you get exactly what you want, not something else entirely.

But do you also know how to get there?

Without that knowledge, you’re leaving the path to chance.

Maybe chance takes you straight to the finish line. Maybe it leads you there with a dozen detours. Or, in the worst case, you miss the target completely.

Everyone knows how chance works. And most of us are familiar with Murphy’s Law — the idea that when left to chance, things tend to choose the less favorable option. So let’s leave nothing to chance. Let’s steer the process and replace luck with skill.

One way to steer that process is through ITEM planning — and this is exactly where milestones come into play.

In this article, we’ll take a close look at the second planning level in the ITEM Base planning tool: milestone planning.

If you haven’t yet read “The plan captures the route, not the journey”, I’d recommend it. That article lays the foundation and explains the key principles you need to use this planning level effectively.

In that piece, I covered two important aspects of planning:

• The preparatory work of finding the best route to your goal, including making sure all necessary prerequisites are in place at the right time.

• The ongoing definition of concrete next steps by the people closest to the actual work.

Both of these can be supported by a tool that, on one hand, provides guidance through the process flow and, on the other, enables information exchange between all involved.

A quick recap of where we are:

• At the ITEM level, we’ve done the groundwork: each ITEM is clearly categorized and has a defined goal.

• Now it’s about finding the path to that goal and enabling everyone involved to stay synchronized.

So let’s look at what elements an ITEM milestone plan needs to contain in order to be genuinely helpful and orienting.

Read more

Er gibt Orientierung, ermöglicht Priorisierung und deckt Abhängigkeiten auf.

Im letzten Artikel habe ich beschrieben, wie genau das organisiert werden kann.

Beides muss verstanden, beherrscht und konsequent angewendet werden.

Also: Schauen wir uns heute das Innenleben der ITEMs an.

Wie ein Granatapfel durchlaufen auch Arbeits-ITEMs charakteristische Entwicklungsphasen, in denen sie reifen und schrittweise ihre endgültigen Eigenschaften ausbilden.

Anders als beim Granatapfel passiert das aber nicht automatisch von Natur aus, sondern es muss bewusst gesteuert werden.

Und damit kommen wir zu einem höchst kontroversen Thema: der Projektplanung.

Manche treiben Planung ins Extrem; andere lehnen sie vollständig als unnötige Bürokratie ab.

Darum müssen wir uns fragen:

Hat eine der beiden Seiten Recht, oder liegt die Wahrheit irgendwo in der Mitte?

Planen oder nicht planen — das ist hier die Frage.

Helmuth von Moltke, ein preußischer Generalfeldmarschall und Chef des Großen Generalstabs, wird im Buch „Moltkes Militärische Werke” folgendermaßen zitiert:

(Quelle: Helmuth von Moltke: Moltkes Militärische Werke: II. Tätigkeit als Chef des Generalstabes der Armee im Frieden. Zweiter Teil. Berlin: Ernst Siegfried Mittler und Sohn, 1900, S. 291 — Aufsatz von 1871: „Über Strategie”.)

Ich werde dieses Zitat als Ausgangspunkt für diesen Artikel verwenden.

Ich werde untersuchen, ob Projektpläne notwendig sind und, wenn ja, wie sie gestaltet sein müssen, um ihren schlechten Ruf abzulegen.

Schauen wir uns also genauer an, was Moltke bezüglich Planung zu sagen hat und was wir daraus lernen können.

Wer nicht plant hat keine Grundlage zum Handeln.

Auch wenn man es auf den ersten Blick so interpretieren könnte, ist Moltkes Leitsatz keine Absage an die Planung.

Im Gegenteil!

Der Kern seiner Doktrin besagt, dass Planung unverzichtbar ist, um die Armee in eine vorteilhafte Ausgangsposition zu bringen, aber niemals den gesamten Feldzug bestimmen kann.

Er unterscheidet zwei Phasen:

• Vor Kriegsbeginn (Aufmarsch)

• Nach dem ersten Schuss (Auftragstaktik)

Schauen wir uns also zuerst den Aufmarsch an.

Die Planung vor Beginn einer Operation nennt er den „Aufmarsch”.

Er bezeichnet ihn als das Element von Planung und Ausführung, das eine präzise, fast mathematische Vorgehensweise erlaubt.

Im Gegensatz zum späteren Gefecht ist er rein administrativ und er ist logistisch steuerbar.

In der Vorbereitungsphase gibt es noch keine Volatilitäten und unvorhergesehene Handlungen des Gegners. Darum kann ein theoretisch optimaler Ansatz frei von jeglichen störenden Einflüssen erarbeitet werden, der die beste Erfolgswahrscheinlichkeit hat.

Darauf basierend müssen dann alle Voraussetzungen geschaffen werden, die nötig sind, um die Eintretenswahrscheinlichkeit für diese Planung zu maximieren.

Das passiert alles in dem Wissen, dass in der Ausführung störenden Einflüsse unweigerlich auftreten und bewältigt werden müssen.

In anderen Worten:

Er begründet die Notwendigkeit eines präzisen geplanten Aufmarschs wie folgt:

Unumkehrbarkeit von Fehlern.

Da der Feind die eigene Handlungsfähigkeit nach dem ersten Kontakt einschränkt, muss die anfängliche Positionierung perfekt sein.

Fehler im Aufmarsch der Armee sind über den gesamten Verlauf des Feldzugs kaum mehr korrigierbar.

Logistik ist das zentrale Element der Kriegsführung. Alles Personal und alle Ausrüstung müssen zum richtigen Zeitpunkt am richtigen Ort sein.

Daher muss der Zeitplan der Operation präzise geplant werden, um ihn später so genau wie möglich einhalten zu können.

In dieser Hinsicht sind Fehler nicht korrigierbar. Ist die Zeit verstrichen, lassen sich Ressourcen nicht mehr im Nachhinein umpositionieren.

Das ist auch der Grund dafür, dass schon vor Beginn der Aktion alle in die perfekte Ausgangsposition gebracht sein müssen.

Dabei geht es nicht nur um die räumliche Dimension, sondern um alles. Also auch Aspekte wie Ausbildung, Informationsbereitstellung, usw. sind wichtig.

Unmöglichkeit der Improvisation.

Laut Moltke lässt sich der Aufmarsch von Armeen aus Millionen von Soldaten und deren Versorgung nicht improvisieren.

Improvisation erfordert schnelle Entscheidungsfindung unter Druck, mit begrenzten Informationen und Zeit. Je komplexer eine Situation ist, desto mehr Variablen, Abhängigkeiten und mögliche Konsequenzen müssen gleichzeitig berücksichtigt werden.

Ab einem gewissen Komplexitätsgrad kann der menschliche Geist einfach nicht mehr alle relevanten Faktoren schnell genug verarbeiten, um effektiv zu improvisieren. Entscheidungen werden zu Raterei statt zu validen Entscheidungen, und das Risiko kaskadierender Fehler steigt dramatisch.

Zudem gibt es in komplexen Operationen oft viele voneinander abhängige Akteure und Ressourcen. Eine improvisierte Änderung in einem Bereich kann unbeabsichtigte Folgewirkungen im gesamten System erzeugen, die im Moment kaum vorherzusehen und zu kontrollieren sind.

Deshalb muss Komplexität durch Planung und perfekte Vorbereitung so weit reduziert werden, dass das Reagieren auf die unvermeidliche Volatilität während der Ausführung diese Grenze nicht überschreitet.

Planung als interdisziplinäre Herausforderung

Moltke betrachtete Planung nicht als rein militärisches Silo.

Für ihn war es eine interdisziplinäre Aufgabe, die wirtschaftliche, technologische und gesellschaftliche Faktoren integrieren musste.

Die Unverzichtbarkeit dieser umfassenden Planung gründet in der Erkenntnis, dass der moderne Krieg alle Ressourcen einer Gesellschaft beansprucht.

Schauen wir uns nun die Auftragstaktik an.

Moltke gilt als Erfinder der „Auftragstaktik”.

Für ihn war wesentlich, dass Vorgesetzte das Ziel und die Absicht klar formulieren, während die konkrete Ausführung dort entschieden werden soll, wo die Situation tatsächlich sichtbar und greifbar ist: auf dem Gefechtsfeld.

Moltke erkannte, dass Pläne angepasst werden müssen, sobald die Realität eintritt.

Daher betrachtete er starre Befehlsketten als Hindernis und verließ sich stattdessen auf selbständig denkende, verantwortungsbewusste Unterführer, die im Geiste der übergeordneten Absicht handelten.

Das bedeutet aber nicht, dass es gar keine Befehle gibt.

In einer Dienstvorschrift von 1888 schrieb er:

„Der Befehl muss alles enthalten — aber auch nur das — was der Untergebene zur Erreichung des gegebenen Zweckes nicht selbst bestimmen kann.”

Für ihn bedeutete Auftragstaktik kein Chaos, sondern eine klare, gemeinsame Orientierung:

• Die Ziele des Befehlshabers bildeten den festen Punkt, an denen sich jede Initiative ausrichtet.

• Durch konsequente Dezentralisierung von Entscheidungen schuf Moltke eine Führungskultur, die schneller, anpassungsfähiger und wirksamer war als die streng hierarchischen Modelle seiner Zeit.

Lassen wir es genug sein mit den Erkenntnissen des alten Preußen und schalten wir um auf meine Interpretation.

Kein Plan ist schlecht, zu viel Plan aber auch.

Schauen wir uns also nun mal an, wie ITEM-Planung vor diesem Hintergrund und auf Basis meiner eigenen Erfahrung aussehen sollte.

Planung ist Vorbereitung

Dafür werden alle bekannten Fakten analysiert, wahrscheinliche Entwicklungen antizipiert und mögliche, sinnvolle Szenarien durchgespielt.

Das schließt auch die Anwendung aller Erfahrungen und Lessons Learned aus früheren Aktivitäten, die in Planungsvorlagen und Projektmanagement-Datenbanken festgehalten sind, mit ein.

Das Ergebnis ist dann der theoretisch beste Ansatz, der in zeitlich geplanten Meilensteinplänen dokumentiert und mit allen Beteiligten besprochen wird.

Wichtig ist, dass die Voraussetzungen und Ressourcen, die zur Umsetzung dieses Plans erforderlich sind, identifiziert und deren Bereitstellung organisiert wird.

Der Plan muss Orientierung geben und Verantwortlichkeiten klären.

Je größer das ITEM, desto mehr Planung ist erforderlich.

Ein kleines, kurzfristiges ITEM mit einer Handvoll an Beteiligten verzeiht Planungsfehler — man korrigiert, passt an und macht einfach weiter.

Aber je größer und langfristiger ein ITEM ist, desto mehr Menschen sind beteiligt, desto mehr Abhängigkeiten entstehen und desto weitreichender sind die Folgen von schlechter Planung und Unklarheiten.

Gleichzeitig wächst der Koordinationsaufwand mit der Anzahl der Stakeholder.

• Unterschiedliche Perspektiven,

• unterschiedliche Verantwortlichkeiten,

• unterschiedliche Erwartungen müssen aufeinander abgestimmt werden

… und das funktioniert nur, wenn ein gemeinsam erarbeiteter und vereinbarter Ansatz als verbindliche Grundlage dient.

Ein solider Plan für große ITEMs ist deshalb kein administrativer Overhead, sondern die Voraussetzung, damit alle überhaupt an einem Strang ziehen können.

Große ITEMs bringen nicht nur mehr Komplexität in der Ausführung, sondern auch in der Planung selbst.

Es gibt mehr alternative Ansätze abzuwägen und mehr potenzielle Fallstricke zu identifizieren und anzugehen.

Das macht die Planung anspruchsvoll.

Aber vor diesem Aufwand zurückzuschrecken wäre ein schwerwiegender Fehler.

Wer die Planung weglässt oder abkürzt, spart an der falschen Stelle.

Die Konsequenzen tauchen später auf, mit deutlich größerem Aufwand und im schlimmsten Fall mit fatalen Folgen.

Der Plan beschreibt nicht die Tätigkeiten sondern die Etappenziele.

Ein Plan ist kein Drehbuch, das Schritt für Schritt genau vorschreibt, wie vorzugehen ist.

Stattdessen dokumentiert er Meilensteine und Zwischenergebnisse — das Was und das Wann, nicht das Wie.

Die konkrete Vorgehensweise zur Erreichung dieser Ziele wird erst im Verlauf der Arbeit selbst definiert, da sie direkt davon abhängt, wie sich die Realität entfaltet: unvorhergesehene Hindernisse, neue Erkenntnisse und veränderte Bedingungen fließen ein.

Diese Unterscheidung ist entscheidend:

• Termine und Ziele bleiben so stabil wie möglich! Sie sind die festen Punkte, an denen sich alle Beteiligten orientieren und auf die alle Anstrengungen ausgerichtet sind.

• Die Vorgehensweise hingegen wird bewusst flexibel gehalten. Sie passt sich der Realität an, reagiert auf den tatsächlichen Verlauf der Arbeit und gibt den Ausführenden den nötigen Spielraum, die situativ beste Lösung zu finden.

Wer plant, denkt — wer denkt, führt.

Erst durch die Planung verstehen wir die Zusammenhänge, identifizieren Abhängigkeiten und definieren die eigentlichen Ziele.

Er ist der Kompass, den wir uns bauen, bevor der erste Schritt gegangen wird.

Damit das gut funktioniert hier nochmal die Regeln:

• Plane, um Erkenntnisse zu gewinnen: Nutze den Planungsprozess, um Klarheit über Ziele und Ressourcen zu erlangen. Durchdenken der Materie erzeugt das vollständige Bild und schafft die Grundlage, um während der Ausführung richtig auf die sich verändernde Realität zu reagieren.

• Schaffe die Voraussetzungen: Beginne erst, wenn die durch den Plan identifizierten, notwendigen Grundlagen geschaffen sind.

• Halte die Richtung: Nutze den Plan als Orientierung für das Team, nicht als starre Einschränkung des Denkens.

• Vertraue den Handelnden: Lass die Akteure den Weg im Angesicht der Realität gestalten, aber immer messbar an den Zielen, die der Plan vorgibt.

• Bewertet die Lage: Vergleiche den Fortschritt kontinuierlich mit der Realität, um den Plan als lebendiges Steuerungsinstrument zu erhalten, anstatt an veralteten Annahmen und Zielen festzuhalten.

Was bedeutet das jetzt also für unsere ITEMs und den Granatapfelbaum?

Jedes ITEM braucht seinen Meilensteinplan

Wie ich im letzten Artikel beschrieben habe, müssen wir für jedes ITEM am Anfang das Ziel klar definieren, damit der Sinn des Ganzen im Eifer des Gefechts nicht verloren geht.

Mit Kenntnis des Ziels ist es möglich, sinnvolle Zwischenziele sowie die erforderlichen Voraussetzungen und Ressourcen zu planen — und diese dann natürlich auch bereitzustellen.

Dazu definieren wir Etappen, wie die Reifestufen des Granatapfels, die Meilensteine oder Quality Gates, zu denen wir die dazu passenden Reifekriterien festlegen.

Jeder ITEM-Typ hat dabei eigenen, charakteristische Merkmale.

Projekte

Beim Projekt sind Fristen und Projektziele von Anfang an bekannt.

Der Projektplan ist ja ein Bestandteil der klassischen Projektmanagement-Methode.

Hier gibt es schon Quality Gates und Meilensteine; Ressourcen und Abhängigkeiten werden ebenfalls geplant.

In dieser Hinsicht müssen wir also nichts Neues erfinden.

Was jedoch nicht selbstverständlich ist, ist ein Fokus auf Zwischenziele statt auf Aktivitäten.

Wir kennen sie alle — die Projekt-Gantt-Tapeten, in denen jede einzelne Aktivität akribisch Jahre im Voraus abgebildet ist.

Diese Detailbesessenheit werfen wir über Bord.

Wir konzentrieren uns auf das Wesentliche.

An dieser Stelle möchte ich Moltkes Zitat gerne aufrichtig adaptieren:

Technologieentwicklung

Bei der Technologieentwicklung sind Meilensteine weit weniger konkret und fest.

Zeitrahmen sind im Vorhinein deutlich schwerer planbar, und Etappenziele ändern sich ebenfalls, wenn das Verständnis der Technologie im Laufe der Arbeit wächst.

Das ist jedoch kein Grund, nicht zu planen.

Es bedeutet lediglich, dass eine deutlich größere Volatilität bei der Zielerreichung explizit eingeräumt wird.

Während das Aufgeben oder Nichterreichen von Projektzielen in einem Projekt keine geplante Alternative darstellt, muss dies in der Technologieentwicklung einkalkuliert werden.

Genau diese Unsicherheiten müssen bei der Planung eingeschätzt und bei der Einbettung der Aktivität in den Gesamtkontext berücksichtigt werden.

Technologien dürfen erst dann für eine Produktentwicklung eingeplant werden, wenn der erfolgreiche Abschluss der Technologieentwicklung verlässlich absehbar ist.

Darum darf es auch zwischen einer Technologieentwicklung und einen Produktprojekt keine lückenlose bzw. alternativelose Anschlussplanung geben.

Features und Funktionen

Features und Funktionen sind von ihrer Natur her kleinere Projekte.

Zwar muss auch hier geplant werden, eine Möglichkeit ist jedoch, dies direkt in Form von Sprint-Planungen zu tun.

Zumindest sollten jedoch die DCVI-Meilensteine geplant sein: die Abfolge von Definition, Erstellung, Validierung und Implementierung.

Kundensegmente

Genau wie Produktentwicklungen hat auch die Erschließung von Kunden- und Marktsegmenten Projektcharakter.

Auch hier können Quality Gates und Meilensteine geplant werden, und Ressourcen sowie Voraussetzungen müssen bereitgestellt werden.

Allerdings kann das Ergebnis hier auch negativ ausfallen.

Der eigentliche Zweck eines solchen Projekts ist es, die wirtschaftliche Tragfähigkeit zu ermitteln, daher muss die Möglichkeit eines negativen Ergebnisses in der Planung berücksichtigt werden.

Problemlösung

Der Problemlösungsprozess ist klar planbar und beschreibbar.

Die Volatilität liegt hier jedoch in der zeitlichen Dimension.

Wenn das Problem ernst ist, ist das Nichtlösen keine Option — ähnlich wie bei einem Projekt, aber anders als bei der Technologieentwicklung.

Der Zeitrahmen ist jedoch oft schwer vorherzusagen.

Der erste Schritt der Arbeit besteht darin, das Problem zu verstehen, und bevor das geschehen ist, ist eine theoretische Planung schwierig.

Das zwingt den Planungsprozess am Beginn in eine inkrementelle Vorgehensweise, die erst im späteren Verlaufe terminliche Stabilität gewinnt.

Die Meilensteine können aber geplant werden. Typische Meilensteine sind hier:

• Problembeschreibung

• Ursachenanalyse

• Maßnahmenentwicklung

• Wirksamkeitsnachweis

• Implementierung

Prozessentwicklung

Bei der Prozessentwicklung ist der Ansatz identisch mit dem bei Projekten.

In den meisten Fällen werden Prozessentwicklungen in Projektform gegossen — der Projektansatz gilt also vollständig.

Es gibt aber auch Prozessentwicklungen, die keine offiziellen Projekte sind.

Mitarbeitende arbeiten parallel zu ihren eigentlichen Aufgaben an einem Prozess, es gibt keine formale Projektorganisation und keine formal definierten Ziele.

Ich finde das zwar nicht gut, aber wenn man das schon macht, dann sollte man wenigstens einen Plan haben.

Mitarbeiterentwicklung

Mitarbeiterentwicklung ist größtenteils nicht in Projektform organisiert, sondern Bestandteil des operativen Tagesgeschäfts.

Dennoch ist auch hier Planung erforderlich.

Der Fokus liegt auf den nächsten Zwischenzielen, die innerhalb eines Quartals oder eines Jahres erreicht werden sollen.

Das finale Endziel ist hier meist unbekannt oder in planerischer Hinsicht so volatil, dass eine formale Langfristplanung keinen Sinn ergibt.

Es gibt jedoch Ausnahmen.

Wenn beispielsweise ein bestimmter Mitarbeitender auf eine klar definierte Rolle vorbereitet wird, kann auch hier ein mehrjähriger Plan mit festen Meilensteinen aufgestellt werden.

Die Planungsmethodik gibt uns die Freiheit, für jeden Einzelfall den sinnvollsten Ansatz zu wählen.

Gar keinen Ansatz zu wählen ist keine Option.

Das war heute mal ein wirklich langer Artikel.

Fehlt ihnen trotzdem etwas? Dann schreiben sie es am besten in Substack in den Kommentar, schreiben sie mir eine Nachricht oder lassen sie uns chatten.

Leave a comment

Im nächsten Artikel werde ich wieder ins operative Detail gehen und anhand meiner Datenbank erklären, wie es ganz konkrete ablaufen kann.

Den Arikel finden sie im englischen Teil des Newsletters.

Danach gehen wir dann auf Drum Beat Ebene, bei der wir darüber reden, wie das Erreichen der Quality Gates und Meilensteine sichergestellt wird.

Also abonnieren sie bitte meinen Podcast, damit sie nichts verpassen.

Subscribe now

Wenn ihnen mein Podcast gefällt, dann empfehlen sie ihn doch bitte weiter.

Share

Share Uwe Mierisch

The big picture across all work items matters.

It provides orientation, enables prioritization, and reveals interdependencies.

In the last article, I described how exactly this can be organized. (In detail)

Today I go one level deeper because:

Both must be understood, mastered, and consistently applied.

So: let’s take a look inside the ITEMs today.

Like a pomegranate, work ITEMs pass through characteristic development phases in which they ripen and gradually form their final characteristics.

Unlike the pomegranate, however, this does not happen automatically through nature — it must be consciously managed.

This brings us to a highly controversial topic: project planning.

Some take planning to excess; others reject it entirely as unnecessary bureaucracy.

So we need to ask: does either side have a point, or does the truth lie somewhere else entirely?

To plan or not to plan — that is the question.

Helmuth von Moltke is quoted in the book “Moltkes Military Works”:

(Source: Helmuth von Moltke: Moltke’s Military Works: II. Activity as Chief of the General Staff of the Army in Peacetime. Second Part. Berlin: Ernst Siegfried Mittler und Sohn, 1900, p. 291 — Essay from 1871: “On Strategy”.)

I will use this quote from the Prussian Field Marshal and Chief of the Great General Staff as the starting point for this article.

I will examine whether project plans are necessary and, if so, how they must be designed to shed their bad reputation.

So let’s take a closer look at what Moltke has to say about operational planning and what we can learn from it.

Those who don’t plan lack the foundation to act.

Even though one might initially interpret it that way, Moltke’s guiding principle is not a rejection of planning.

The core of his doctrine states that planning is indispensable for bringing the army into an advantageous starting position, but can never determine the entire campaign.

He distinguishes two phases:

• Before the start of the war (Deployment)

• After the first shot has been fired. (Objective-based Tactics)

The Deployment

The planning before the start of an operation he calls the “deployment.” (Aufmarsch)

It is the only element of planning and execution that allows for precise, almost mathematical preparation.

In contrast to later combat, it is purely administrativ and logistically controllable.

In modern words: Planning provides the understanding of the perfect execution approach, taking into account all known and fixed constraints, and enables the preparation of all controllable preconditions in order to maximize the likelihood of that plan becoming reality.

He justifies the necessity of a precisely planned deployment as follows:

Irreversibility of errors.

Since the enemy restricts one’s capacity to act after the first contact, the initial positioning must be perfect.

Errors in the deployment of the army are barely correctable over the entire course of the campaign.

Logistics is the central element of warfare. All personell and equipment has to be available at the right place at the right time.

Therefore the timing of the operation must be precisely planned to be able to adhere to it later as closely as possible.

In this regard, mistakes are not correctable. Once the time has passed, resources can no longer be repositioned after the fact.

Impossibility of improvisation

According to Moltke, the deployment of armies of millions of soldiers and their supply cannot be improvised.

Improvisation requires quick decision-making under pressure, with limited information and time. The more complex a situation is, the more variables, dependencies and potential consequences there are to consider simultaneously.

At a certain level of complexity, the human mind simply can no longer process all relevant factors fast enough to improvise effectively. Decisions become guesswork rather than informed choices, and the risk of cascading errors increases dramatically.

Additionally, in complex operations there are often many interdependent actors and resources. An improvised change in one area can have unintended ripple effects across the entire system, which are nearly impossible to anticipate and control in the moment.

That is why complexity must be reduced through planning and perfect preparation to such a degree that reacting to the inevitable volatility during execution does not exceed that limit.

Planning as an Interdisciplinary Challenge

Moltke did not see planning as a purely military silo.

For him, it was an interdisciplinary task that had to integrate economic, technological, and social factors.

The indispensability of this comprehensive planning is grounded in the recognition that modern war draws on all the resources of a society.

I find this remarkable, as it displays already the basic principles of systems thinking.

Objective-based Tactics (Auftragstaktik)

Moltke is regarded as the inventor of “Objective-based Tactics” (Auftragstaktik).

For him, the essential thing was that superiors clearly articulate the goal and intent, while the concrete execution should be decided where the situation is actually visible and tangible: on the battle ground.

Moltke recognized that plans need to be adjusted the moment reality sets in.

Therefore, he considered rigid chains of command an obstacle and instead relied on independently thinking, responsible subordinate commanders who acted in the spirit of the overarching intent.

But this does not mean there are no orders at all.

In a service regulation from 1888, he wrote:

“The order must contain everything — but only what — the subordinate cannot determine independently to achieve a given purpose.”

For him, Auftragstaktik did not mean chaos, but a clear, shared orientation:

• The commanding officer’s intent forms the fixed point around which every initiative aligns.

• By consistently decentralizing decisions, Moltke created a command culture that was faster, more adaptive, and more effective than the strictly hierarchical models of his time.

My Interpretation — No Plan Is Bad, Too Much Plan Is Also Bad.

Enough looking at the insights of the old Prussian.

Let’s now examine what ITEM planning should look like against this backdrop and based on my own experience.

Planning Is Preparation

To this end, all known facts are analyzed, likely developments are anticipated, and meaningful scenarios are played through.

This also includes the application of all experiences and lessons learned from previous activities, which are preserved in planning templates and project management databases.

The result is the theoretically best approach, documented in time-scheduled milestone plans and discussed with all stakeholders.

It is important, that prerequisites and resources required to implement this plan are identified, and their provision is organized.

The plan must provide orientation and clarify responsibilities.

The Larger the ITEM, the More Planning Is Required

A small, short-term ITEM involving a handful of people forgives planning errors — you correct, adjust, and move on.

But the larger and more long-term an ITEM is, the more people are involved, the more dependencies arise, and the more far-reaching the consequences of poor planning or ambiguity become.

At the same time, the coordination effort grows with the number of stakeholders.

• Different perspectives,

• different responsibilities,

• different expectations must be aligned

… and this only works when a jointly developed and agreed approach serves as a binding foundation.

A solid plan for large ITEMs is therefore not administrative overhead, but the prerequisite for everyone to pull together in the first place.

Large ITEMs bring not only more complexity in execution, but also in planning itself.

There are more alternative approaches to weigh and more potential pitfalls to identify and address.

This makes planning demanding.

But, shying away from this effort would be a serious mistake.

Those who rush or shortcut planning are saving in the wrong place.

The consequences emerge later, with significantly greater effort and, in the worst case, with fatal outcomes.

The Plan Consists Not of Commands, but of Assignments

A plan is not a script that prescribes step by step exactly how to proceed.

Instead, it documents milestones and intermediate results — the what and the when, not the how.

The concrete approach to achieving these goals is only defined in the course of the work itself, as it depends directly on how reality unfolds: unforeseen obstacles, new insights, and changing conditions.

This distinction is critical:

• Tasks and goals remain as stable as possible — they are the fixed point around which all stakeholders orient and toward which all efforts are directed.

• The approach, on the other hand, is deliberately kept flexible. It adapts to realities, responds to the actual course of work, and gives those executing it the necessary room to find the best situational solution.

Those who plan, think — those who think, lead.

It is only through planning that we understand the connections, identify dependencies, and define the true goals.

It is the compass we build for ourselves before the first step is taken.

The Rules:

What does this mean for our ITEMs and the pomegranate tree?

Every ITEM Needs Its Milestone Plan

As I described in the last article, we must clearly define the goal for every ITEM right from the start — so that the purpose of the whole thing doesn’t get lost in the heat of the moment.

With knowledge of the goal, it is possible to plan meaningful intermediate goals and the required prerequisites and resources — and then of course to provide them.

Each ITEM type has characteristic traits.

Projects

In projects, deadlines and project goals are known from the outset.

The project plan is a component of the classic project management method.

Here there are quality gates and milestones; resources and dependencies are also planned.

In this regard, we don’t need to invent anything new.

What is not a given, however, is a focus on assignments rather than activities.

We all know them — the project Gantt wallpapers in which every single activity is meticulously mapped out years in advance.

We throw this obsession with detail overboard.

We focus on the essential information.

I would like at this point to genuinely adapt Moltke’s quote:

Technology Development

In technology development, milestones are far less concrete and fixed.

Timeframes are much harder to plan in advance, and tasks also change as understanding grows during the work.

This is no reason not to plan, however.

It simply means that significantly greater volatility regarding goal achievement is explicitly acknowledged.

While abandoning or not achieving project goals is not a planned alternative in a project, it must be taken into account in technology development.

Precisely these uncertainties must be estimated during planning and considered when embedding the activity in the overall context.

Technologies may only be scheduled for a product development when the successful completion of the technology development is reliably foreseeable.

Features and Functions

Features and functions are by nature smaller-scale projects.

While an approach must be planned here as well, one option is to do this directly in the form of sprint planning.

At a minimum, however, the DCVI milestones should be planned: the sequence of Definition, Creation, Validation, and Implementation.

Customer Segments

Just like product developments, opening up customer and market segments has project characteristics.

Here too, quality gates and milestones can be planned, and resources and prerequisites must be provided.

However, the outcome here may also be negative.

The very purpose of such a project is to determine viability, so the possibility of a negative outcome must be accounted for in planning.

Problem Solving

The problem-solving process is clearly plannable and describable.

However, the volatility here lies in the time dimension.

If the problem is serious, not solving it is not an option — similar to a project but unlike technology development.

The timeline, however, is often difficult to predict.

The first step of the work is to understand the problem, and before that has happened, even theoretical planning is difficult.

Plans are created for problems too, and the planned resources are organized — but here flexibility extends not just to defining the concrete approach: tasks and timeframes must be continuously adjusted as understanding grows.

Process Development

In process development, the approach is identical to projects.

In most cases, process developments are cast in project form — so the project approach applies completely.

But there are also process developments that are not official projects.

Employees work on the topic in parallel alongside their actual responsibilities, there is no formal project organization and no formal goals.

Even so, there should be a plan, as I described at the outset.

Employee Development

Employee development is largely not organized in project form, but is instead a component of day-to-day operations.

That said, planning is still required.

The tasks to be planned within employee development are typically intermediate goals scheduled in calendar increments.

The focus is placed on the next intermediate goals to be reached within a quarter or a year.

The end goal is usually unknown here, or so volatile in planning terms that formal long-term planning makes no sense.

There are exceptions, however.

If, for example, a specific employee is being prepared for a clearly defined role, a plan spanning several years with fixed milestones can also be put in place.

The planning methodology gives us the freedom to choose the most sensible approach for each individual case.

Choosing no approach at all is not an option.

Conclusion

That was quite a long article today.

Is something still missing for you? Then write it in the comments, sent me a message or let’s chat on substack.

Leave a comment

In the next article I will go into operative detail again and explain, using my database, how everything can work in very concrete terms.

After that we’ll move to the drum beat level, where we’ll discuss how the achievement of quality gates and milestones is ensured.

If you dont want to miss it, please subscribe to the newsletter.

Subscribe now

If you found this article helpful, don’t forget to share it with others who might enjoy it too!

Share

And if you like my newsletter, I would be grateful if you would share it as well.

Share Uwe Mierisch

In my article “Managing Priorities in Day-to-Day Operation” I described the fundamental concept of how better control of daily operations can be achieved with and without AI.

This raises the question of how exactly this can be put into practice.

For large companies, it will be necessary to use professional software solutions for this purpose — ones that can handle large amounts of data and comes with professional analytics and user interfaces.

For small businesses, small teams, or personal use, simple tools can do the job — and I'm using one here as an example.

In the following articles, I will explain the principle using a SeaTable Base that I also use myself.

In many use cases, it is more than sufficient — and it gives me the opportunity to demonstrate the operational workflow in practice.

You can order this Base from me at the end of the article. If you’d like, I’ll send it to you by email.

Of course, you can also recreate this structure in other spreadsheet programs, software platforms, or project management tools.

For any questions, you can reach me via direct message.

I would like us to develop this database together, so please write in the comments which improvements you would like to see or have already implemented yourself.

Leave a comment

It would be nice to build a community here that helps each other.

So let’s start with the first worksheet, the actual ITEM list.

Read more

Erst erzählt er was von DCVI und Super Sprints, dann noch Drum Beat und NewPDP und jetzt kommt er mit einem Granatapfelbaum daher und will das ganze Tagesgeschäft umkrempeln. Das wird immer verrückter.

Keine Angst, ich bin nicht verrückt und ich werde das alles auch nicht komplizierter machen, als es ist. Ganz im Gegenteil, ich will versuchen einen Weg aufzuzeigen, die Komplexität im Tagesgeschäft besser in den Griff zu bekommen und damit auch den Projekten mehr Raum zu geben.

Aber dafür werde ich doch noch einen neuen Begriff einführen:

Das Gleichnis mit einem Granatapfelbaum möchte ich machen, weil es nach meiner Meinung das Konzept besser verständlich macht. Es wird uns die nächsten Artikel begleiten. Bitte haben sie etwas Geduld mit mir, am Ende der Serie wird sich das komplette Bild zusammenfügt.

Stellen sie sich jetzt einmal vor, dass alles, was sie auf dem Schreibtisch haben einem Granatapfel an einem Grantapfelstrauch entspricht.

Es geht darum den Überblick zu bekommen.

Ich will die Idee mal ganz kurz und knackig auf einen Punkt bringen:

Was haben wird davon?

Nun es sind zwei Ergebnisse, die ich erreichen will:

1. Wir bekommen eine höhere Transparenz, können Muster erkennen und unser Handeln kontinuierlich verbessern.

2. Wir bauen eine Datenbank auf, auf deren Basis wir KI einsetzten können. Sie wird uns helfen, aus der wachsenden Menge an Erfahrungen zu lernen und in der jeweiligen Situation die richtige Information verfügbar zu haben und schlaue Vorgehensweisen zu finden.

Also lass uns mal schauen, wie das aussehen kann.

Das wahre Leben ist nicht schwarz/weiß, es hat viele Farben.

Klassisches Projektmanagement, Agiles Projektmanagement, Hybrides Projektmanagement. Ich belausche häufig die Diskussion, welcher Methode die Zukunft gehört und welche zum Sterben verurteilt ist.

Ich bin der Meinung, so darf man nicht argumentieren, denn das wahre Leben lässt sich nicht in Schubladen pressen, das ist ein Fakt.

Ich konnte über viele Jahre beobachten, dass die eine wahre Lehre nicht praxisgerecht ist, denn es gibt immer Sachverhalten, die da einfach nicht reinpassen. Das zu ignorieren ist aber keine Lösung, denn davon gehen die Probleme nicht weg.

Also lassen sie uns doch heute mal versuchen ein Modell zu finden, in dem alles, was im wahren Leben wirklich auftritt, seinen Platz findet.

Um auf das Granatapfelbaum-Modell zu verweisen, ich rede über die Granatäpfel an dem Baum. Es gibt viele von ihnen an einem Baum. Sie sind unterschiedlich groß und unterschiedlich reif, genauso wie die ITEMs auf ihrer Agenda.

Lassen sie uns mal anschauen, was alles so ein “Granatapfel” sein kann.

Projekte

Im Grunde ist ein Projekt eine detailliert geplante Veränderung, die nach bekannten Regeln durchgeführt wird.

Das Ergebnis eines Projektes kann in unterschiedlichsten Bereichen zu Hause sein.

Es kann ein neues oder verändertes Produkt sein, ein Prozess, eine Organisation, eine Infrastruktur oder noch vieles anderes. Vielfältige Veränderungsbedarfe können mit den Methoden des Projektmanagements umgesetzt werden.

Projekte sind üblicherweise große Veränderungsvorhaben, die langfristig angelegt sind und signifikanten Personaleinsatz und Investitionen erfordern.

Features, Funktionen, Eigenschaften

Genauso wie bei einem Projekt gibt es auch hier einen definierten Beginn, ein definiertes Ende und ein definiertes Ergebnis.

Für diese Veränderungen gibt es unterschiedlichste Change Management Methoden, es können z.B. agile Sprints oder systemisch gesteuerte Workflows sein.

Gemeinsam ist allen dieser Methoden die inkrementelle Vorgehensweise, die ein schrittweise Veränderung bewirkt, bei der jeder einzelne Schritt zu einem auslieferfähigen Produkt führt.

Technologien

Am Anfang steht eine Idee, die wird dann durch Forschung konkretisiert und inhaltlich durchdrungen, um anschließend im Rahmen einer Produktentwicklung in ein kundenfähiges Produkt einzufließen.

Dieser Verlauf ist weder konkret planbar, noch ist das Ergebnis vorhersagbar. Es gibt Erwartungen, aber keine Sicherheit. Trotzdem ist es notwendig diese Entwicklung zu durchschreiten, um zum richtigen Zeitpunkt die Technologie ausreichend verstanden zu haben, um sie in eine Produktentwicklung mit fixem Zeitplan und Ergebnis einplanen zu können.

Auch hier gibt es Pläne die abgearbeitet und Investitionen, die getätigt werden müssen, nur ist das Ergebnis halt über lange Zeit offen.

Dieser Sachverhalt stellt eine wichtige Säule im NewPDP dar, der ich noch weitere Artikel widmen werde.

Kundenapplikationen / Geschäftspotentiale

Sie können neu sein oder Veränderungen von bekannten Kundenbedarfe. Sie tauchen überraschend auf, werden durch systematische Analysen erkannt oder entwickeln sich in unterschiedliche Richtungen weiter.

Um ein Produkt weiterzuentwickeln, muss der Kundenbedarf bekannt sein und es muss auch verstanden sein, welche wirtschaftlichen Potentiale der Bedarf beinhaltet. Sind die Kunden bereit dafür Geld auszugeben und wenn ja, wie viel?

Um diese Information korrekt verfügbar zu haben, muss in der Organisation ein Aufwand betrieben werden, sprich Ressourcen (Zeit, Kapa, Geld) sind notwendig und damit sind es ITEMs auf der Arbeitsliste.

Probleme

Auch Problem haben die Eigenart, dass zum Zeitpunkt ihres Auftretens die Zeit bis zur Lösung nicht konkret planbar ist.

Der Zielzustand ist klar: Das Problem ist gelöst. Wie genau das aussieht ist am Anfang noch nicht bekannt. Wenn man das wüsste, hätte man das Auftreten des Problems schon von Anfang an verhindern können.

Ich möchte nicht missverstanden werden, Problemlösung muss einer methodischen Vorgehensweise folgen und diese ist bekannt.

Nur die Zeit die für die Ursachenanalyse, die Definition von Maßnahmen, die Validierung der Wirksamkeit der Maßnahme und die Implementierung der Maßnahme vergeht, ist abhängig vom Erkenntnisgewinn und damit nicht von Anfang an sicher vorhersehbar.

Also, auch wenn hier projekthaft gearbeitet wird, erfüllt es nicht die von mir eingangs beschrieben Definition eines Projektes. Also bleiben wir mal beim Problemlösen.

Prozesse

Auch diese müssen erstellt, angepasst und weiterentwickelt werden.

Teilweise kann das in Projektform geschehen. Teilweise ist es aber durchaus sinnvoll einfach nach Bedarf oder Mehrwert zu entscheiden, welche Aktivitäten als nächstes unternommen werden, ohne eine festgelegte Planung und ein definiertes Ergebnis zu kennen.

Organisationen, die das Vernachlässigen, bekommen über kurz oder lang existenzielle Probleme. Darum ist es notwendig die erforderlichen Aufwände rechtzeitig zu tätigen.

Mitarbeiter

• Ist es der Mitarbeiter selbst, der Zeit in seine Weiterentwicklung investiert,

• ist es das Team in Form von Teamentwicklung oder

• die Führungskraft in Form von Coaching und Mitarbeiterführung.

Es benötigt Zeit.

… und da gibt es noch mehr

Mit dieser Aufzählung will ich es hier heute jetzt bewenden lassen, ich denke sie verstehen das Konzept.

Alle diese Kategorien fasse ich unter dem Begriff ITEM zusammen.

Schreiben sie mir bitte im Kommentar, welche Kategorien ihn noch erwähnenswert erscheinen, die dieses Kriterium erfüllen und die ich nicht genannt habe.

Leave a comment

ITEM Management ist erweitertes Multiprojektmanagement

Wenn ich sie frage, wieviel Zeit und wieviel Geld sie in den letzten Wochen in jedes dieser ITEMs investiert haben. Wissen sie die Antwort?

Wenn ich sie frage, wieviel Zeit und wieviel Geld ihre Organisationseinheit in den letzten Wochen in jedes dieser ITEMs investiert hat. Wissen sie die Antwort?

Ich sage ihnen ganz ehrlich, ich konnte diese Frage viele Jahre nicht beantworten und das war ein Grund für Stress und Performancedefizite.

Es führte dazu, dass ich mich fremdbestimmt gefühlt habe und immer wieder realisieren musste, dass wichtige Themen liegengeblieben sind.

Viele Projekte brauchen Programmmanagement

Meine Welt als Produktentwickler bestand aus Entwicklungsprojekten und Serienbetreuungsaktiviäten.

Diese beiden Kategorien hatten Struktur. Projekte haben einen Projektplan und Entscheidungspunkte. Genauso ist es bei Serienbetreuungsaktivitäten.

Eigentlich ist es ja naheliegend einen Überblick über alle Projekte zu haben, um Ressourcen abschätzen, Querbeeinflussungen erkennen und proaktiv damit umgehen zu können.

Und dafür gibt es auch eine bekannte Methode, das Projekt-Programmmanagement, welches von den einschlägigen Projektorganisationen beschrieben wird.

Das ist zwar schon seit langem bekannt und die Notwendigkeit anerkannt und trotzdem gibt es in vielen Organisationen in dieser Beziehung Defizite, die behoben werden müssen.

Also packen wir es an und tun, was notwendig ist.

Wenn ich dieses Konzept zu Ende denke, dann kommt mir die Erkenntnis, dass es nicht ausreicht den Blick nur auf die Projekte zu lenken, denn die anderen ITEMs brauchen auch ihren Platz im Kalender der Organisation und in dem jedes einzelnen Mitarbeiters.

Wie man das konkret in der operativen Ausgestaltung machen kann, erkläre ich in einem eigenen Artikel.

Aber wir haben doch die Mitarbeiter für die Projekte freigestellte!

Gratulation, wenn ihnen das wirklich gelungen ist, dann haben diese Mitarbeiter eine kurze ITEM-Liste.

Das ist gut und erstrebenswert!

Aber darum dürfen wir die Leute, die nicht diesen Luxus genießen nicht aus dem Auge verlieren.

Und wenn wir auf die ganze Organisation schauen, dann füllt sich die ITEM Liste sehr schnell und es gibt immer Leute, die das alles im Auge behalten müssen und dafür sorgen, dass nicht gerade die wichtigen Sachen liegen bleiben oder Ergebnisse nicht verfügbar sind, wenn sie gebraucht werden!

Das Ziel ist nicht eine lange Liste zu haben und damit Bürokratie zu betreiben.

Das Ziel ist Transparenz zu erzeugen und durch kluge Steuerung die ITEMs in der Liste immer auf einen beherrschbaren Umfang zu reduzieren.

Daten sind der Treibstoff für Effizienz

Es gibt zahlreiche Ansätze, wie Projektmanagement durch den Einsatz von KI verbessert, Projektsteuerung vereinfacht, Projektabläufe stabilisiert und insgesamt die Geschwindigkeit gesteigert werden kann.

Bei all diesen Diskussionen habe ich immer wieder feststellen müssen, dass die Datenbasis für den Einsatz von KI nicht ausgereicht hat, um wirklich signifikante Verbesserungen zu erzielen.

Daraus habe ich die Schlussfolgerung gezogen, dass wir als erstes sofort mit dem Sammeln der Daten anfangen müssen.

Naja und wenn wir die Daten dann schon mal transparent haben, dann können wir ja schonmal anfangen sie zu nutzen, auch wenn die KI noch nicht zur vollen Performance fähig ist.

Bleiben Sie dran, es gibt noch eine Menge zu besprechen.

In den nächsten Artikeln spreche ich darüber, wie das genau operativ im realen Einsatz aussehen kann, indem ich ihnen meine Datenbank zeige.

Ich werde dann auch noch in tieferen Ebenen der Arbeit an den ITEMs einsteigen.

Also abonnieren Sie meinen Podcast, damit Sie nichts verpassen.

Subscribe now

Mich interessiert Ihre Meinung – schreiben Sie sie in den Kommentar, schicken Sie mir eine Nachricht oder lassen Sie uns auf Substack chatten.

Leave a comment

Wenn Ihnen mein Podcast gefällt, dann empfehlen Sie ihn doch bitte weiter.

Share Uwe Mierisch