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

Now what is this all about?

First there was talk of DCVI and Super Sprints, then Drum Beat and NewPDP and now he shows up with a pomegranate tree and wants to overhaul day-to-day operations entirely.

This is getting wilder by the minute.

Don’t worry. I haven’t lost my mind, and I have no intention of making things more complicated than they need to be.

Quite the opposite: I want to show you a way to better manage the complexity of everyday operations, and in doing so, create more space for the work that actually matters — your projects.

Paradoxically, simplifying requires one small addition, a new term: the ITEM.

I’d like to use the analogy of a pomegranate tree, because I believe it makes this concept easier to grasp. It will run through the next several articles. I ask for a little patience, with the hope that by the end of the series, the full picture comes together.

Imagine that everything sitting on your desk is like a pomegranate hanging on a tree.

The Idea in a Nutshell

Let me get straight to the point:

What do we gain from this? Two concrete outcomes:

1. We gain greater transparency, can recognize patterns, and continuously improve how we work and prioritize our resources and activities.

2. We build a database that allows us to leverage AI to navigate our growing pool of experience and identify smarter ways of working.

So let’s take a closer look at what this can look like.

Real Life Is Not Black and White. It Has Many Colors

• Classical project management.

• Agile project management.

• Hybrid project management.

I often find myself listening to debates about which methodology owns the future and which is destined to die out.

That framing is misguided. Real life cannot be neatly sorted into boxes, that’s simply a fact.

Over many decades, I’ve observed that no single true doctrine is practically workable, because there are always situations that simply don’t fit. Ignoring those situations is not a solution, the problems don’t disappear just because we look away.

So let’s try to build a model that accommodates everything that genuinely occurs in real organizational life.

To reference the pomegranate tree model: I’m talking about the pomegranates on the tree. There are many of them. They vary in size and ripeness, just as our work items do.

The pomegranate itself, however, is also a system in its own right and therefore offers a good analogy for the complete model. In the upcoming articles I will cut open the pomegranate, but for now let's stay with the fruit on the tree.

Let’s explore what can qualify as a “pomegranate.”

Projects

At its core, a project is a detailed, planned change executed according to established rules.

The outcome of a project can span many domains.

• a new or modified product,

• a process,

• an organization,

• or an infrastructure.

A wide range of change needs can be addressed through project management methods.

Projects are typically large-scale change initiatives: long-term in nature, requiring significant personnel and investment.

Features, Functions, and Product Properties

Like projects, Feature-, Function-, and Property Development have a defined start, end, and deliverable. Various methods apply: agile sprints, systemically controlled workflows, and others.

What all these methods share is an incremental approach: each step produces a shippable result ready for real-world use.

Unlike projects, the other methods are designed to be significantly shorter and less resource-intensive. While exceptions exist in practice, treating them separately is precisely what helps avoid scope creep and keeps them lean.

Technologies

It begins with an idea, which is then explored and refined through research, before eventually, if it makes it that far, being incorporated into a product development effort that can reach customers.

This journey cannot be precisely planned, nor can the outcome be predicted.

There are expectations, but no guarantees.

Nevertheless, it is essential to progress through this phase, so that at the right moment, the technology is sufficiently understood to be incorporated into a product development cycle with a fixed timeline and defined deliverable.

Here too, there are plans to be executed and investments to be made. But the outcome remains uncertain for a long time.

This is a critical pillar of the NewPDP framework, to which I will dedicate further articles.

Customer Applications / Market Opportunities

To advance any product, the organization must know what customers need and understand the commercial potential: Are customers willing to pay for it? If so, how much?

Generating this insight requires organizational effort. Resources in the form of time, capacity, and money.

In this context, customers can also be internal ones. Internally too, new requirements and business opportunities emerge that need time to mature.

Problems

Problems share a key characteristic: at the moment they arise, the time needed to resolve them cannot be predicted.

The target state is clear: “The problem is solved”, but the path to get there is not.

To be clear: problem-solving must follow a structured methodology, and that methodology is well known.

But the time required for

• root cause analysis,

• defining countermeasures,

• validating their effectiveness,

• and implementing them

depends on what is discovered along the way, and therefore cannot be reliably predicted upfront.

Even though the work is project-like in nature, it doesn’t meet the strict definition of a project I outlined earlier. So let’s call it what it is: problem-solving.

Processes

Some of this work can take the form of a project. But in many cases, it makes more sense to prioritize activities based on need or value without a fixed plan or predefined outcome.

Organizations that neglect this will face existential problems sooner or later.

The investment must be made at the right time.

People

Whether it’s:

• an individual investing time in their own development,

• a team working on cohesion and collaboration,

• or a manager focusing on coaching and leadership

it all takes time.

… And There Is More

I’ll stop the list here for now. I think you understand the concept.

I group all of these categories under the term ITEM.

Please share in the comments: which categories do you find missing?

Leave a comment

ITEM Management Is Extended Multi-Project Management

If I asked you how much time and money you personally invested in each of these ITEMs over the past few weeks. Would you know the answer?

If I asked how much time and money your team or department invested in each of these ITEMs. Would you know that answer?

I’ll be honest: for many years, I couldn’t answer those questions, and that was a source of both stress and performance gaps.

It left me feeling reactive rather than in control, and I regularly found myself realizing that important things had been left unattended, or that results weren’t available when they were needed.

Multiple Projects Require Program Management

My world as a product developer consisted of development projects and series support activities.

Both had structure: projects had project plans and decision gates; series support activities had their own cadence.

Maintaining an overview of all active projects seems obvious to estimate resource needs, spot interdependencies, and handle conflicts proactively.

This is exactly what project program management addresses, a well-established method described by leading project management bodies.

And yet, despite decades of awareness, many organizations still fall short here.

It's high time to close that gap.

When I take this idea to its logical conclusion, I realize that focusing only on projects isn’t enough.

The other ITEMs also need their place in the organization’s calendar, and in every individual’s.

How to implement this operationally is something I’ll explain in dedicated articles.

But Our Team Members Are Fully Dedicated to Projects!

Congratulations! If you’ve really achieved that, those team members have a short ITEM list. That’s great, and worth striving for.

But that shouldn’t cause us to lose sight of the people who don’t have that luxury.

And when we look at the organization as a whole, the ITEM list fills up fast, and there are always people who need to keep all of it in view, ensuring that nothing critical falls through the cracks and that results are available when they’re needed.

The goal is not to maintain a long list for the sake of bureaucracy.

The goal is to create transparency, and through smart management, continuously reduce the list of active ITEMs to a manageable scope.

Data Is the Fuel for Efficiency

There are countless approaches to improving project management, simplifying project control, stabilizing project workflows, and increasing overall speed through AI.

Yet in every one of these discussions, I kept running into the same obstacle: the data foundation was too weak for AI to deliver meaningful and helpful results.

That led me to a clear conclusion:

And once that data is transparent, we can begin using it right away even before AI is operating at full potential.

In the upcoming articles I will describe in detail how this can be implemented operationally.

To do so, I will use a sample database that I created specifically for this purpose and that you can get from me.

So subscribe to my newsletter to make sure you don't miss these articles.

Subscribe now

If you have any comments or feedback on this topic, please write them in the comments.

Leave a comment

or send me a direct message.

We can also chat about it.

I’m looking forward to hearing from you!

If you found this article helpful, don’t forget to share it with others who might enjoy it too!

Share

One trend is clear — and it’s irreversible.

If you’re expecting me to proclaim the end of humanity or prophesy the rise of artificial intelligence as our new ruler, I’m afraid you’ll be disappointed.

I genuinely believe — and I mean this seriously — that computers can, in the long run, be a gift to humanity. There may even be a chance they protect us from ourselves. Sounds naïve? Perhaps. But a little optimism never hurt any engineer.

And given everything happening in the world right now, we could certainly use some.

Unfortunately, that’s hope, not scientific insight.

I won’t attempt a prediction of that magnitude — I lack the data, the expertise, and, honestly, the kind of ultimate abstraction required for it. And I suspect I’m not alone in that.

What I can do is to examine a time horizon for which I have clear data and solid evidence. A horizon close enough to be concrete and far enough to be truly relevant.

Today, I want to talk about what this means in practice — for the product, for its development, and for everyone involved in it.

So let’s start with the trend itself.

Muscle and Mind

Muscles have been largely mechanized.

For as long as we’ve walked this planet, humans have tried to shape the physical world to our will.

We transport heavy loads. We generate heat, light, and motion. We protect ourselves from weather, natural force and from each other.

For millennia, we relied almost entirely on our bodies to do this. Our bodies provided the energy, the strength, and the intelligence needed to reshape the world, step by step, according to our wishes.

And then, in the blink of an eye on the timescale of human history, everything changed.

I find it fascinating every time I reflect on just how short that interval really is.

It’s been only about 300 years since we invented machines capable of taking over physical labor. Since then, they have steadily lifted the sweat from our brows and delivered enormous gains in efficiency.

And it’s been only about 50 years since we began using electronics and software to process information — helping our brains work more efficiently.

Or, alternatively, flooding them with more information than they can handle. I’ll just say: social media. (ok, that doesnt belong here, but I couldn't resist)

With that, I’ve essentially sketched the development path of the mechatronic products we’re here to discuss.

Initially, the focus of electronics in machines was on unlocking new use cases, using energy more efficiently, and simplifying how humans operate machines.

In my last article, I put forward a thesis that, at first glance, sounds provocative:

The requirements of a physical product are far less volatile than the software requirements.

Had I claimed that 250 years ago, I would have been laughed out of the room — rightly so. Back then, mechanics was the dynamic frontier.

That I can confidently argue the opposite today is a testament to how remarkably successful engineering has been. We’ve climbed high up the curve of mechanical innovation — so high that we’re beginning to see the ceiling.

We are approaching saturation — a point where more no longer means much more.

The pace is slowing — not because engineers have run out of ideas, but because they were so effective in the first place.

The physical world operates by natural laws — and those laws are largely understood. Thermodynamics sets a hard upper limit on motor efficiency. Material physics constrains how much load can be borne. The remaining room for improvement shrinks; gains become increasingly marginal.

Of course, open frontiers matter. The electrification of transport is a good example.

But even there, the requirements are broadly known, the physics understood, the development more gradual than revolutionary.

When it comes to logic —meaning what machines can think and decide — the picture looks entirely different. Here, we are still at the beginning.

The Hardware Is Learning to Think

With the arrival of microelectronics in machines, a new era began. Slowly at first — then with extraordinary momentum.

Suddenly, it became possible to combine sensors, actuators, and computing units in a system, orchestrated by software.

The machine acquired something like a nervous system.

I find the comparison with the human body genuinely helpful here.

The mechanical, hydraulic, pneumatic, and thermodynamic systems of a machine — these are its skeleton, muscles, and metabolic organs. They provide force, movement, and energy.

Sensors, cables, microelectronics, and software, on the other hand — these are the sensory organs, the nervous system, and the brain. They perceive, process, and trigger action.

The more of the latter enters a machine, the more it resembles the human body — and in many dimensions, even surpasses it.

But there is one fundamental difference from the biological model, and it’s highly relevant for developers:

The human body has one central control unit: the brain. One. Just one.

Highly complex machines — take my beloved trucks, or equally, passenger cars — operate with a decentralized network of many system and domain control units, connected through gateway controllers in a specific architecture.

This represents enormous complexity — and it demands a clear methodology from developers to fully grasp the system as a whole and systematically bring it to life.

That methodology is called Systems Engineering. Remember that term. It will be worth your while.

I’ll return to it repeatedly in the articles ahead and go deep into the subject matter.

Separating the Stable from the Fast-Moving

When physical development loses momentum while logical functions grow exponentially, one idea becomes obvious: why not systematically separate the two domains?

Keep the mechanical part stable. Evolve the software layer at high frequency. Both simultaneously, but independently.

This requires a centralized electronics architecture — and equally, a centralized software architecture.

And with that, the machine too finally gets a brain — just as we humans have.

For this to work, a fundamental structure is needed:

There must be a software layer that reliably handles the core functions of the physical and electronic hardware — something like the machine’s brainstem.

Above that sits an operating system that serves as a stable platform — a foundation onto which software applications can be docked, modified, and extended without touching the underlying hardware.

In the automotive industry, this new architecture has been given a name: Software Defined Vehicle.

Behind this term lies a far-reaching prediction: that the transport function will become secondary for customers in the future.

They want to work in the vehicle, be entertained, sleep — while their position on the map quietly changes.

The car will then be defined not by driving dynamics, efficiency, or safety, but by the software the customer consciously uses and experiences while driving.

Whether that comes to pass remains to be seen.

But the underlying trend is real — and far broader than the automotive industry.

The architecture of the machine continues to approach the architecture of the human body — and as we know, that’s an extraordinarily capable concept.

For developers, this means one thing concretely: welcome to the world of parallel processes.

The hybrid development process will continue to exist — as I outlined in my last article.

Alongside it, a purely agile development process will emerge — for the topmost product architecture layer: the Software Application Layer.

Both processes run simultaneously, overlap — and yet operate at completely different speeds, with different methods and different characteristics.

I frequently encounter the view that in the future, only the agile process will remain — that the classical development approach will simply die out like the dinosaurs.

I consider this a dangerous misconception — and I want to raise your awareness of it.

Ask yourself, deliberately, with every development initiative: What is this actually about?

Is the physical substance of the product evolving — or is this “only” about the application layer?

Those who can answer that question clearly gain immediate clarity about the right approach — and dissolve a great deal of apparent complexity in the process.

And Then the Machines Start Talking to Each Other

Before I close, I want to address one capability that has defined us as humans for millennia — and that machines are now beginning to acquire as well.

The ability to communicate with each other and to coordinate action accordingly.

That is precisely what “Industry 4.0” is about: the networking of machines through external computing resources.

Centralized storage and processors in data centers somewhere in the world, with which machines exchange information in real time via wireless connection over the air.

The machines are talking to each other. And they’re learning as they go.

And with that, we come full circle back to my opening premise.

Here, machines can do something we humans simply cannot: communicate with thousands of other machines in milliseconds, share data, synchronize decisions.

An advantage that becomes unbeatable as connectivity grows.

But — and this matters to me — these systems do not emerge on their own.

Many more years of human developers will be needed to design, implement, and make these architectures usable.

And I think you can sense that this is anything but trivial.

I look forward to exploring this together with you in the articles ahead.

I hope this article helps you place the developments of the past — and those still ahead of us — into a coherent framework.

With that understanding in hand, you can navigate the jungle of growing complexity and reach for the right toolbox in any situation.

Here are the key takeaways from the last few articles at a glance:

1. Some products are heavily physically driven — for them, the classical development process remains the right approach, even in the future.

2. The vast majority of products are mechatronic — they require a hybrid methodology.

3. To gain speed, the Software Application Layer will increasingly be decoupled and developed agile — independently of the rest of the product cycle.

4. Cross-device networking creates highly complex systems — for which Systems Engineering is not optional, but essential.

So — Do We Still Need Projects?

Projects will still exist in the future — but they will look very different from the ones we know today.

What lies ahead is a coexistence of hybrid and purely agile approaches, operating side by side.

• At different speeds,

• on different system levels,

• and with fundamentally different logic.

Navigating this environment is not simple. It requires clarity about what kind of development you’re actually doing at any given moment.

The complexity is real. But so is the opportunity — for those who understand the terrain.

Stay tuned — there’s a lot more to explore.

Subscribe now

If you have any comments or feedback on this topic, please write them in the comments.

Leave a comment

or send me a direct message.

We can also chat about it.

I’m looking forward to hearing from you!

If you found this article helpful, don’t forget to share it with others who might enjoy it too!

Share

And if my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch

It has always been the same sequence.

A big improvement of our trucks is needed and therefore a developement project is to be set up.

• Extensive discussions are held about which new functions are absolutely necessary to meet regulatory requirements,

• which additional features promise economic potential,

• what the budget allows for

• and what must be sadly left out.

Everyone agrees: For this expensive and high-stakes endeavor — with a hard legal deadline at the end — a classic project must be set up.

After long, tough negotiations, the decisions are made and a schedule is drawn up that often requires five to six years between the project decision and customer availability.

The project can begin.

But from the very start, time is insufficient.

So the schedule is compressed as much as possible, leaving at least some buffer before the legal deadline — because experience shows:

Projects are never finished on schedule.

Everyone wants hardware prototypes quickly, so parts design moves fast.

Prototype vehicles are built to develop the new product.

At enormous cost, the parts are manufactured and the first prototype vehicle is assembled.

One and a half to two years have passed.

And now comes the shocking realization:

The vehicle is not ready to drive.

Important software packages are not finished — or simply don’t work.

No software, no driveable vehicle — that is today’s reality.

There it stands in the workshop, the beautiful, expensive piece — failing to fulfill the purpose it was built for.

But no problem, people tell themselves.

Software development is agile!

It’s practically waiting for situations like this to show how brilliantly it handles them.

Dozens of software developers swarm around the vehicle with their laptops, flashing here, analyzing there.

After a few weeks, the prototype is running — and development can continue.

Let’s fast-forward:

We are now six months before the end of the project. Four years have passed, and testing is in full swing.

The hardware is working.

The last gap tolerances and manufacturing processes are being optimized, homologation tests are complete, and the paperwork is with the authorities. Everyone is waiting for the stamps.

Production is beeing prepared in a big scale.

Only the software is causing problems. The burn-down charts are showing the wrong trend.

Testing is still surfacing hundreds of new bugs every day, while only a few dozen are being resolved.

The fever curve is pointing sharply upward.

The vehicle cannot be handed over to customers in this state.

Many software components can no longer be touched because they have already been submitted for homologation.

Now there is sheer panic.

The board of management is being briefed regularly.

Sales, quality, and development sit together to decide which software bugs will be accepted — and which absolutely must still be resolved.

This is now the hour of heroes!

Suddenly everyone rallies together.

Suppliers suddenly find experts in other departments who can help.

Teams move into shared offices, and all other work is radically deprioritized.

And the miracle happens.

The series launch must be postponed by a few months — but somehow everyone can live with that.

Fortunately, we had a buffer built in, which we are now consuming.

Customers are understanding, suppliers deliver the old parts longer in higher quantities, and workshops flash the software to the latest version just before delivery.

When it’s all over and the new product receives positive reviews from customers and trade press, there is celebration.

A strong sense of team spirit has emerged.

The team and management are proud of how they once again got the crisis under control.

The celebration is brief. Because the next day, the next project calls — and it’s already on fire again.

Does this sound familiar?

I was tired of having to hold my breath with every project, wondering whether this time it would again be pulled back from the brink — or whether it would drive the company into ruin.

That’s why I took a closer look at the processes and developed a concept for how the development of a mechatronic product should ideally proceed.

What Is the Root of the Problem?

To understand why the development of mechatronic products keeps running into these difficulties, we need to understand the characteristics of hardware development and software development.

That is precisely why I covered both topics in the last two newsletter articles.

If you haven’t read them yet, I strongly recommend it — it is extremely helpful for understanding the problem presented today.

What Is a Mechatronic Product?

A mechatronic product is characterized by the fact that hardware and software are inseparably linked.

Only together can they deliver the customer value that defines the actual end product.

Looking back in time:

What is today a mechatronic product was often previously a purely mechanical one — using “mechanical” here as an umbrella term for mechanical, hydraulic, pneumatic, and electrical systems.

Vehicles, machines, and devices used to function without software.

With the advent of digitalization, however, functionality expanded so drastically that these products are simply unthinkable today without software.

Mechatronic products work with physical forces and simultaneously control their use with digitized systems.

Physical parameters such as force, displacement, speed, and position are captured by sensors — and can be made useful both for the core product function and for the user.

An example:

The purpose of a commercial vehicle is to transport payloads — which requires high physical forces.

At the same time, transport must be efficient and safe.

That’s why modern trucks have systems that optimize fuel consumption, monitor the environment, support drivers in critical situations, and help fleet owners optimize operations through connections to maintenance and fleet management systems.

What Does This Mean for the Project vs. Agile Question?

The challenge in developing mechatronic products is to bring together the characteristics of hardware development and software development within a common development process.

To make this more than just an empty statement, I want to describe what happens when you fail to do so.

Mechatronics Development as a Classic Project

If you organize the development of a mechatronic product using purely classical project management methods, exactly what I described at the beginning will happen — with absolute predictability.

The reason is simple: Software never works on the first place!

In hardware development, the greatest time demand comes from manufacturing — whether for prototypes or production tooling.

In software development, on the other hand, the greatest time consumption lies in finding and fixing bugs.

If you chain these two processes sequentially, the resulting schedules fall completely outside any economic reality.

The consequence:

Schedules are compressed — which is no longer classical project management, but an approach that has neither a name nor a reliable track record.

That it sometimes works through luck and skill is shown by practice.

Relying on that alone can put the livelihoods of many thousands of employees at risk — and is therefore not an approach I consider responsible.

Mechatronics Development as Purely Agile

Organizing mechatronics development in a purely agile manner fails on at least two fundamental characteristics of hardware development.

Hardware Can Only Be Developed Incrementally to a Limited Extent

Hardware must be safe throughout the entire life of the product.

It is neither possible nor sensible to deliver a half-finished product to customers.

A mechatronic product must be complete in terms of its hardware components to be customer-ready.

I deliberately wrote “limited incremental” — not “not incremental at all.”

There are, in fact, two meaningful approaches:

First, you can limit yourself to developing an MVP that doesn’t include all desirable features — which I actually strongly recommend.

However, the effect is not large enough to enable purely agile working.

Second, there is ongoing series support:

If you have a customer-ready product already you can improve it incrementally in specific functions.

This is common practice, and here I see no problem with an agile approach.

However, this also has inherent content limitations:

A fundamental renovation or new development of a product is not achievable this way.

Hardware Requires Long-Term Planning

Hardware development involves activities that require long-term preparation.

Whether it’s new manufacturing equipment, large tooling, validation boundary conditions, or safety verification — there are many aspects that must be planned well in advance.

Since hardware is an integral part of the mechatronic product, the development process must accommodate all these requirements.

So What Is the Solution?

The solution lies in hybrid project management — as I propose with the NewPDP.

I won’t be able to explain all the details in a single article — that is, after all, the job of the entire newsletter. So subscribe right away to make sure you don’t miss any issue.

Subscribe now

The hybrid approach consists of a four-level architecture:

Level 1 — Program Management: All planned product changes are coordinated and brought into a shared rhythm.

Level 2 — Project Management: The essential sequence from start to customer delivery with the key milestones. A dedicated project management organization ensures overview and flow.

Level 3 — The Drum Beat: A shared, short-cycle rhythm for detailed planning and results reviews. The Drum Beat is the medium through which interdisciplinary collaboration is organized and integrated by the team.

Level 4 — Execution: In weekly sprints, the team handles the tasks while management controls the resources.

This Process Applies to Everyone!

To close, a rule that in my experience is unfortunately too rarely made clear enough:

I have unfortunately experienced this repeatedly:

It is too tempting for hardware developers to focus on the classical project management methods they know.

And equally tempting for software developers to live exclusively by the agile elements.

That does not work!

The NewPDP only works when everyone consistently and collectively lives the entire process.

That means a change in mindset for both sides — but it is essential for success.

And with that, it becomes a leadership task!

Dear management:

This is where you are needed. This is your part in the transformation. You must understand the new process, demand it, and model it — otherwise, nothing will change.

That’s exactly what I’ll explore in the next articles — diving deeper into how the NewPDP works in practice across each of these four levels. Make sure to subscribe so you don’t miss it.

Subscribe now

If you have any comments or feedback on this topic, please write them in the comments.

Leave a comment

or send me a direct message.

We can also chat about it.

I’m looking forward to hearing from you!

If you found this article helpful, don’t forget to share it with others who might enjoy it too!

Share

And if my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch

Today I’m walking onto very thin ice!

It’s been almost 40 years since I wrote software for my thesis that could calculate energy consumption in a factory.

The topic of the thesis wasn’t the software itself, but improving the energy efficiency of the factory. The software was ‘just’ a tool, a means to achieve a result.

Using IT for such problems was considered highly innovative back then. And to be honest, I must admit that I had to request an extension on the submission deadline because I didn’t finish on time.

• Does anyone still remember Fortran?

• Does anyone still know what a punch tape looked like?

• How you searched the holes in the punch tape for errors when compilation failed and corrected them with a hand punch?

Later in my professional career, I had the pleasure of watching programmers desperately trying to get the software running at least halfway bug-free by the delivery deadline, with desperation and fear breathing down their necks. In this respect, things haven’t improved all that much apparently.

For me, it's a perspective from which it's relatively comfortable to talk smart.

I want to do that today.

I’m aware that software development today works fundamentally differently than it did back when object-oriented programming was still unknown.

For today’s software developers, this article offers the opportunity to read an outsider’s perspective. That might be an interesting viewpoint as well.

Please write to me whether you can relate to my view of things or whether I’m mistaken.

Leave a comment

This article focuses on pure software development; I’m setting aside the problems that arise when software and hardware must work together.

That will come in the next article, which will deal with mechatronics development.

What Actually Makes Software Development So Difficult?

I think it’s important to ask this question if you want to understand and improve the approach to software development.

It follows the old but still valid principle that you must first identify the problem and understand its causes before you can find an effective solution.

So let me write down some theses about these possible problems.

You Don’t Know Exactly What the Development Goal Is

With software, it’s often not exactly clear from the start what the software must be able to do in order to fulfill the purpose for which it’s being developed.

This is a multifaceted topic, but I believe my thesis is a pretty good example to demonstrate the problem.

At the beginning of my work, it seemed reasonable to assume that the greatest energy-saving potential would lie in the electrical drive energy of the work machines in production. That’s why I initially focused on how the efficiency of the machines could be calculated.

However, during the analysis it turned out that a major waste of energy occurred through the extraction of warm room air in the chip extraction systems at the machines. Heat was being blown into the environment in large quantities and had to be replaced by reheating.

This dramatically changed the focus for the software. Suddenly it was no longer just about analyzing electrical and mechanical efficiencies, but about calculating thermal energy, which had to be determined from temperature and pressure differences in the airflows of the chip extraction systems.

The phenomenon of volatile goal definition is frequently encountered in software development. I’ve observed this repeatedly.

While with hardware the requirements for the product are relatively stable, as I described in the last article, with software the focus and thus the requirements for the product often change during development.

You Don’t Know Exactly What’s Inside the Black Box

At its core, software development is still based on manipulating binary states.

However, since it’s impossible to solve complex problems at the level of logic gates, we work with pre-built software structures.

While languages like Fortran first reduced complexity through procedural commands and control structures (like IF-THEN or loops), today we use object-oriented programming and microservices.

These function as ‘black boxes’: complex logic is encapsulated in objects or modules, where only the interface – that is, the input and expected output – needs to be known, and of course, what the module can be used for.

This gain in efficiency and development speed has its price, however: you lose full transparency over the internal processes. When a system shows unexpected behavior, a systematic root cause analysis begins:

• Is there a GIGO effect (Garbage In, Garbage Out) because the input parameters weren’t validated?

• Does the chosen module even fulfill the functional requirements, or is there an architecture error?

• Is the abstraction reaching its limits, so that we need to implement a custom solution?

• Does the underlying mathematical or physical model even correspond to the reality of the problem?

So the work isn’t done just by selecting the right object or module and building it into the code, but errors that occur must be identified and eliminated until the software ‘runs satisfactorily.’

I deliberately don’t say error-free, because I’ve given up on that expectation.

In each use case, it must be carefully examined how much and which errors are unacceptable and must be fixed and what we can live with.

Milliseconds Decide Whether It Works or Not

In addition to purely logical complexity, modern systems have another insidious level of complexity: time.

Software today rarely acts in isolation. It runs in multicore environments or communicates asynchronously via APIs.

Errors here often arise from so-called race conditions.

When two processes access the same resource simultaneously, the result depends on who ‘arrives first.’

Such a system is no longer deterministic – that is, with exactly the same input, sometimes it delivers the right result and sometimes a completely wrong one, just because a background process shifted the timing by milliseconds.

These ‘Heisenbugs’ (errors that disappear when you try to investigate them) are extremely time-consuming to identify during development.

And there we have it, the complexity that makes classical project management impossible.

That’s Not All…

These three phenomena are not yet all the aspects that make software development difficult.

But this should be enough for today to convey an impression of the nature of modern software development.

I think it has become clear that there are completely different problem areas here than with hardware development, which I discussed in the last article.

If you want to point out additional aspects, please write them in the comments.

Leave a comment

What Is Easy About Software Development?

Now I also want to look at the flip side of the coin. There are also welcome aspects.

Software Development Works Incrementally

A special characteristic of software development is that individual functions or features can be developed and completed in isolation, without the entire product having to be completely finished.

This enables the software product or service to be worked on incrementally.

You can deliver a first version with few functions and then gradually expand the product with more and more functions and features.

This first variant is often referred to as a Minimum Viable Product (MVP).

It’s the version that has the minimum functional scope with which the software can be used.

This offers the possibility of quickly delivering important functions to the customer without having to wait for the rest.

This shortens the time to market, which is a very important criterion in today’s world because the environment is also developing very quickly.

There Is No Bathtub Curve

Software has no wear and no aging.

Hardware is characterized by a bathtub curve, where early failures due to development errors occur at the beginning, then a long phase of stable functioning, until later failures occur due to wear and aging.

With software we have the burndown chart. Here we see the errors from development that are resolved until a stable state is reached that no longer changes.

(Well, until the next change, but that’s another topic.)

Finding all errors is not easy and also takes time, but once you’ve worked through the errors, you’re also done.

Coding Is Relatively Universal

A decisive advantage of software development over hardware development lies in greater flexibility in personnel deployment.

While hardware projects often require highly specialized experts for different disciplines, the competencies in software development are significantly less differentiated.

This doesn’t mean there are no specialists – the crucial point is rather that the fields are so closely related that specialists can also help in adjacent areas.

Developers can usually be deployed across domains and can familiarize themselves relatively quickly with adjacent project areas.

Additionally, development tools and testing facilities in software are largely standardized and can be used across teams, which further shortens the familiarization time.

This more universal deployability makes it possible to react flexibly to capacity peaks, compensate for bottlenecks through resource redistribution, and scale teams as needed.

Software Is Relatively Cost-Effective

When I see the costs of a software release, the shock is often initially great.

Somehow you intuitively expect software development to be cheaper than hardware development – and when large sums are quoted, the disillusionment is great.

However, this initial reaction shouldn’t obscure the fact that software development is actually much more cost-effective than comparable hardware projects.

The decisive difference lies in the significantly shorter capital payback period.

While hardware products often require years to amortize, software projects can be refinanced more quickly.

This enables shorter product cycles and more agile adaptation to market requirements – a strategic advantage that more than pays off economically in the overall view.

Should I Set Up a Project or Work Agile?

I’m now doing the same exercise as in the last article and going through the criteria for a project and agile development individually. This time I’m looking at the characteristics of software development.

Let’s see what comes out.

Time-limited – works in principle, but since the result is often uncertain, the plan is just as uncertain. This speaks against projects and for agile, because agile can better handle uncertainties.

Interdisciplinary – Not such a big issue, since it’s essentially about relatively closely related fields.

Fixed result – Usually not guaranteed. This speaks against a project.

Defined requirements and constraints – Also not given, so also speaks against projects.

Iterative approach – Helps keep development loops short in case of errors and inaccuracies, so speaks for agile.

Self-organized teams – An efficient way to effectively prioritize available resources. Resources are relatively flexibly deployable. Clearly a plus for agile.

Quick delivery to the customer – Quick availability of features and functions enables quick delivery. So agile.

Short-cycle improvement based on customer feedback – Short capital payback period. Customer feedback from use can also be quickly implemented commercially and strengthens competitiveness. Agile!

Since predominantly complex cause-and-effect relationships exist, the occurrence of problems cannot be effectively prevented with risk management – speaks against project management.

As was not otherwise to be expected, the agile approach is clearly better suited for software development than classical project management. Agile is specifically tailored to the nature of software development and therefore fits like a glove.

Can We Then Completely Forget Classical Project Management?

Well, when projects become very large, the agile way of working also reaches its limits.

That’s the point where we talk about ‘scaled agile.’

Scaled Agile is a method to maintain the advantages of agile development at the core and to get a grip on the complexity that increases with functional scope through superordinate structures.

The best-known scaled framework is probably SAFe.

When I look at these models with my project experience, much seems familiar.

There are coordination processes that strongly remind me of interdisciplinary work in projects. Agile Release Trains have striking parallels to program management.

The scaling, in turn, can borrow very well from classical project management. Nevertheless, an adaptation to the characteristics of software development is preferable to a purely classical project management approach.

So Now We Have a Dilemma

For hardware development, classical project management with agile elements fits.

For software development, an agile approach scaled with borrowings from project management fits.

We now need to bring these together in the next chapter when it comes to developing mechatronic products, which consist of both.

That's exactly what I'll explore in the next article. Make sure to subscribe so you don't miss it.

Subscribe now

If you have any comments or feedback on this topic, please write them in the comments.

Leave a comment

or send me a direct message.

We can also chat about it.

I’m looking forward to hearing from you!

If you found this article helpful, don’t forget to share it with others who might enjoy it too!

Share

And if my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch

A colleague calls me and says:

“Uwe, I have a big problem, but also already have a solution!

Our product development isn’t fast enough. There are new competitors bringing better products to market much faster than we can manage. We urgently need to change something, or we’ll be pushed out of the market!

The solution is a new development methodology. It’s called SAFe and is an agile approach that everyone is using now.

We don’t need project organizations anymore, people organize their work themselves.

There are also no more project goals and schedules, we now work agile with backlogs and features.

Take a look at this, it’s definitely something for you too.”

Is he right?

Of course I’ll look into it!

That’s just how I am, I don’t believe anything without examining it. I want to understand.

If you’re interested in what assessment I’ve come to, then keep reading. I’ll tell you about it in this and the following articles.

I want to make it understandable and easy to follow, therefore I will examine the individual aspects of hardware, software, and mechatronics development sequentially one after another.

So let’s start today with the development of pure hardware products.

Development of a Product Consisting of Mechanical, Hydraulic, Pneumatic, or Electrical Systems

When I think about this type of product development, the following sentence immediately comes into my mind:

Let’s look at these three characteristics in detail so we can assess whether this is true and what it means for the way work is organized.

Why Is It Complicated and Not Complex?

The behavior of typical hardware disciplines (mechanics, hydraulics, pneumatics, electrical engineering) is predominantly complicated and rarely complex.

Complicated means there are causal cause-and-effect relationships.

If I do this, that happens.

These disciplines are scientifically researched and can be worked on with engineering methods and tools.

However, this is also where a problem with the complicatedness lies.

These cause-and-effect relationships are not known to everyone.

You need subject matter experts who are very well educated and experienced in their respective field, who have completed extensive training and who master the required methods and development tools.

Lets record this insight:

The existence of universal geniuses who know and can do everything are an unrealistic wishful thinking.

There are specialists who master subject areas in depth, and generalists whose expertise lies not in the individual subject areas themselves, but in understanding how they interact and connect. We need both in a development project.

If we want to meet the product requirements for a hardware product, it must be determined by what means and technologies they should be fulfilled.

• You can use mechanical structures, then you need people who are familiar with technical mechanics.

• You can use hydraulic systems, then you need people who are familiar with hydrostatics and hydrodynamics.

• For pneumatic systems you need fluid dynamics.

• And then there’s also thermodynamics, electrical engineering, vibration theory, control engineering, materials science, and much more.

Each discipline in itself is already complicated, and the interaction in a product makes it even more complicated!

And that’s exactly where some complexity comes into play after all.

Because everything is so highly complicated, errors and prediction inaccuracies are immanent and unavoidable.

However, you don’t know in advance where and when you’ll be wrong. That’s pure chance!

At this point we no longer have a causal cause-and-effect relationship.

And then there are always circumstances that are causal by nature, but whose laws are either not yet researched, i.e., unknown, or for which there is no method yet with which they can be adressed.

In these cases, there is no alternative but to select solutions based on experience or, in the worst case, to choose randomly. At this point too, it’s unfortunately not predictably certain that you’re always right.

Unfortunately, this happens relatively frequently in practice in hardware development, which is why we also have to deal with substantial amounts of complexity in hardware development.

That’s then my next insight:

And Why Do Hardware Developments Always Take So Long?

1. This is partly because many errors and mistakes can only be found out empirically.

2. There are problems for which there are either no theoretical development methods yet or no practical ones.

If this is the case, physical prototypes are needed to resolve these situations.

Building physical prototypes takes an immense amount of time.

Materials must be procured, tools and fixtures must be built, then the parts must be manufactured and the product assembled and put into operation.

Depending on the type of product, this can (rarely) take days, (often) weeks, but it can also take months before everything is finished and you can work with it.

So I can record the next insight:

But there’s another time consumer in hardware development that you can’t get around.

And that’s the problem that hardware wears out and ages.

The system behavior and product properties of hardware change over time.

This has the consequence that you can’t just look at the new condition.

All states over the entire life time, from new to end of life, must be considered and validated.

This topic is scientifically particularly demanding and is therefore still mostly solved empirically today.

So the investigation takes quite a while. As the systems and parts must have the chance to develop wear behavior.

Even if the product’s lifetime can be condensed into a shortened period with statistics and acceleration, significant time spans still remain.

Formulated again as an insight:

Unfortunately, the last two insights also occur simultaneously.

Imagine that I only find out towards the end of a test series that I was wrong about my assumptions about how the product behaves towards the end of its life.

Then in the worst case, prototypes must be built again and the test repeated.

Except for the Errors, Hardware Development Is Plannable

If I look at the four insights, then I can conclude that except for the errors and inaccuracies, hardware development is fundamentally well plannable.

You know the mechanisms of action in principle and can therefore structure and prepare the approach well and sensibly.

It even has a great advantage to plan, because once I’ve created and executed these plans, I can subject them to a continuous improvement process.

With each further development, the plan then gets better and fewer errors occur.

As they say: Don’t make the same mistake twice!

This reduces complexity with increasing experience and development becomes more efficient and faster.

So Should I Rather Set Up a Development Project or Work Agile?

The major project management organizations (IPMA and PMI) are relatively agreed on the definition of criteria that characterize a project.

A project is a time-limited undertaking of an interdisciplinary project team with defined requirements, clear boundary conditions, and a specified result.

In contrast, agile development is characterized by an iterative approach of self-organized generalist teams with rapid delivery to the end customer and short-cycle improvement of the product based on customer feedback.

If I now put the puzzle together, the following comes out.

• Time-limited can be done because it’s well plannable, so this speaks for a project.

• Interdisciplinary must be, because high expertise in diverse subject areas is needed, so this also speaks for a project.

• Specified result. Customer expectations are relatively stable but must be met safely, also speaks for a project.

• Defined requirements and boundary conditions are given, so also this speaks for a project.

• Iterative approach helps with errors and inaccuracies to keep development loops short, so this speaks for agile.

• Self-organized teams. Since many experts are needed, a very large number of employees are usually involved, so that self-organization is numerically difficult. A dedicated project management resource seems appropriate. This speaks rather against agile.

• Rapid delivery to the customer is not feasible due to the long prototype manufacturing and validation times. This is strongly conflicting with agile.

• Short-cycle improvement based on customer feedback. Hardware development is expensive and therefore has a long capital return time. If the product is revised too quickly, it doesn’t earn its money back. Not agile!

• Since predominantly causal effect relationships exist, the occurrence of problems can be effectively prevented with risk management. Risk management is a project management method.

So, What Exactly Needs to Be New Then?

In classical project management theory, a project is completely described and planned out from beginning to end.

However, the complex matters I explained, completely defy prediction and therefore cause constant plan changes and readjustments to the project.

This creates immense inefficiencies and wastes resources, since the entire planning process—with all its coordination efforts and investigations—has to be repeated multiple times, each time from the current project stage all the way to the project end.

Complex matters can be controlled better and more efficiently with agile project management methods, where planning is done only for the timeframe that can be foreseen and assessed with reasonable accuracy.

I call these incremental plans Drum Beats. I’ve already written about this in an article and will go into more detail on it in the future.

This hybrid approach is an essential success factor when it comes to making hardware development faster, cheaper, and more efficient.

In the next article I will look at software development, so please subscribe to my newsletter so you don’t miss it.

Subscribe now

If you have any comments or feedback on this topic, please write them in the comments

Leave a comment

or send me a direct message.

We can also chat about it.

I'm looking forward to hearing from you!

If you found this article helpful, don’t forget to share it with others who might enjoy it too!

Share

And if my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch

The world isn't waiting for us to comfortably and leisurely optimize our old ways of working.

Drastic changes must be made urgently, or we will become the developing countries of tomorrow!

Since the last industrial revolution, Western industry has dominated the world. We were the heroes. Everyone envied us and gratefully accepted everything we produced.

Cars, machines, electronics, software—there was no way around North America and Europe.

But this has changed radically over the past few decades.

China, India, South America, Asia-Pacific, the Middle East, and yes, even Africa want their share of the pie and are no longer satisfied with the role of recipient and low-wage countries.

While the US tries to freeze the status quo with tariffs and force, and Europe remains petrified in a state of paralysis, I believe we must do something to maintain our competitiveness in this increasingly intense competition.

But to do this, we must radically question ourselves and make drastic changes. And we need to do it quickly!

Those who don’t question the foundation of their product development now will no longer be relevant tomorrow.

NewPDP - History

This yielded a number of starting points for making the development process faster and more efficient.

On this basis, I developed this new concept, supported by my team and experienced, competent consultants. In addition to the study’s findings, we incorporated our own experiences from development projects that we’ve participated in over the past 30 years.

In 2022, the NewPDP began being applied in two projects that were selected as pilot applications. During these first years, the NewPDP continued to evolve, until in 2024 the decision matured to use it for all newly starting projects going forward.

So it's not pure theory but rather a development by a dedicated team, whom I would like to thank at this point for their courage, resilience during the early days, and persistence to see it through.

I spent a long time thinking about what name we should choose for a new product development process. It should be cool, spark curiosity, and invite participation.

In the end, I decided to stick with the rather trivial name “New Product Development Process,” because that’s what it’s about: We need to implement a new process that unites the proven and the new in one coherent concept!

However, it’s not a gradual evolution of the familiar, but truly a new process!

Even though the NewPDP won't be new forever, I'm using the name that people intuitively picked.

4 Pillars—3 Catalysts

The NewPDP is based on 4 pillars—subject areas in which fundamental transformation takes place.

I will briefly describe here in this article what these subject areas are and why they are relevant. You’ll find the full content in many more Substack articles that I will write on this topic throughout this year.

In addition, there are 3 factors that must be changed to alter the boundary conditions in such a way that the transformation is sustainable in the long term.

There will also be extensive and detailed information on these.

If you haven’t already, please subscribe to my newsletter so you don’t miss these articles.

Subscribe now

The 4 Transformation Fields of the NewPDP

Collaboration - The Drum Beat

To remain competitive, the potential and performance capability of employees and leaders must be converted into performance with a high degree of efficiency.

As an engineer, I deliberately use "efficiency" here in its physical/thermodynamic sense - the ratio of useful output to total input - rather than the broader management concepts of efficiency and effectiveness. Physical efficiency encompasses both: achieving maximum benefit with minimal effort by doing things right and doing the right things. In this context, energy and human potential can certainly be equated.

I like the analogy with a machine. A well-designed machine converts the energy used into usable performance with as few losses as possible by meticulously optimizing the interaction of all machine elements in detail.

That’s exactly what we need to achieve with human potential. The performance capacity (energy) that lies within people must be converted into maximum performance.

It’s not an absolute reinvention, but rather crystallizes the essential core from many management methods that is relevant and effective for high efficiency.

It combines culture and operational procedures into a coherent method that is both practical and continuously improvable.

Processes - Evolving Standard Procedures

Yes, I admit, this is not a new invention either.

Workflows have been able to be improved with Lean Management methods for many years. This saves resources and increases speed—exactly what we need.

We just haven’t sustained it with the necessary consistency in the past.

So we need to tackle this again and really do it sustainably.

Standardizable workflows must be standardized and optimized through a continuous improvement process.

What was true in the past is still true today. Continuously improving the same workflows brings professionalism, which in turn brings speed and efficiency.

Clearly assigned resources, well-practiced processes, and continuous improvement work wherever the environment is stable and predictable. Let’s face it, not everything is volatile and unpredictable.

It’s not just new, groundbreaking innovations that are necessary to survive in an increasingly competitive field.

It’s also the tried-and-true approaches that must now be implemented consistently and without lazy compromises.

I will write extensively about this because we must finally understand what prevented our success. Only by addressing these root causes and getting it right this time will we achieve the results we need to survive.

Technology - Proactive Technology Maturation

We are currently experiencing a technological revolution unfolding on multiple levels simultaneously:

• The energy transition and electrification of formerly fossil-fueled applications

• Artificial intelligence taking work off people’s hands and enabling previously unthinkable functions and features

These are just the most obvious technology fields already putting us under pressure today. But there’s more on the horizon:

• Quantum computing

• Space and satellite technology

• Nuclear fusion

• ...

What makes this truly transformative is that these new technologies will fundamentally reshape even well-established fields. Materials science, mechanics, mechatronics—everything will change as a consequence.

For us developers, this means we must deal with an immeasurable number of new, immature, and poorly understood technologies while simultaneously bringing products to market that are just as reliable, powerful, and user-friendly as before.

Well, probably the previous level isn't even sufficient when the competition raises the bar, as we can already observe throughout the industry.

This field will decide between survival and death. So our NewPDP must also offer different and more future-proof approaches here if we want to be among the survivors.

Uncertainties and misjudgments are inevitable. This is why timing and investment decisions must be smart and well-measured.

This pillar is truly innovative and visionary. It transforms not only the technical dimension but fundamentally reshapes how we financially evaluate and fund technologies—a paradigm shift essential for future competitiveness.

Development Tools - Hardware Light Development

It’s only been about 40 years since the transformation from working with slide rules and drawing boards to working with computers took place.

I can hardly believe that I experienced this myself at the beginning of my professional career.

Today it’s normal for us to sit in front of a 2D screen and create three-dimensional products in the computer.

But now the next transformation is at the door!

We as engineers will become part of the virtual world and develop products in the metaverse!

Working with hardware prototypes currently determines development time and costs when developing mechatronic products. The efficiency gains from a transformation to a hardware-free development process are gigantic.

Anyone who sleeps through this will be left behind—I have no doubt about that.

However, this is no walk in the park. The subject matter is complex, and it’s not just about applying new technologies, but also about completely new thought structures and approaches.

That’s why I also chose Hardware Light Development instead of Hardware Less Development. Let’s see how far the journey takes us.

In any case, we now urgently need to pack our bags and get on the road, otherwise the train will have left and we can only wave at it from the platform.

3 Catalysts of the NewPDP

In addition to the 4 transformation fields, we must also deal with 3 aspects that must also undergo fundamental transformation for a company to function in this new environment.

Organization

We all know the classic organizational forms:

• Functional organization

• Divisional organization

• Matrix organization

We also all know the disadvantages inherent in these principles. I’ll just say: silo thinking and complex responsibility models!

However, there are also many reasons why these organizational forms are repeatedly chosen despite their disadvantages.

Alternatives that typically emerge in software startups have not yet achieved this breadth of application.

I’m clear that the disadvantages of classic organizational models are no longer bearable in our future competitive environment. We need better alternatives.

The 4 transformation fields offer the opportunity to create conditions under which new organizational forms become possible.

A symbiosis emerges: The transformation fields require new organizational forms but simultaneously enable them.

You see, this will be an exciting aspect that I will explore.

Leadership

The situation is similar with leadership models:

Detailed job descriptions, management by objectives, promotion as a reward for good work are methods that even the youngest among us should have experienced firsthand.

But here too, there are serious disadvantages that make our organizations slower and less capable than they can be.

Examples? Endless reporting meetings and showing off for career advancement, micromanagement, timidity, and bureaucracy. All phenomena for which there is no room in the future.

Here too, we need alternatives. That’s why this aspect will occupy an important space in my future articles.

Product Architecture

Let’s come to the last point for today.

Over the past 100 years, modularization and variant management have occupied us. Both originated from the increasing complexity of hardware variants.

While there was little product variation at the beginning of the last millennium, it has grown exponentially.

It was a competitive criterion to precisely meet customer needs through products increasingly tailored to specific customer requirements.

Since the focus during this time was on mechanical products and in later years on mechatronic products, the competence had to be developed to create many product variants with few parts.

The problem was met with modular product architectures.

Although variance will by no means decrease but will continue to grow exponentially, product architectures will change significantly.

Known technologies will be replaced by new ones, creating the need for new architectures. However, these will initially be just as poorly understood as the new technologies themselves.

At the same time, the role of software in meeting customer requirements will increase significantly, and the role of hardware will be reduced, though not disappear.

In short: Modularization will no longer be enough! Modern product architectures will look fundamentally different.

We’re already observing this in vehicles: The Software Defined Vehicle follows different architectural principles. We’re experiencing firsthand how difficult it is to find the philosopher’s stone.

While some of us are still trying to realize the modularity architectures that would have been appropriate 20 years ago, they actually need to jump into the cold water of architectural transformation without having properly learned to swim.

Outlook

As this overview demonstrates, the NewPDP is a comprehensive and profound framework that warrants much deeper exploration.

In the coming articles, I will examine each topic area and transformation aspect in detail.

Many of these topics can be viewed controversially, and I welcome an intensive exchange of ideas. I would be grateful for comments, opinions, and differing perspectives. I'm also happy to answer any questions you may have.

I will incorporate the identifier buttons that I used in this article into my articles so that you can more easily assign the respective articles to the subject areas.

Although the NewPDP has been maturing for several years, there is still plenty of room for further concretization, operationalization, and adaptation to rapidly accelerating developments.

Please don’t hold back with feedback and suggestions for improvement!

I would like to be involved when you successfully future-proof your companies and make life difficult for the esteemed new competitors. Please contact me if I can help you.

If you liked the article or have questions or comments, please write them to me in the comments. I appreciate every comment.

Leave a comment

We can of course use the chat function to exchange ideas directly.

If you liked the article, please share it with others.

Share

I’d be very grateful if you shared my newsletter with your friends and colleagues.

Share Uwe Mierisch

I just can’t stand them anymore.

Those consultants and smart advisors who go from company to company telling everyone—whether they want to hear it or not—how brilliantly Chinese firms are making Western companies look old and foolish.

But you know what?

These consultants are right about one thing:

Competition has gotten tougher, there’s no denying that.

If we want to survive in this new world and thrive long-term, a whole lot needs to change in our companies.

But the solution doesn't lie in copying Chinese companies—it lies in being better.

I won’t address all the aspects that play a role on the path to long-term competitiveness in this article. I’ll only select one aspect, but one I consider absolutely crucial.

And honestly, it’s long overdue that we tackle this.

Today, let’s talk about how we can make this happen!

Efficiency as a Critical Competitive Factor

In my last article, I wrote about why individuals can achieve little alone but accomplish much through collaboration, and why building personal relationships and networks is essential to this.

I described how people with many strong relationships are more successful than lone wolves.

But what if we didn’t leave it up to individuals to build and maintain their relationships?

What would happen if we implemented a way of working in the company that methodically and systematically promotes the formation of strong relationships between people?

Exactly — we would activate the potential of our entire workforce as an integrated collective, and the company’s performance and thus competitiveness would increase!

Costs decrease, products improve, customers become more satisfied.

One effective way to do this is to make the Drum Beat, which I introduced as a project management method in previous newsletter articles, the general working rhythm throughout the entire company.

Experience shows that cost reduction programs only produce short-term results. The Drum Beat, however, when practiced continuously as a work mode, ensures lasting efficiency that increases steadily with growing experience and ever-strengthening relationships.

What I'm explaining using the Drum Beat as an example naturally works with all similar methods, such as product increments in agile project management. I think you'll recognize the parallels and be able to transfer this to your process if you're using something similar instead of the Drum Beat.

If you have questions, don’t hesitate to contact me.

So let’s look at the details of what matters.

Shared Goals Are the Key to Company Success, but Also to Individual Success.

If the potential of every employee and every leader is to be efficiently deployed to increase efficiency for the entire company, then it’s an important prerequisite that the goals and results of all process participants are aligned.

From the company’s perspective, it’s simply not enough for employees to individually achieve their personal goals. It’s necessary for these individual goals to work together toward a common company goal.

This doesn’t happen by chance but must be ensured through a well-structured process.

The Drum Beat planning process offers an excellent opportunity for this.

In the project, the project manager develops short-term Drum Beat Deliverables with their project management team. These are goals aligned with achieving project objectives and give the entire project team orientation and priorities.

They are also a recognized measure of each project team member’s success, giving everyone clarity about what’s worth putting effort into.

Clarity regarding the results to be achieved helps both individual employees and the entire company.

In many companies, projects are the essential part of business operations that determine success. Nevertheless, there are many reasons to use the Drum Beat method outside of projects as well, in the ongoing daily business of all indirect administrative areas.

In addition to project goals, this also addresses company goals that aren’t directly influenced by projects.

I’m excluding manufacturing areas here because they usually have other objectively measurable goals that enable elegant efficiency measurement. We can talk about that if there’s interest.

Clear Agreements Strengthen Relationships

Once the deliverables and thus the priorities are clear to everyone, it’s about all employees making their individual agreements to be ready to work and deliver.

This is nothing less than well-organized relationship building. People talk to each other about who needs what from whom and document it properly so it won’t be forgotten.

In this phase of Drum Beat planning, the foundation for trust and good relationships is laid here. Exactly as I described it in detail in my last article.

Communication is intensive, support needs and necessary contributions become concrete and completely transparent to those affected.

Remember? In my last article, I challenged you to make a personal plan for how you can intensify your relationship maintenance.

This increases the intensity and quality of this aspect of relationship maintenance, creating a strong relationship network throughout the entire organization while also helping each individual.

Through the shared rhythm and beat, an intensity is possible that couldn’t be achieved through singular individual actions.

Now We Really Do It

Once the planning event has taken place, it’s time to deliver on the promises.

Here again, everyone is working together with the same priorities.

I think an achievement rate of over 80% should definitely be reached. If it’s lower, the goal ambition must be reduced so that the organization’s performance level and ambition level align.

The increasing efficiency over time will ensure that ambition can also rise. So don’t plan for 100%, but aim for a range between 80 and 90%, so there’s a corridor for efficiency growth.

It’s clear that this promotes the trust aspect. Achieving jointly agreed deliverables provides confidence that it will work again next time.

This increases people's trust in each other. As a result, people become more ambitious and learn how much more can be accomplished.

Celebrate Achieved Results and Be Grateful

At the end of every Drum Beat, we review what was achieved together.

This makes it clear to everyone what worked and what perhaps didn’t.

This shared pause and appreciation of what was achieved is a crucial point that helps solidify relationships between people.

It’s not necessarily common to take this time and talk together about what was achieved.

Don’t take this lightly. Here in Germany, especially in Swabia, they say: not scolded is praised enough. It’s meant to suggest that celebrating gratitude is seen as a waste of time.

But the exact opposite is true!

Strong relationships and trust—indispensable for efficient collaboration—only form when people receive feedback that their efforts are seen and there's willingness to show appreciation in the future.

Here again, the Drum Beat offers the opportunity to handle this important aspect of relationship maintenance simultaneously and in a well-organized manner.

How Can We Be Even More Successful

I think you’ll agree with me that it’s not satisfying to remain at a once-achieved performance level.

There are many scientific studies proving that ambition isn’t coincidental but belongs to human nature for many reasons.

But we also know that the field in which each individual person displays their ambition doesn’t always lie in business.

Here too, the Drum Beat offers an organizational framework with its retrospective that makes a level achievable that’s greater than the sum of individual persons.

Personal Success and Company Success Go Hand in Hand

If the majority of employees in a company are successful, then the company is usually successful too.

But the reverse is also true: if the majority of employees aren’t successful in their work, then the company has a results problem and is very likely not competitive in the long term.

I always start from the employee perspective, because the notion that employees automatically become successful just by working for a successful company is an unrealistic fantasy with no basis in reality.

That’s why I believe the right and important path is to start with organizing employee collaboration to lift the company’s overall performance to a level that wouldn’t be achievable through individual successful employees or leaders alone.

Now it’s true that there are other important factors to address as well — more on that in future articles.

But let’s start with employees and their collaboration. I hope I’ve convinced you that significant improvement potential can be realized this way.

However, it still needs to be operationally implemented in daily business processes, and I haven’t described all the details here in the article.

So if you’ve decided to implement this proposal, contact me and I’ll discuss the operational design in your specific environment together with you.

Leave a comment

You're free to choose the method that works best for you.

I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.

Subscribe now

If you found this helpful, don’t forget to share it with others who might enjoy it too!

Share

I’d be very grateful if you shared my newsletter with your friends and colleagues.

Share Uwe Mierisch

What’s your reaction to this statement?

“Of course it’s about me! That’s always been my motto.”

Or

“Absolutely not, that’s antisocial! The common good must stand above the individual’s self-interest.”

Let’s unpack this together. I hope we can agree on a common perspective.

But if you have a different opinion, don’t hesitate to share it with me. You can use the comments or send me a personal message. I’m very curious!

Leave a comment

It’s About Creating Value

When I talk about the business environment, we often immediately think of numbers like revenue, profit margins, or ROI.

But actually, the purpose of every business activity is to create value for which someone voluntarily gives up something that belongs to them.

Yes, this business value can often indeed be measured in money.

However, it becomes more difficult when it’s not about companies, but about people.

In human interaction and collaboration, compensation often doesn’t occur through direct exchange, but happens with a big unknown time delay.

I help someone else today and get something back sometime, possibly.

Another special feature is that this compensation often doesn’t consist of money, but of other, non-material values such as social status, services and competencies that I don’t have myself, or simply by having something taken off my plate that I don’t like doing.

And this is where community comes into play, because the community can also give something to the individual that represents value to them.

Take a moment and think about what other forms this compensation could take, so that it’s “worth it” for you to do something for someone else now.

Precisely because this connection between creating value for others and receiving value for oneself can be so diverse and non-concrete, people must enter into relationships with each other.

Relationships are necessary for the system of human society to function.

If you have a good relationship with another person, you will receive something from them without having to give something back immediately.

You will also give something without immediately expecting something in return.

But the reverse is also true. If you believe that the other person won’t do anything for you, then you won’t do anything for them either.

That’s called a bad relationship, and it develops in the same way as a good relationship, namely by gaining experience with the other person.

So let’s next look at how a good relationship comes about.

Trust

Every person has expectations of the other person with whom they interact.

When these expectations are met to a high degree, trust grows.

I collect positive experiences with the person and therefore assume for the future that my expectations will continue to be met.

If this is mutual, then a good relationship develops between us.

If my expectations are regularly not met, then exactly this experience forms. The advance trust that may have been present initially dwindles.

No relationship develops, instead we distance ourselves.

While trust is lost very quickly, building trust is much more effort-intensive.

It’s not enough to want to meet the other’s expectations, it must actually happen.

That’s why let’s now look at what’s necessary for this.

Communication

Very intensive and honest communication is the first and one of the most important building blocks for building trust, for two reasons:

1. If you don’t talk to the other person, you won’t learn their expectations and therefore you most likely won’t meet them. Believe me, random hits or intuition aren’t enough! You must communicate very intensively and broadly so that you even learn what moves the other person, what help they currently need, what problems burden them, and what support they’re willing to accept.

2. If you communicate frequently and extensively, your counterpart gets the feeling that you’re interested in them and their problem and want to help them. Even if the expected help perhaps doesn’t come or doesn’t work as expected, the experience remains that you wanted to help them, and that’s already half the battle.

Yes, there’s a right measure for communication. Too little communication is harmful, too much communication is annoying. But communicate more rather than less!

Proximity

Proximity to each other is closely related to communication.

It’s much more credible when you look directly into each other’s eyes during communication, directly perceive body language and emotions.

Believe me, it’s no coincidence that executive assistants climb the career ladder much more successfully than other employees.

You can assume that they’re capable and probably smart too, otherwise they wouldn’t have been selected for the job. But there are many more competent and smart employees in the company.

The difference certainly also lies in the fact that they have proximity to the boss, which enables them to build great trust. Believe me, no one promotes someone they’re not sure is worth the trust!

Now not everyone will always have the opportunity to establish this proximity. That shouldn’t stop you from communicating and building trust. Where it’s not so easy, you just have to make more effort.

And don’t limit this just to bosses for the sake of your career, because if you don’t have the trust of your colleagues and they don’t help you, then the boss won’t either.

Authenticity

Authenticity is the next important building block for gaining trust.

Be as you are!

You instinctively sense whether someone is playing a role, and when you have this feeling, it’s not trust-building. You then involuntarily ask yourself: “Why are they doing that? Do they have something to hide?”

This suspicion is fatal and destroys trust.

Authenticity is the basis for predictability, and this in turn pays very strongly into trust.

Be as you are, then the other person knows what to expect from you. They can then adjust their expectations to reality and also understand why something might run differently than they expected.

This also includes openly admitting mistakes and dealing honestly with yourself and the situation.

Empathy

While authenticity was about you, empathy is about the other person.

You must take the time and make the effort to put yourself in the other person’s shoes.

It’s not enough to ask the other person about their expectations and then meet them.

You must find out what really moves the other person, what they expect from you in their inner self, and what is how important to them.

It helps to have known each other for a long time. Over time, it becomes easier to grasp the other’s thoughts, recognize their feelings, and identify their expectations.

Reliability

Meeting expectations also means being reliable.

Actually, this is the simplest discipline in building trust, but it’s still so difficult:

Keep what you promise!

Do what you say!

With expectations that you create yourself, there’s no “I couldn’t have known that!”

Yes, it’s as trivial as it sounds: Those who are unreliable lose trust. You can’t build a good relationship with unreliable people.

Here too, of course, there’s no 100%. Something can slip through. When that happens, authenticity and honesty can often still save the situation.

However, if it becomes the rule to not keep your promises, then trust is gone, and so is the relationship.

Reciprocity

After talking so much about trust as the basis of a relationship, I want to come back to reciprocity.

This principle forms the foundation for a good relationship and for success in a business context.

Trust is the belief or certainty that this principle works between us.

But it’s not enough that we both have trust, we must also actively apply it.

An important basic rule is that reciprocity consists of advances.

Everyone must do the right thing for the other person at the time when they need it.

But at that time, they don’t know whether they will really get the return service sometime and whether the measure will be balanced.

A situation can certainly arise where one person always gives more than the other in the long run. Perhaps because the other can’t give more, or because I myself don’t need more.

In the end, it’s not the balance sheet that’s decisive, but that the principle works at the right time for everyone.

Now comes the big but:

There are situations where the other person isn’t willing to do their part of reciprocity. If you recognize this, you must act, otherwise you’re the fool and will be exploited.

Address it, and if it doesn’t change, then draw the consequences.

There are relationships that can’t be patched up and must then be consistently ended.

Willingness to Compromise

There will always be situations where your own interests are in opposition to the interests of the other person. Here it’s necessary to find a compromise that both can accept.

This requires willingness to compromise on both sides. If one party continuously insists on their advantages, then it’s difficult to build and maintain a good relationship.

So be willing to back down sometimes, trust that the other person has the same attitude.

Network Maintenance

In a business environment, an extensive network of relationships is necessary to be successful yourself and to be part of a successful environment.

That’s why you must develop and maintain a multitude of relationships.

This costs effort and time, but it’s still advisable and even necessary.

Another element of a good relationship is that you also share your network, which you’ve built with great effort, with others.

Reciprocity isn’t just about doing what’s necessary yourself, but also about using your own relationships and the associated trust to help the other person.

Professionalism

With that, I come to the last point for today, professionalism.

This requires professionalism.

Professionalism means qualifying yourself in a field, developing skills and abilities, and being able to produce high-quality results.

The profession is where you can create relevant value for others.

You need something that’s your brand. Something that everyone knows you’re particularly good at and that it’s worth building a relationship with you for.

Partnerships Are Based on Functioning Relationships

In the last article, I addressed partnerships and claimed that it makes more sense to build equal partnerships for mutual benefit, rather than practicing collaboration according to the power principle based on unequally distributed power positions.

I claimed that partnerships only work when the people involved build good relationships with each other.

In this article, I’ve now addressed exactly these relationships.

Please write to me about what experiences you’ve had in this topic area and which aspects I may not have covered sufficiently.

Leave a comment

We can also chat about it.

I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.

Subscribe now

If you found this helpful, don’t forget to share it with others who might enjoy it too!

Share

I’d be very grateful if you shared my newsletter with your friends and colleagues.

Share Uwe Mierisch

I think very few people believed we could actually pull it off!

It’s been 25 years now. We were a small team with a big mission:

“Build a company, develop a portfolio of heavy commercial vehicle axles, and supply the American subsidiary’s serial production with high quality and deliver reliability in 3 years.”

When we tackled this impossible mission, one thing was clear: We could only do it together with strong, competent partners. Alone? No chance!

The path we chose was unusual back then and still isn’t standard practice today.

But before I reveal the secret, I want to describe the standard approach I typically observe—one that has nothing to do with true partnership. That way, you can judge whether this is also common in your environment.

Everyone Thinks: The Most for Me!

In a way, it’s even logical and understandable. When it comes to business, everyone wants to maximize their profit by using all the levers they have.

If you do this consistently, you can observe the following approach:

• I need something for my project that my organization doesn’t have. So I have to buy it. This could be parts or services. What it is doesn’t really matter—in any case, I have a problem on the table.

• To solve this problem, I search for potential suppliers who have what I need. With some luck, I find multiple offers.

• In this situation, I can now use the competition between potential suppliers to negotiate the best price for myself. The more time I have, the more I can put pressure on suppliers. I hold the stronger position and can use my decision-making power to my advantage.

• I delay signing the supply contract as long as possible, specify the product very precisely, and negotiate hard on every small, individual cost item in detail.

• During this phase, suppliers undercut each other, each trying to offer the best price to win the contract.

• Meanwhile, development is already running at full speed. The developers have to work with all suppliers simultaneously, which means extra work and unclear relationships.

• Suppliers do only as much as necessary to barely stay in the race. They don’t want to invest too much because they know only one will get the contract.

• Once the supply contract is signed, the supplier holds the stronger position. Every change that becomes necessary during product development, they charge dearly for. Now is the time for them to recover what they sacrificed during the bidding phase.

• When we’re in serial production and the time comes for the supply contract to expire and be renegotiated, the arm-wrestling starts again.

• I threaten the supplier that I won’t extend the contract unless they lower the price.

• They calculate how much a supplier change would cost me. In my business, these are substantial sums. That’s why the supplier will explain at length that the previous price is no longer profitable for them and they therefore demand a price increase.

• Each side tries to extract the maximum for themselves. I’m in the weaker position because my costs will rise either way. Either I accept the cost increase or I invest substantial sums to switch suppliers.

• My leverage returns when the next project begins. However, the current supplier benefits from the experience and assets gained during the previous project, giving them a significant competitive advantage over competitors. They will fight aggressively to retain the business, undercutting any rival without hesitation. The supplier knows they can increase prices again once I’m back in a weak negotiating position—which happens with predictable regularity as soon as the product is completed.

• If the supplier manages this skillfully over a long time, they have the opportunity to eliminate all competitors and build a monopoly. Then I’m really in trouble!

And of course, my customer does exactly the same thing with me as a supplier!

Do you recognize this pattern in your environment?

Were you already aware of it, or does it surprise you to see how this actually plays out?

You’ll probably also conclude that this approach isn’t efficient and certainly doesn’t lead to an optimal outcome for anyone.

There’s either a winner and a loser, or even two losers—which is always the case when neither side makes money in the end.

The Way Out: Strategic Partnership

I think it’s clear that we wouldn’t have accomplished our task back then if we had proceeded as just described.

Instead:

We entered into strategic partnerships with our suppliers.

Now I’ll explain how that works and what prerequisites are necessary.

It Starts with a Shared Vision

Unlike the approach just described, my intention here is not to delay the decision as long as possible, but to make it as early as possible.

I lay on the table what product goals I need to achieve and what costs I can afford to reach my required profitability.

The supplier lays on the table what their product can do and what price they need for their profitability.

Of course, this doesn’t fit together yet. Each side must move away from their optimum somewhat.

I have to make compromises on product requirements and also be willing to compromise on my price expectations.

The supplier may have to invest more effort in their development and also price in cost efficiencies they can’t yet prove.

We agree on a mutually supported compromise that includes risks for both sides.

Trust Is the Foundation, and That Always Exists Between People

The essential difference from the approach described at the beginning is that the basis for the contract isn’t supposedly objective facts, but agreed-upon goals for which both sides must contribute throughout the project to achieve.

That’s exactly the crucial point. Both sides must become convinced that each will do everything to realize the agreed overall optimum.

There can be no “not my problem” attitude here. All problems are shared problems.

This trust only develops when the compromise is intensively discussed. And specifically, the people who also have decision-making responsibility during the project’s implementation phase must talk with each other.

This is exactly where the challenge lies, especially for large companies with this approach. The more people who have a say, the more difficult it is to build trust and ultimately to prove worthy of that trust.

Back then, we were a very small team with full decision-making authority, and we worked with similar partners. Yet even in that situation, I can say from my own experience that it’s not easy to choose the most trusted partner over the one with the lowest initial price offer.

Partnerships and Trust Grow Over Time

Once you’ve successfully brought a project to completion on this basis, both sides have experienced that they can rely on each other. That the trust is justified.

This strengthens the trust basis for the next project.

You don’t just quickly switch suppliers then, but build further projects on this increasingly strong trust foundation.

Even though it might look like a monopoly at first glance, it is something completely different. Other suppliers still exist, even though the partners choose to stick together for mutual benefit.

However, there is no guarantee that a partnership will last forever—that has happened to me as well. When it does break apart, you have to find a new partner.

Profitability and Partnership Aren’t Contradictory — Quite the Opposite

We’re currently experiencing where power-based business models can lead.

Disrupted supply chains, exorbitant costs, and companies struggling to survive.

This exact consequence occurs when one side manages to gain absolute dominance without adequate mutual dependencies.

If you strive for that yourself, you must also expect that the other side might possibly succeed in building up this position.

In a true partnership, this can’t happen. All sides have a common interest and common success.

But it’s also important to understand that you can’t force a partnership. If a partner isn’t trustworthy, it doesn’t change anything if they offer the supposedly best price.

To put it another way: Cheapness is dangerous!

What’s Your Opinion?

I could write many more details about partnerships in a business environment. But before I do that, I’d like to hear from you what you think about the topic.

What’s your opinion?

Are you interested in more details?

Have you gathered your own experiences with partnerships?

Please write in the comments or let’s chat about it.

Leave a comment

I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.

Subscribe now

If you found this helpful, don’t forget to share it with others who might enjoy it too!

Share

I’d be very grateful if you shared my newsletter with your friends and colleagues.

Share Uwe Mierisch

A Counterintuitive Approach to Better Project Outcomes

In my last article, I made a provocative claim.

I know this goes against common practice. That’s exactly why I want to explain my reasoning today.

The Core Problem: Power Imbalance in Conflict of Interest Situations

Let me get straight to the point:

The result? Stress for that person and suboptimal compromises for the project.

A truly optimal, sustainable compromise requires three elements:

1. Clear advocates: Each goal dimension needs someone who openly champions that position

2. Equal footing: All parties must negotiate as equals

3. Neutral facilitator: A Project Management Master who moderates without their own agenda, working toward consensus

This is precisely why I’ve defined project management roles along these goal dimensions:

• Project Manager: Responsible for project objectives.

• Project Architect: Responsible for the product.

• Functional Representatives/Project Team: Responsible for technical execution and content realization.

The Power Imbalance Problem

When the project manager is also the supervisor of other project management team members, the power dynamic becomes distorted.

The project manager possesses additional leverage through their ability to conduct performance reviews and impose disciplinary measures.

The consequence is predictable: Team members will carefully consider how hard they push their interests against those of their boss.

It’s not easy to contradict your supervisor and consistently advocate for your position against theirs—even when that’s exactly what the project requires.

Three Common Objections (and My Responses)

“But good managers can make good decisions on their own!”

Of course competent leaders can develop compromises independently.

The real question is: Are these the optimal compromises?

That depends heavily on chance—the manager’s character, their mood that day, the team’s courage to speak up. Why leave project success to chance when we can build it into the structure?

“Isn’t this just about performance management?”

No. Naturally, managers must monitor performance and address issues. That’s not in dispute.

The core of my argument is different: It’s about conflicting interests, not performance deficits.

The danger lies precisely in the dual role of project manager + supervisor, where these two issues become too easily entangled. These dimensions must be clearly separated.

“In line management, the boss is responsible for everything too!”

Ideally, a line manager has a single, clear interest: the functionality of their department.

In the dual role, however, multiple contradictory interests systematically overlap.

Similar situations exist outside of projects, and they cause significant problems in practice. Often, they’re branded as “micromanagement.”

A Concrete Example

Here’s a classic conflict scenario that illustrates the issue.

The Situation

Project Goals:

• Reduce energy consumption by 5%

• Keep product costs constant (versus predecessor)

• Be customer ready in 3 years

The Reality:

The project team developed optimization measures. Combined, they would just barely achieve the 5% target.

But there’s a catch:

• Implementing all measures increases product costs

• Some measures violate platform guidelines, others conflict with brand standards

Responsibilities in a Project Organization

To better understand the positions of the individual project team members, here is a brief overview of the responsibilities.

Project Manager

The project manager is responsible for ensuring that the project goals are achieved.

Typical project goals for which the project manager is responsible include:

• Delivery deadline

• Project and product costs

• Performance indicators defined in the project charter (quality, performance characteristics, functionalities, etc.)

They owe the project team balanced, realistic goals that they must align and agree upon with the stakeholders.

Project Architect

The project architect is responsible for a customer-appropriate, platform-compliant product that aligns with brand characteristics.

They represent the interests of the platform architecture within the project and ensure compliance with cross-project product properties and characteristics.

At the same time, they owe the project manager technical architectures and concepts with which the project goals can be achieved.

Department Representatives / Project Team Members

The project team members are responsible for efficient and competent delivery of project work.

The project team members decide on the working approach and the technical execution.

In doing so, they must consider both the project manager’s specifications regarding project goals and the project architect’s specifications regarding product architecture and properties.

At the same time, they owe the project manager efficient, goal-oriented procedures that minimize resource and time consumption, along with balanced risk awareness.

The Three Competing Interests

Those different responsibilities lead to the following perspectives.

Project Manager’s Perspective:

• Implement all measures

• Avoid cost increases through more efficient design

• Negotiate remaining cost gap with suppliers

• Complete everything on schedule

Project Architect’s Perspective:

• Implement platform- and brand-compliant measures (even if costs increase)

• Drop non-compliant measures (even if the energy goal is missed)

Project Team/Functional Representative’s Perspective:

• Get more time to search for better solutions

• Adjust goals with stakeholders

Finding the Compromise

In practice, there’s rarely a perfect solution. Not all predetermined goals can be achieved simultaneously.

A compromise must be found across all goal deviations:

1. Time compromise: How much additional time is acceptable? Can other activities be shortened to compensate, or is there flexibility in the delivery date?

2. Content compromise: Which measures get implemented, which don’t? This determines the gap in energy consumption, costs, and platform compliance.

3. Process compromise: When are project goals adjusted—immediately or after validation? This addresses how stable or volatile the compromise is.

I don’t want to specify a particular compromise here; in each specific situation, a different solution will be the best one. Nevertheless, I think the example illustrates the problem.

Deciding or Negotiating Compromise

Compromises can be reached in two fundamentally different ways:

Negotiating or deciding.

In both cases, arguments need to be brought to the table, but not necessarily all of them.

Finding Compromise Through Decision

Every deviation from a well-considered guideline can have consequences. If there are no consequences, then it’s easy to accept the deviation.

However, the consequences are usually neither recognizable at first glance nor assessable in their impact.

For this reason, each stakeholder must examine the effects on their area of interest and explain them to the team.

In the case of a decision by the project manager, the project managers don’t have to explain their arguments. They make the decision themselves anyway.

Of course, it’s a great advantage for the acceptance of the decision if they communicate their arguments in the justification.

However, I have very often had to experience that in the hectic rush of daily business, this is exactly what doesn’t happen.

The consequence is then a poor collaborative climate and an “I don’t care anymore” attitude.

Deciding on a compromise is undoubtedly the fastest solution strategy. However, it’s also the solution strategy with the greatest volatility.

The probability of finding the best compromise through decision-making borders on the probability of winning the lottery.

As long as it’s a reasonable compromise, it’s not a disaster not to decide on the very best solution. Things move forward in any case, and that’s important.

However, possible misjudgments in the decision-making process and a lack of commitment to the compromise within the project team regularly lead to this compromise being frequently questioned afterward.

Finding Compromise Through Negotiation

In negotiation, all arguments come to the table.

Each advocate explains what consequences arise for their area from each potential goal deviation. Here the project manager is part of the team.

Then consensus is sought.

Consensus means finding a solution everyone can live with, even if not everyone is happy. But there’s both understanding and acceptance.

Prerequisites for stable consensus:

1. All participants are equal

2. A facilitator without their own agenda guides the discussion

This is exactly where traditional hierarchy fails:

• If the project manager is the team’s supervisor, they’re no longer equal—they have power.

• If they also supervise the Project Management Master, the facilitator is no longer neutral—they’re suspected of representing the boss’s interests.

When the project manager is on equal footing, the resulting consensus has significant advantages: It’s based on the entire team’s competence and a shared risk assessment, giving it high quality and acceptance.

The Bottom Line

I’m not claiming projects can’t function without separating disciplinary and professional authority. Many projects run reasonably well in traditional structures.

But I do claim this:

Good compromises aren’t found by luck or because someone decides to be nice.

Good compromises emerge through structures that enable genuine representation of interests, equal footing, and neutral facilitation.

Now’s the right time to jump into the comments – I’d love to hear about similar experiences, parallels you’ve seen, or your take on this.

Leave a comment

We can also chat on this topic.

I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.

Subscribe now

If you found this helpful, don’t forget to share it with others who might enjoy it too!

Share

I’d be very grateful if you shared my newsletter with your friends and colleagues.

Share Uwe Mierisch

Sometimes it proves useful to explicitly clarify matters that intuitively seem self-evident.

Upon closer examination of common project management terms, I find that not everything is as clear as assumed. This is precisely what causes misunderstandings in collaboration. People wonder why things don’t run as smoothly as they would like.

For this reason, I want to discuss the following terms in this article:

• Management

• Manager

• Project Management

• Project Management Team

• Project Team

• Project Management Office

• Project Management Support

• Program Management Office

You see, that’s quite a long list. So let me get started right away.

Management

I’ll first focus on the activity and then address the role.

Managing Is More Than Giving Instructions!

The biggest misunderstanding arises from the fact that “managing” is often understood only as interaction between manager and employee.

But it’s much more than that!

Unfortunately, it’s also frequently the case that managers inadequately perform these other aspects as well. Which further reinforces this false perception.

So what does managing actually include?

There’s an abundance of literature that defines the topic very differently.

Therefore, I’m presenting a model here that I consider most effective based on my professional experience.

If you have a different opinion on this, please write to me in the comments—I’m very interested:

Leave a comment

Now let’s look at the activities which belong to managing:

Setting Goals

Managing begins with setting goals.

However, defining goals is not a matter of inspiration—it’s hard, time-consuming work in itself.

Typically, you start with one or more predetermined goals.

To avoid going too deep here, I’m deliberately leaving out goal derivation from visions and strategies.

Goals to be achieved must be cascaded into sub-goals:

• For topics

• For organizational units or individuals

• For time periods

Planning

• What activities are required?

• How much time do the activities need?

• Who will be needed for execution?

• What conditions and prerequisites must exist?

• What dependencies must be considered?

• How can partial results and goal achievement be measured?

• Who must make which decision when?

Commissioning Work and Deploying Resources

The next step is the one that management is often mistakenly reduced to.

Resources such as budgets, work time, or work tools are provided.

Decisions relating to content work are made or triggered.

Preventing or Solving Problems

Plans rarely work out as intended. Therefore:

Evaluating Results

The evaluation forms the basis for further action.

Manager

I consider it very important that managers personally execute all these aspects of management and don’t completely delegate individual ones.

This doesn’t mean that a manager can’t obtain support or input.

Quite the contrary: Management is also teamwork. I’ll come back to this later when discussing the management team.

Conversely, however, a manager should really only manage and not perform content work themselves.

Especially in development environments, it’s not uncommon for managers to also possess domain knowledge.

Mixing both fields of activity typically leads to poor management performance.

Although executives are often called managers, personnel responsibility is by no means a prerequisite for the manager role.

Conversely, executives can and should also manage. In fact, management activities are an essential component of every leadership role—personnel management is then added on top.

Unfortunately, I frequently observe that executive-managers only personally perform the steps “commissioning work” and “evaluating results” and either omit or delegate the other steps.

That’s not good! It’s the cause of many problems we see in companies.

All steps require the same attention, have the same priority, and must be performed by the manager themselves. If they don’t do this, they cannot deliver high-performance management.

Believe me, I’ve made this mistake myself and suffered the consequences bitterly.

I frequently observe that executives neglect goal definition and planning because they believe they don’t have time for it—or because they think everything is already clear and known anyway.

A Side Note:

Assistants are an important resource because they support executives in management and thus contribute to better management performance.

Bosses who want to eliminate assistant positions for cost reasons have not understood how top-level management works.

Project Management

The starting point of every project is goals specified by the project’s stakeholders.

To realize these project goals, two areas of activity are required:

1. Managing

2. Implementing

Managing

Just as described above, management activities must be performed in the project.

Based on this, the project plan is created, the project team is commissioned, and investment funds are released.

To control project risks, professional risk management is conducted: risks are regularly analyzed, preventive measures defined and planned.

Work results are discussed promptly within the team and with stakeholders. Confirmed results are a prerequisite for reliable and continuous maturity progression.

Implementing

A continuous alignment must take place between content activities and project management activities.

Project management takes place before the content processing of project scopes. But then accompanies the implementation activities. Goals, plans, and results must be constantly adapted to realities.

Project Management Team

The project management team consists of:

• The Project Manager

• The Project Management Master

• The Project Architect

• The Department Representatives

Depending on the size of the organization, it may make sense for the department representative—who is essentially a kind of project manager for the department—to also have a department project management master at their side.

These project roles exclusively perform project management tasks, should be freed up for these tasks, and work in only one project.

As already indicated in the heading, too many cooks spoil the broth. It’s important to have only the minimally necessary number of employees, each with a clear focus.

Only this way is it possible to ensure excellent situational awareness at all times. This is the basic prerequisite for good project management. Too many people means too many interfaces, unclear task distribution and responsibility.

Project Team

It doesn’t matter whether they are exclusively assigned to the project, work in parallel on multiple projects, or are only temporarily involved.

The number of project team members is determined solely by necessity, as determined by the project management team during planning.

The rule here is: whoever is needed is part of the team—the number of employees is determined only by necessity and therefore has no lower or upper limit.

Unlike the project management team, the project team doesn’t work exclusively on content work.

Members of the project team also take on project management tasks within their area of responsibility as part of self-responsibility and self-management.

This includes the detailed definition of goals as well as detailed planning of workflows and coordination of collaboration. As experts, they provide important input for risk management and develop the results that are confirmed in project reviews.

Project Management Office

For the Project Management Office, we need to distinguish how this term is used.

I know two different interpretations.

I just listed who belongs to the project management team. If project management supporters are also present, they also sit in the Project Management Office.

Spatial concentration in the Project Management Office is highly recommended. It enables the visualization of important project information on the walls—from project plans to risk portfolios to task boards.

At the same time, it facilitates spontaneous exchange and coordination, so that all project managers always share the same situational assessment.

The Project Management Office can also be the meeting room where project meetings take place.

The other version of a Project Management Office is independent of the actual project.

Here, company-internal project management standards are developed, defined, and brought to decision.

Training, qualifications, and experience exchange for project managers are organized. Planning and coaching experts can be pooled here, which projects can access as needed.

In addition, the PMO typically selects the project management tools, decides on their use, and adapts them to the organization’s needs.

The Project Management Office typically reports to the board of management about the state of project management in the organization.

It maintains an overview of the entire project portfolio and evaluates whether sufficient project management resources are available to professionally handle the projects.

In case of bottlenecks, it coordinates the deployment of external resources.

Project Management Support

This typically includes the following activities:

• Planning meetings

• Writing minutes

• Tracking task completion

• Updating schedules

• Preparing project status reports

• Helping project members work with the project management tool

These are administrative activities.

As the name suggests, the project management supporter is intended as assistance and capacity relief for project managers and project members.

However, one must note that delegating these administrative activities creates an additional interface between supporter and responsible person, which inevitably leads to efficiency losses.

Therefore, I favor optimizing tools, processes and user interfaces so that those responsible can smoothly handle these tasks themselves without being significantly burdened.

So if many project management supporters are needed, it’s a sign of poor tools or poor collaboration culture.

I also frequently observe that project management supporters are deployed where processes are not regulated or corresponding subject matter experts are missing.

Such situations can occur in different contexts, mostly tracking activities.

If you deploy PMSs for such activities, something is wrong with your organization.

Anyone who has their projects under control without PMSs is very likely working in a very good environment.

The need to deploy PMSs should therefore always be an occasion to carefully analyze what they’re needed for and how the situation can be improved so it works without them.

Program Management Office

Let’s conclude with the Program Management Office.

Here too, there are two different scenarios.

The Program Management Office can take on the role of the Project Management Office.

Another possibility is to spatially concentrate all program managers and platform architects in one office, thereby improving exchange and cross-program collaboration.

The situation is therefore relatively similar to the Project Management Office.

Head of PMO

I’d like to conclude by pointing out one special feature.

Project management team members, on the other hand, don’t report to the project leader but either to the PMO leader or—in the case of department representatives—to their respective department heads.

Project leaders are often called project managers, both of which suggest that they have disciplinary personnel responsibility.

I know it’s absolutely common to organizationally place project management team members under the project leader. However, this has significant disadvantages, which I’ll discuss in detail soon.

So please subscribe to my newsletter so you don’t miss these articles.

Few Steering the Ship, Many Working on Deck

I’ve only covered the selected terms in their essential features here.

Nevertheless, it should have become clear why it makes sense to have a focused and lean project management team in a project and to clearly distinguish it from the significantly larger number of project team members doing content work.

Therefore, pay close attention in my articles whether I’m talking about the project management team or the project team—these are two fundamentally different things.

If you liked the article or have questions or comments, please write them to me in the comments. I appreciate every comment.

Leave a comment

Also please write me which terms I should go into more detail about in separate articles.

Comments are the currency with which free subscribers can reward me for my efforts.

We can of course use the chat function to exchange ideas directly.

If you liked the article, please share it with others.

Share

Back When a Truck Was Just a Truck

In the first half of the last century, trucks were beautifully simple. We divided them into three categories:

• Light trucks

• Medium-duty trucks

• Heavy-duty trucks

They were universal tools. You hauled grain, coal briquettes, beer, milk, furniture, machinery—anything that needed to get from Point A to Point B found its ride on the flatbed of the same truck.

For manufacturers, the product was crystal clear.

One truck type = one bill of materials.

You knew the permissible gross weight, you knew the road conditions, and because inspections weren’t as strict back then, you built things a bit more robust just to be safe.

Life was simple.

Then Came Customer Focus

It didn’t take long for the variety of truck configurations to increase.

The original standard truck became increasingly adapted to specific use cases, body types, and customer preferences.

At first, manufacturers simply created more types. Alongside the flatbed truck, you now had semi-trailers, dump trucks, multiple wheelbase options, and various axle configurations to choose from.

Each of these types had its own bill of materials that guided production.

Sales Codes Made Diversity Even Greater

But then came the flood of additional customer requests, managed through sales codes. Customers could now select equipment details to customize their chosen base model.

Different engine ratings, transmissions, tank sizes, power take-offs, weight variants, and much, much more became available.

The truck the customer ordered was configured by the salesperson together with the customer, tailored to their specific needs.

The bill of materials that guided production was no longer predetermined by engineering.

It was now calculated algorithmically using sales codes and plus/minus bills of materials.

Each sales code had its own bill of materials with plus and minus positions.

These bills of materials modified the base vehicle bill of materials. Part numbers marked with minus were removed from the base bill of materials; part numbers marked with plus were added.

A particular challenge was that there wasn’t just one sales code per vehicle order—there could be several. So you also had to list as minus all the parts that might have just been added as plus by another code.

This way, a mainframe computer could calculate from the base bill of materials (the bill of materials for the base vehicle) to the correct bill of materials for the customer’s vehicle using Boolean algebra.

I can hardly believe it myself, but I personally wrote plus/minus bills of materials.

Not on a computer. No, with pencil on printed forms. Entering them into the mainframe was a job for specialists!

You can surely imagine that this work was extremely time-consuming and error-prone. The most-used work tool was the eraser.

Every designer had to know their scope across all vehicle variants in detail and explicitly document all possible combinations.

Inevitably, the time came when this system could no longer be maintained and was replaced by an innovation in product documentation.

This innovation was the component bill of materials.

NED – The New Engineering Documentation

With the new product documentation, base bills of materials and sales code bills of materials disappeared and were replaced by component bills of materials.

A component bill of materials contains a small number of part numbers that are always—without exception—installed together.

Each of these component bills of materials comes with a long instruction sheet of Boolean algebra, called encoding.

It describes exactly in which sales code combinations the specific component bill of materials is applied or not applied.

The original vehicle type is now just a container holding all component bills of materials that might be needed in any possible combination of sales codes.

When a customer orders a vehicle, a computer program (the variant configuration system) calculates the specific vehicle bill of materials for the customer order based on the codes selected by the salesperson together with the customer.

You can surely imagine that writing Boolean algebra for component bills of materials is not trivial. It’s probably one of the most demanding tasks a designer faces in their daily work.

But there’s one huge positive effect: Everything that fits together doesn’t need to be described!

This means that when writing Boolean algebra, the designer can and must focus on what doesn’t fit together or doesn’t work and must be redirected through encoding to a buildable and functional configuration.

In this way, a virtually infinite number of possible vehicle configurations becomes possible without having to explicitly develop and document each one beforehand.

The Modular Product Platform

The next simplification step was to standardize interfaces throughout the vehicle.

It’s logical: the more things that don’t fit together, the more must be regulated through encoding.

The next level of simplification therefore consists of designing the vehicles architecture technically so that through cleverly standardized technical interfaces, as many things as possible fit together.

Then they no longer need to be encoded in complicated ways but can be controlled with simpler code rules.

Modular concepts were developed and brought into production for all construction scopes.

Whether a combination is needed or not, it simply fits and therefore doesn’t need elaborate control.

The result:

• Fewer parts (component bills of materials)

• More possible vehicle variants

Everything Perfect?

So we’ve almost arrived in a perfect world, haven’t we?

Just add a bit of AI and machine learning to automate the remaining Boolean algebra writing, and we have everything we’ve always wanted.

The manufacturer has relatively few parts in inventory, and the customer gets any variant they want.

So everything’s perfect?

Of course, in reality, this isn’t as trivial as I’m presenting it here in simplified form.

But the basic logic is correct.

I’ll take the opportunity in many future articles to go into detail about the opportunities and challenges of this variant control.

Since it’s an extremely large topic, it would help me greatly if you’d ask questions in the comments about what interests you most urgently. Then I can address those aspects first.

Leave a comment

Please subscribe to my newsletter so you don’t miss any of the articles.

Subscribe now

How Variant Control Impacts Development Scope Management

Why did I give this whole long preamble when today I’m actually concerned with how development scopes can be controlled?

Well, it’s quite simple:

I assume that someone unfamiliar with our business in detail imagines development the way it really once was, when a truck was truly one truck.

If the truck needed to be renewed or improved, you simply took that specific truck and redeveloped or modified it.

In the current situation, that’s no longer possible, because that one truck no longer exists!

Even today, not everyone has grasped that the product of every vehicle development is no longer a truck but a truck modular platform!

And this has drastic consequences, because unfortunately this platform is incredibly large and must therefore be simultaneously modified in many places for different reasons.

These reasons include:

• New vehicle applications need to be incorporated, requiring new vehicle variants

• Legal requirements must be met, requiring either the entire platform to be modified at certain points or specific scopes to be modified for certain markets only

• Technological advancement occurs in technical systems

• Quality problems, supplier issues, or other unwanted disruptions must be eliminated

The necessities to modify the product platform are extremely diverse and require varying amounts of time.

But at all times, it must be ensured that the complete product platform functions and is customer-ready!

Because otherwise, not a single truck can be configured.

The Solution: A Four-Stage Project Architecture

To master this complicated situation, the famous elephant must be sliced.

A Key Central Element: The Project

The project bundles development scopes on the product platform that can be handled by a project organization with minimal interfaces and that follow a common timeline.

Minimal interfaces in this context means that project contents are assembled to bundle substantively related matters, thereby keeping the number of involved people and organizational units to a minimum.

For this, it must first be clear what exactly is needed. I’ve written extensively about this in my article “Getting the Timing Right: Planning Product Development Projects the Right Way.”

Typically, the need for changes to the product platform is so great that multiple projects must be organized. Otherwise the scope of work for the each project management team would become unmanageable large.

For This Whole Construct to Actually Work, Project Timelines Must Be Stable and Known for the Entire Project Duration

Classic project management is required here.

The Project Program

So that, what we’ve just separated still fits together, the newly defined projects must be combined into project programs.

All projects that have their Start of Production (SOP) in a common time period are now bundled into a program and synchronized using multi-project management methods.

This requires a small but excellent program management team that knows all affected projects with their mutual dependencies and orchestrates a structured process that maintains synchronicity.

An important detail is that the program management team coordinate the start of projects. This ensures that project timelines are sensibly synchronized from the beginning.

Since we’re developing a hardware product, prototypes must be built for testing, and these must be complete, functioning trucks.

Therefore, projects within programs must be scheduled so that there are points in time when all projects have the appropriate technical maturity to start vehicle validation.

Since we need a market cycle that’s shorter than the duration of a project program, we need multiple staggered programs.

The Drum Beat

If you’ve been faithfully following my newsletter, you already know the Drum Beat.

It ensures that the milestones and quality gates of the projects that are indispensable for a functioning program are actually achieved with the essential work statuses.

This premise is extremely important because schedule delays in one project affect the entire platform and can therefore cause all other projects in the program to run into difficulties.

That’s why schedule discipline is absolutely critical!

The ToDo Sprint

The lowest level in the program architecture is the ToDo Sprint.

Since in a matrix organization with a functional organizational structure, work from all projects and programs is processed in the same organizational units, the ToDo Sprint controls task completion.

Let me point out here that this organizational form also has something to do with the product platform landscape explained at the beginning.

As I explained, the highly variant product platform requires employees who have a complete overview of all relevant content in the segment of the product platform they’re responsible for. This knowledge is indispensable for encoding component bills of materials.

But now it’s a prerequisite that all changes to these scopes must also be made by the same team!

This isn’t just about packaging space issues but also about knowledge of customer requirements in the corresponding segments of the platform and their functional implementation, which is also reflected in the encoding.

Even if systems engineering promises to get all this under better control, it won’t work in the coming decades without highly qualified employees. Believe me.

So we organizationally bundle tasks from all projects in such a way that teams have clear priorities and the understanding of the modular product plattform will sustain.

Conclusion

Today in this article, I ventured an experiment:

I wanted to condense a highly specialized situation so that the essential logic of how product structure and project structures are connected fits into a short newsletter article.

I’m aware that you surely have many, many question marks after reading this.

So don’t hesitate to ask me questions.

This way I can target the many other aspects there are to discuss about this very large topic area.

I’d also be very interested to know if you have such constellations in your environment.

What questions do you have about modular product platforms and multi-stage project management? Share in the comments below, and I’ll address them in future articles.

Leave a comment

We can also chat about it.

I’ll dive deeper into the details in the coming articles. Please subscribe to the newsletter so you don’t miss them.

Subscribe now

If you found this helpful, don’t forget to share it with others who might enjoy it too!

Share

If my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch

For the most impatient among you, here’s the answer right away:

With the classic approach used in the past, new vehicle development took 6 to 8 years.

In the article “Getting the timing right”, I explain that in the commercial vehicle industry, it’s possible to estimate market demand over a 3 to 4-year period with reasonable accuracy.

In many cases, external influences limit the available time to just 4 to 5 years. So it has to be faster anyway, and then it’s good if there’s a plan for how to make that possible.

In this article, I will explain what project approach can achieve a short development time while still producing a proper product.

If you work in a different industry where these timeframes are different, you may still find food for thought that can help in your environment to reduce project duration to a necessary level.

I’d like to ask you to write in the comments whether you were able to find such parallels. Fair warning: this works better if you’ve actually read the article first.

Leave a comment

Why Do Classic Waterfall Projects Take So Long?

Let’s first understand why classic product development projects take so long.

Based on that, we can consider where we want to start making changes.

Classic Project Philosophy

It must be absolutely certain that large amounts are only invested and contracts are only signed when the content work is finished and the result is confirmed through complete validation.

1. New technologies are only developed when it’s certain they’re really needed in the market.

2. Suppliers are only selected and purchase prices negotiated when all technical specifications are known and their correctness is proven.

3. Costs for production tools and factory investments are only spent when the product has been successfully validated.

4. Customers and markets are only informed after project completion, so they don’t delay their purchase decision to wait for the new product.

The cost of this certainty is having to accept a long development timeline before product availability.

Well, and since everything is so certain, the investments can be high. If the business case shows a good payback, then this money is supposedly safely invested. - Or so the theory goes. -

What Are the Problems?

Let me say it right at the start: You can develop very good products with this classic approach! This has been proven in many successful projects in the past.

However, all of life is a compromise, and so is the classic approach. Often this compromise is simply not the best compromise.

Before I move on to a different approach, I want to address the problems and challenges that come with this classic approach.

Not All Assumptions Are Safe

To gain certainty, decisions need a secure data basis.

As just described, in classic vehicle development projects, this certainty is created by carefully and laboriously securing all decision premises before a decision is made.

Unfortunately, it’s impossible to do this with all premises. Some premises inevitably arise for which assumptions must be made that cannot be validated.

These premises now introduce risk into the project that it’s not prepared for and can’t handle well, because absolute risk avoidance is also a project premise.

When these risks then actually occur, they throw the project off track.

Decisions are reversed, setbacks in project flow cause time delays and excessive costs.

Changes in the Environment Create Instability

This problem is amplified by the fact that, due to the long project duration, supposedly secure premises become outdated and generate volatility that leads to the same consequences.

Sequential Work Is Always Connected with Loops

Ironically, the effort to boost efficiency by having departments wait for validated data leads to considerable rework.

• First the developers develop.

• Then the purchasers negotiate with suppliers.

• Production planners plan production next.

• At the very end, the after-sales experts figure out how the product can be repaired.

• The controllers always carefully ensure that money is only spent when everything is clear.

When specialist functions start later, they inevitably discover issues with the supposedly validated data only at a later stage.

The premises originally considered secure turn out to be wrong in the course of work, and the correction causes setbacks in project progress.

Previously completed work based on the original assumptions must now be repeated.

This causes time delays and significant inefficiencies.

The Required Time Is Not Available

The worst problem is that there’s often simply not enough time for such an approach.

Then the 6 to 8 year project plan is simply compressed like an accordion.

Now it’s over with the secure premises!

The lack of time leads to poor results that are inadequately checked.

Occurring risks are no longer a regrettable exception but a certain reality.

An organization geared toward certainty is thrown into chaos and is methodologically unable to deal with the chaos.

This is the point where task forces, freestyle, and excessive resource and time expenditure become the project management method.

Project goals are now secondary; now it’s only about being able to deliver at all.

Alternative Approach - The Super Sprint

Project Philosophy

Although it may not seem so at first glance, it doesn’t mean that more money is spent.

It only means that the supposed certainty is only proven late in the course of the project.

1. New technologies are prepared at a time when no concrete market need is yet recognizable.

2. Project goals are set conservatively and in close alignment with customers, without the expectation that the product must be offered unchanged for a long time. Quick availability and subsequent short-term further development are project premises.

3. All specialist areas work simultaneously and complete their stages at the same time. (You can read about the individual phases in DCVI in a separate article.)

4. Short-cycle planning and implementation phases enable situation-appropriate prioritization and proactive response.

Solution to the Problems

Predictive Technology Validation

Technology development takes time, there’s no way around it.

What seems like the most cost-effective approach – delaying investment until you’re absolutely sure – actually proves the most expensive.

The better approach is to engage with the technology immediately and learn for little money and on a small scale.

I’ll describe exactly how to do this in a separate article.

This phase can be completed in a few months; for large, very innovative technologies, it can take one to two years including customer feedback.

There are several important premises to maintain:

1. Everyone must participate, not just product engineering! Purchasing, production planning, after sales, even controlling must use this opportunity to acquire the necessary competence to assess and apply the new technology.

2. End customers must be involved and have the opportunity to develop qualified feedback. They must be part of the activity.

3. Over-development must not occur in this phase. When the technology is sufficiently well understood, pause until a concrete application project is started.

When the time comes that the technology is needed in the market, the product can be developed quickly and without loops based on the identified market need and good knowledge of the technology’s potential.

If the technology doesn’t meet expectations, it was better to invest little money in this realization than to bring the technology to production for expensive money because there’s no way back.

The DCVI Project - The Super Sprint

I know, I know. The agilists will criticize me. You can’t stretch a sprint over 4 years; then it’s not a sprint but something else.

Fine by me, let me call it a “super sprint” then.

Nevertheless, the approach used in a 1-week sprint also makes sense over a relatively long period.

The approach consists of 4 phases that all involved employees complete together.

1. Definition - Everyone aligns specifications with each other. I really mean “everyone”! This is an exciting phase because nobody yet knows exactly how they will solve their problems. Nevertheless, it’s important that all concepts, strategies, and premises are integrated and coordinated with each other. This is the heyday of systems engineering. At the end of this phase, everyone looks each other deep in the eyes and knows what each individual’s result must be for the product to work in the end.

2. Creation - Now everyone develops the concrete solutions. Intensive teamwork is required here as well. At the end of this phase, the product and all its accompanying processes are theoretically finished. Again, everyone looks each other in the eyes and says with deep conviction: “I’m sure this will work!” But everyone also knows that no one can be completely sure because there’s no proof yet. The certainty is based purely on the professional competence of the involved employees.

3. Validation - The product is built and tested together with all accompanying processes. From now on, only what doesn’t work is fixed, and this must happen very quickly. At the end of this phase stands the question: “Are we really finished?”

4. Implementation - Now only the process capability of the large-series process remains to be installed.

There’s naturally a lot to tell about each phase, so I’ll write separate articles about each.

The Magic Word Is: Simultaneous

For the product to be developed in half the time, no one can wait for anyone else! All specialist functions work simultaneously and continuously align their work progress with each other.

At the end of each of the 4 phases stands a milestone with a detailed review and the freezing of the work result achieved so far.

For this highly integrative working method to function, organizational prerequisites and procedures must be implemented.

A very important procedure is the Drum Beat and the project roles (project manager, project management master, product architect and functional unit representative) associated with it.

At the end of the project, or as I call it, the super sprint, stands a deliverable product.

Simultaneously, however, the next super sprint is already running, further developing the product and quickly implementing learned insights.

How Long Do the Individual Phases Last?

The secret is to take the time at the beginning to think carefully and work thoroughly in order to be fast at the end.

1. Definition - 1 year

2. Creation - 1 year

3. Validation - 1.5 years

4. Implementation - 0.5 years

We exclude technology preparation from the project timeline so that it doesn’t influence the period between project decision and series readiness.

So, the product needs 4 years from project start to series maturity.

After completion of the creative phase, the focus shifts from design to validation.

At this point, the next project already starts with its definition phase.

The customer thus receives an improved product every two years. They don’t even notice the four-year project duration.

Software Is Faster

Everything written so far considers the temporal restrictions that hardware places on the development projects of a commercial vehicle.

Software development offers the possibility of being brought to market faster. Therefore, shorter software cycles are overlaid on the hardware cycle of 2 years.

Now’s the right time to jump into the comments – I’d love to hear about similar experiences or parallels you’ve seen.

Leave a comment

We can also chat about this topic:

I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.

Subscribe now

If you found this helpful, don’t forget to share it with others who might enjoy it too!

Share

I’d be very grateful if you shared my newsletter with your friends and colleagues.

Share Uwe Mierisch

Picture this: You're the leader of an organization that desperately needs to transform. You've identified the problems, you have a vision for the future, and you're ready to make it happen. But here's the brutal truth—most transformation efforts fail not because of bad ideas, but because of bad organization.

As a leader, my job isn't just to spot what needs fixing. It's to analyze my organization, leverage our strengths, address our weaknesses, paint a clear and realistic picture of where we're headed, and—when fundamental transformation is necessary—make sure it actually succeeds.

That's what real leadership looks like.

Over the years, I've tried countless approaches to transformation. Some worked brilliantly, others crashed and burned. But the most recent transformations I've led have validated a core framework that I want to share with you today.

Every organization, every team, and every challenge is unique. But certain principles hold true across the board—and knowing when to be flexible is just as crucial as knowing what never changes.

The Top Management Dilemma: Three Levels of Executive Engagement

Let's start with an uncomfortable truth:

I think we can all agree on that.

But here's where it gets tricky—what role should top management actually play?

There are three main approaches, and each comes with its own set of challenges and opportunities.

Option 1: The CEO-Led Transformation (The Gold Standard)

This is my number one recommendation because it's simply the most effective approach I've seen.

When the CEO or a managing director personally leads the transformation—not just announces it, but actually rolls up their sleeves and works alongside the team on both the vision and execution—something magical happens.

Credibility becomes unshakeable. Priority and focus become automatic.

But here's the catch: the leadership team must invest significant time working with the entire organization, not just a select group of elite employees.

This approach is common in startups, and I've experienced it firsthand as a member of a startup's executive team.

The efficiency is remarkable, which is why I strongly recommend choosing this option whenever possible.

Of course, in the real world, there are plenty of reasons why this ideal scenario rarely happens. Which brings us to...

Option 2: Top Management as the Principal

Here, top management appoints a transformation manager and team that has their absolute trust. And I mean absolute—this trust is the foundation that makes or breaks this model.

Management and the transformation team must speak with one voice and give the transformation identical priority.

Even in this setup, leadership can't completely step back.

They need to invest enough time to stay aligned with the transformation team and demonstrate the transformation in their own leadership behavior.

When the organization sees this united front between leadership and the transformation team, acceptance follows.

Option 3: Top Management as Participant (The Nightmare Scenario)

The scenario goes like this:

Everyone agrees transformation is necessary. Leadership is willing to provide resources—people and money. But they don't see themselves as part of the problem.

"The people down there need to transform. I'm fine and can keep doing what I've always done."

Here's the harsh reality: in every transformation, top management is always affected and must transform their own thinking and behavior.

In this situation, the transformation team must work on two levels simultaneously:

• Achieving transformation with top management

• Implementing transformation with the workforce

The real killer? The workforce picks up on mixed signals from leadership, which compromises the entire effort's credibility.

If you're a transformation manager in this situation, don't lose heart.

You'll need unbreakable optimism, but I can tell you from experience: it can work.

It's exhausting, you'll face countless frustrating phases, and it takes much longer than the other scenarios—but it's possible.

Pro tip: Don't be fooled by lip service. Top management rarely admits this attitude openly. Judge them by their actions and adapt your approach accordingly.

Building The Transformation Dream Team

The Transformation Manager is the brain of the operation. They define strategy and make tactical implementation decisions.

The other team members discuss strategies with the manager, organize operational execution, and communicate throughout the organization.

Here's what's non-negotiable:

The transformation manager must be an opinion leader in your organization. Not in the sense that "everyone likes them," but in the sense that "when they speak, people listen."

This usually requires seniority, though I've seen young professionals build this kind of standing too.

Regardless of how leadership views the transformation, the transformation manager must have the complete personal trust of top management.

The nature of transformation means no one can know exactly what needs to be done or where the journey will ultimately lead.

Your transformation team needs solid baseline qualifications in the domain being transformed, keeping them at least two steps ahead of the organization in the learning process.

Simultaneously, they must possess the leadership qualities necessary to guide an organization without being able to present a detailed roadmap.

The Consultant Question

Two or three people aren't enough to transform an organization. At the same time, transformation is temporary—it shouldn't become a permanent state.

Even though consultants aren't cheap, don't be stingy here.

Usually, your company's future is at stake—you must invest sufficiently to make success possible, even when creating a business case and payback calculation is challenging.

The Middle Management Make-or-Break Factor

Here's a truth that might surprise you:

• They're deeply involved in business processes enough to understand and help shape change.

• They have the leadership experience and hierarchical power to get their employees on board.

• But they also have significant influence upward. It's unlikely that top management will ignore middle management's opinions—if trust isn't there, the middle manager gets replaced. So you can assume the people in these positions have their bosses' ears.

Your transformation team and middle management must pull in the same direction for organizational transformation to succeed.

Take middle management seriously and give them your full attention. They're the critical factor determining success or failure.

To ensure middle managers invest sufficient time in transformation while still handling day-to-day business, you must especially appreciate and focus on those with intrinsic interest in the topic.

They're your gold nuggets—guard them carefully so they don't get lost.

Project Organization: Creating Structure in Chaos

Consider which organizational units are represented by whom in your transformation project. Form sub-projects and appoint selected middle managers as sub-project leaders.

Even though transformation isn't strictly a project (because goals and endpoints are unclear), you can and should use project management structures.

I won't propose specific structures here since they depend heavily on your concrete situation. But if you want to discuss your specific scenario with me, send me a message or write in the comments, and we'll find time to talk.

The Communication Imperative

The final crucial pillar in your transformation framework is communication.

• Communicate what you're planning

• Communicate successes

• Communicate lessons learned

• Communicate immediate next steps

• Communicate who's doing what

• Communicate parallels to transformations in other organizations

• Communicate praise

• And more...

Your transformation must always be part of the conversation, everywhere.

Use every communication channel available in your organization:

• Intranet

• Email

• Town halls

• Quarterly calls

• Newsletters

• Communities

• Training sessions

• And more

But use one communication form extensively: Talk to people. Discuss.

Approach people in hallways, in the coffee kitchen, take them to lunch and talk about the transformation.

Go into different functional areas and face the criticism—it will come, that's certain.

Meet criticism constructively with a positive attitude, even when it might be unfair. It offers you an irreplaceable opportunity to get your arguments across and have people's attention.

Don't get discouraged if you don't win every debate. Trust me, over time the desired effect will emerge—people will become more open to transformation and eventually start participating or even helping to shape it.

But you must pay the price of investing incredible amounts of time in discussions and communication.

The bottom line? Transformation isn't just about having a great vision—it's about building the organizational framework that can actually deliver that vision. Get the structure right, and change becomes inevitable. Get it wrong, and even the best ideas will crumble.

If you have questions or suggestions, please write them in the comments.

Leave a comment

We can also chat.

Would you rather message me directly?

I'll dive deeper into project management practices in the coming articles. Please subscribe to the newsletter so you don't miss them.

Subscribe now

If my newsletter resonates with you, please consider sharing it with others.

Agile project management is based on Scrum.

That's how it all started, so let's introduce Sprint meetings and Scrum boards first.

Once that works, we can scale up and think about the higher complexity in projects.

Makes sense, right? That's why I often see teams taking this approach.

Noooo, that's not the right way to do it!

I used to do something similar myself. Back then it wasn't called Scrum - it was called Shop Floor Meeting.

But I found that it didn't really solve the problem. We still had issues with the quality of our development projects.

So in this article, I'll describe how to do it better - a way that actually makes the problems go away.

Starting Point

I think it's important to thoroughly analyze the starting situation before any project, change, or transformation.

So let's recap what we have and what we want to achieve with the Drum Beat method.

We use classic project management in our projects, just like it says in the IPMA textbooks.

Well, we say we work according to IPMA. In the end, it's probably more like freestyle.

• We have a project plan,

• project managers,

• project team members,

• and defined project roles.

• We also have quality gates,

• milestones,

• and quality gate deliverables.

• We have project traffic lights,

• reporting,

• risk management,

• and project documentation.

That's good news because it means we don't have to start from zero. There's a foundation we can build on, even if it's not perfect yet.

What were the problems I wanted to avoid with the Drum Beat method?

• The project plan doesn't work as desired.

• Deliverables for quality gates and milestones are delivered poorly.

• Project budgets and timelines get out of control.

• Quality and performance of the developed product is compromised.

The next step was to identify the root causes of these problems and define countermeasures.

These countermeasures are the processes and roles I've explained in my previous Drum Beat articles.

To find the smartest implementation approach, I need to look at these causes again and prioritize them.

I can't tackle everything at once - that would overwhelm people in the organization and possibly ruin the whole implementation.

Here's the prioritized list of causes:

1. Project milestones are too long-term and too big

2. Poor prioritization of project activities by importance

3. Too late identification and correction of plan deviations

4. Poor resource management

5. Poor coordination of project activities between service providers and recipients

Based on this analysis, I can now stagger the introduction of Drum Beat elements over time. This way, I first create the prerequisites that enable the implementation of further process steps.

Here's how it works:

Step 0: Project Plan and Project Team

As I mentioned at the beginning, the project plan and project team already exist.

The project plan is good enough to provide guidance for how the project should flow, and the project team is motivated to implement the plan.

That's enough as a foundation for the start. We won't waste energy improving this now - we need to work on more important issues first.

Only later, when the team has a clear understanding of what Drum Beats and ToDo Sprints can deliver, will we have the foundation to take the project plan to the next level.

Step 1: Define Drum Beat Deliverables

The change starts with Drum Beat Deliverables.

Only when Drum Beat Deliverables have sufficient quality can the other process steps produce meaningful results.

For this reason, the project management team must first learn how to derive and properly formulate Drum Beat Deliverables from the overall project plan and the current project status.

This isn't easy when you've never done it before. That's why it's important to support this implementation step with trained resources.

We need people who already know how to do this and can provide guidance and assistance to the project management team.

The transformation team itself needs to be involved in the planning and provide guidance to the team.

Usually, this manpower won't be enough either. We also need external consultants with agile project management training.

So everyone speaks with one voice, the transformation team and consultants must align their concepts before planning begins and agree on a common understanding. It's recommended to practice Drum Beat planning beforehand.

On this basis, both can now work together with project team members to define Drum Beat Deliverables and develop the templates I described in my article "Drum Beat Deliverables Create Clarity - and Deliver the Truly Relevant Results."

You will notice that Drum Beat Deliverables show strong qualitative improvement over the first three to four Drum Beats.

I recommend adjusting the method slightly after each Drum Beat.

In this case too, you should do a retrospective after each Drum Beat and implement what you learned in the very next Drum Beat.

Even though the following process steps aren't implemented yet, you'll still notice an improvement in project work. This is important because it promotes acceptance of the method.

Step 2: Conduct Planning Event

At the beginning, this will also be organized and moderated by the transformation team and consultants.

The entire project management team is present. The functional area representatives on the project management team take on the role of functional area teams in one person.

We don't want too many people involved at the start so it stays manageable during this rough phase.

We pay the price that the actual project team isn't involved yet and can only be informed about the results afterward.

It's clear this leads to poor understanding and commitment from the project team. We have to accept this.

The priority is first to enable the core project management team and establish an initial content foundation.

Step 3: Implement Project Roles

For this, we need to implement the new project roles.

Usually, the project will already have a project manager.

So we need to select, train, and coach:

• a Project Management Master,

• a Project Architect,

• and Functional Unit Representatives

We also need to redistribute responsibilities.

The project manager gets relief and focuses more on project content flow, while the Project Management Master takes responsibility for the method and the architect for the product.

The transformation team and consultants step back more and more, hand over responsibility for the process to project team members, and only support when necessary.

Step 4: Implement ToDo Sprints in Pilot Teams

Now we've created the foundation.

The Drum Beat Deliverables have quality that reliably provides guidance, and the project management team can independently plan, formulate, and manage DBDs.

The transformation team and consultants shift their focus from the project team to the functional area teams.

Project team employees now need to plan the activities required to realize Drum Beat Deliverables into ToDo Sprints.

This needs the same kind of support at the beginning as we organized for the project management team in step 2.

Since support resources are limited, we focus on selected pilot teams at first.

We identify teams that are particularly relevant to project results and whose employees are open to the new method.

These teams are now also included in Drum Beat Deliverable planning and planning events.

Even though only the pilot teams are currently implementing ToDo Sprint planning, all other project employees are already being trained. This way they are prepared for the next step and won't have forgotten what they learned when they need it.

Step 5: Roll Out ToDo Sprints Completely

In the next step, our pilot teams serve as role models for the rest of the organization's employees.

The pilot teams' ToDo Sprint backlogs serve as examples, and pilot team members are available as contacts for other teams.

This significantly increases the number of employees available for guidance, so we can provide adequate support to all employees despite limited resources from the transformation team and external consultants.

Step 6: Dashboards

Now all process steps are implemented.

Of course, we've had DBD and ToDo boards available and used them in our project management tool from the beginning.

But now the focus shifts from the content of DBDs and ToDos to their flow.

The transformation team and consultants now support the project team in working with the boards:

• Are DBDs and ToDos properly moved from “Backlog” to "In Process" and "Done"?

• Is the "Roadblock" column used correctly?

• How does the team work with statistics?

• Are emerging delays addressed in time?

The implementation focus shifts from planning to execution.

Step 7: Perfect Project Plan

So the new process steps are now implemented.

Now we can return to the project plan and adapt it to the new method.

It should provide guidance for DBD planning but not create duplication in planning.

I like to refer to an old engineering rule. Maybe some of you still know this rule, even though it comes from a time when technical drawings were still drawn with ink on transparent paper:

"Each dimension may only exist once!"

The background is that contradictions are avoided by having no duplications. If a dimension exists only once, it can be wrong but not contradictory.

This principle also applies very well to planning and avoids one cause of misunderstandings.

It means each task should only exist once in planning. What's in the project plan shouldn't be in the Drum Beat backlog, and vice versa.

7 Steps Take Time

So I've divided the implementation into seven logically connected steps.

Due to agile thinking, there's a retrospective after each Drum Beat, and we improve the identified potential in each following Drum Beat, so we become better, more efficient, and more effective.

Want to introduce Drum Beat in your organization and still have questions?

Write them in the comments and I'll try to answer them to your satisfaction.

Leave a comment

We can also chat.

Would you rather message me directly?

I'll dive deeper into project management practices in the coming articles. Please subscribe to the newsletter so you don't miss them.

Subscribe now

If my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch

As a product development leader, I regularly attend project review meetings where we discuss the status of important product development projects. In these meetings, project teams typically present two very different types of topics to top management:

1. Technical Concepts and Product Performance Reports

For these agenda items, project teams seek management confirmation and approval for technical approaches and performance metrics. In these cases, management takes an active role in the decision-making process, providing valuable input, strategic direction, and meaningful oversight that actually adds value to the project.

2. Project Delays and Missing Results

The second type of agenda items puts management in a completely different role. Here, project delays and missing deliverables are presented in detail. Teams explain what went wrong and outline their plan to mitigate the consequences of this mess. These presentations carry an undertone of: "We want you to know how critical the situation is. Don't be surprised if things ultimately go wrong - everything we're doing is without alternatives because lost time cannot be recovered. We hope the plan works, but you can't help us anyway." There's not even an expectation that leadership can still help. And believe me, these agenda items are no fun for management!

To change this situation for the better, I've been exploring how to prevent it from happening in the first place.

However, if they do arise, the goal should be to present decision alternatives to management early enough so their decisions help prevent problems from escalating in the first place.

If we succeed in this, management will have a positive value contribution for both types of agenda items. And ideally, the project team will solve problems early enough that many of them will not need to be reported at all.

One aspect of the solution is the "Drum Beat" that I've introduced in previous articles. This helps project management teams plan more realistically, recognize project risks earlier and proactively avoid problems through better planning.

The other important aspect that needs to be addressed is guaranteeing proactive work management in functional departments. Since project content is created in functional areas, these employees must be included in solving the problem.

The method to achieve this is the ToDo-Sprint - designed to make task processing more prophylactic, effective, and integrated. I'll focus on this aspect in today's article.

But first, let me dive deeper into the fundamental root causes of project delays. I'll explain the causes I've identified so you can consider whether these might also exist in your organization.

From these causes, you'll understand why a combination of Kanban and Scrum can solve the problem.

Multitasking Needs Clear Priorities

I work in a matrix organization.

In my article "Mastering the Matrix" I wrote about the special characteristics this involves. Take a look at that article - it should help you to understand this point better.

When project organization (as process organization) and functional organization (as structural organization) are arranged in a matrix, there's typically no unique assignment of employees to projects. A functional team works simultaneously, but with different intensities, across multiple projects.

Without a process to synchronize, prioritize, and organize all these tasks - as was the case with us - tasks remain uncoordinated. The affected project learns too late what won't be delivered in time, putting it into a reactive mode where it shouldn't be.

We need a working mode that ensures project-wide planning of all activities within functional area teams.

Employees plan their activities together in short cycles, considering the concrete situation as it currently exists.

To avoid ineffective multitasking, we need "timely dedication" - temporary focus on a single activity planned so that all important results for all projects can be delivered.

This means that while work may be done on multiple activities for different projects within a sprint, at any specific time (hour, day) work is done on only one task. Only when that's completed is the next one tackled.

The "Roadblock" category signals urgent support needs for the team.

With this approach, emerging problems are recognizable on a quarterly or weekly basis, and solutions can be sought and found proactively before time runs out.

Capacity is Objective

The truth is brutal and unavoidable: capacity is finite.

Because this insight is so uncomfortable, management tends to use the ostrich method - sticking their heads in the sand and preferring not to talk about it.

"They'll figure it out somehow. They should just try harder, then it'll work."

This attitude puts management in the position of later sitting helplessly in project reviews, feeling bad anyway.

I'll explore what decision options management has in these situations in a future article.

But to even be able to decide, there must be a planning process where these cases are uncovered early and prophylactically, showing the team and the management the decision alternatives.

The Scrum approach also helps with this problem.

Since planning occurs over short-term intervals (quarter, week), resource availability is easily assessable. The workload is also concrete since the status quo on which the activity builds is clearly on the table.

Functional area management must engage with the results of Scrum planning and either make necessary decisions immediately or acknowledge decisions the team has made and consider them in leadership actions.

Avoiding Interrupted Flow

Nothing is more frustrating than having to wait for input and helplessly watching your own deadline wobble because you can't work on the topic.

That's why it's helpful to look during planning at who needs what when from whom, so inputs are available at exactly the right time.

When coordination between affected colleagues (I call them service provider and service recipient) isn't organized and methodically structured, workflow stagnates.

"It was obvious I needed that. It's always like that. You should have known."

"We talked about it - why didn't you do it?"

Here I draw on the pull principle from Kanban.

For this to work well, there are some rules to follow.

ToDo Sprint Rules

1. Each employee is personally responsible for ensuring that required inputs are clearly and unambiguously defined and communicated to contributing colleagues.

2. Inputs are scheduled so results are available exactly when needed for further processing. This creates no inventory and results aren't overtaken by time.

3. Each team member plans their own activities. When a task is scheduled, it signals a commitment that it will actually be completed.

4. The requester is responsible for scheduling with the service provider. If they can't agree with the service provider, they must seek alternatives or organize escalation. (Escalation isn't negative here - it's involving additional resources to solve the problem.)

5. Tasks with no requester are omitted. (What nobody needs doesn't get done.)

6. When problems emerge during processing, the service provider must immediately contact the requester and involve them in solving the problem. (Maybe it can be done with less after all.)

Point three is especially important to me because it ensures that whoever has to do something has actually "bought" that assignment - firmly committed to actually doing it.

The ToDo Sprint Process

The ToDo Sprint approach isn't rocket science and resembles many known frameworks.

1. Drum Beats are divided into one- or two-week ToDo-Sprints, each getting a backlog with tasks to be completed in each sprint.

2. During Drum Beat planning, these backlogs are filled for each sprint of the Drum Beat.

3. During Drum Beat planning, resource availability and task dependencies are also considered.

4. By PED (Planning Event Drum Beat), there's an initially filled backlog for all ToDo-Sprints of the new Drum Beat.

5. Each new ToDO-Sprint starts with a review of the previous sprint.

6. Based on review results and current project situation, the backlog for the coming ToDo-Sprint is updated and refined.

7. ToDo-Sprint planning is discussed in functional area regular communication.

8. After completing ToDo-Sprint planning for the current sprint, each team member independently moves their tasks into "In Progress" and "Done" columns.

9. When a team member moves a task to "Roadblock," line supervisors and the Drum Beat Deliverable Owner step in and support resolving the roadblock.

I haven't tried it yet, but I'm still considering setting up a parking area on the ToDo Board where requesters can park their required inputs for backlog planning.

It's also not enough to just describe the task - the expected outcome of the activity must be clearly defined between the service provider and service recipient on the ToDo Board.

How much detail to include is something both parties must decide together. What's important is that they agree on the required result. I believe the more detailed it's written down, the more confident you can be that you truly understand each other.

The ToDo Sprint Combines Agile Sprint and Lean Kanban

Features from Agile Sprint:

• Fixed timeframe

• Team plans work for the coming sprint together

• All tasks are visible to all participants

• Shared understanding of goals and progress

• Regular review of work results and processes

• Early recognition of deviations

• Immediate correction when problems are identified

Features from Lean Kanban:

• Pull principle - only tasks that meet concrete needs are completed

• Focus on continuous flow - all activities are scheduled so no "inventory" or "overproduction" occurs

• Each backlog item represents a deliverable

In this article, I've described how project work in functional organizations can be organized so that threatening project delays are recognized early and prevented as much as possible.

I'm sure there will be many more questions about this. If you have questions about this topic, don't hesitate to ask them in the comments.

Leave a comment

We can also explore your questions in chat or via DM.

I'll dive deeper into project management practices in the coming articles. Please subscribe to the newsletter so you don't miss them.

Subscribe now

If my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch

There are moments in work life that you never forget.

I experienced one of these moments when we introduced our first Drum Beat in a pilot project.

The project team sat together in a meeting, planning the Drum Beat deliverables.

Everything should have been sorted out. Now we just needed to wait for everything to be implemented, and then we could celebrate our first successful Drum Beat.

The review day arrived, and the project team gathered to check off the Drum Beat results.

That's when a project management team member, who had taken responsibility for a Drum Beat deliverable, said:

"I didn't communicate the Drum Beat Deliverable to the project team because it's nonsense anyway. I had them work on the things that are really important."

I was shattered. My world collapsed.

But looking closer, I realized we had made serious mistakes in our Drum Beat planning.

Just quickly sitting together and writing something down isn't a sustainable planning process and doesn't create commitment.

Since I believe you must learn from your mistakes, we developed a concept for how Drum Beat planning must be organized to be complete, realistic, and reliable.

In this article, I'll introduce you to this concept, hoping you can avoid the negative experiences I had.

It’s a five-step process.

Drum Beat Planning isn’t something you can do in a single day.

It’s a process that takes several days.

The exact duration depends on:

• the complexity of the project,

• the size of the project team,

• and the experience of the project management team.

You should plan for at least one week. In many cases, more time is needed. However, it should not take longer than four weeks.

In the following sections, I will explain each stage so that you gain a solid understanding of the entire process.

Review

For inexperienced teams, this is already the first emotional moment:

"Leave me alone. I still have time until the Drum Beat ends."

"I don't have time to explain in detail where I stand. I need to hurry to get finished."

Sound familiar? Does this happen with your teams, or does it only happen in my environment?

Write me your experience in the comments.

Leave a comment

In my case, training helped.

The entire Drum Beat Process must be taught to all team members so that they understand the context of this exercise.

Then you have to take the teams by the hand and just do it. After a few repetitions, the value of the approach becomes clear, and resistance fades.

It is a fact that the project management team needs to get an overview of where the project stands before starting a new planning round.

It doesn't matter whether the work is already finished or not.

Shortly before the Drum Beat ends, you can already estimate pretty well where things are heading.

Will people manage to complete the Drum Beat Deliverables, or are shortcomings and spillovers already showing?

The review happens in well-organized meetings where service providers and service recipients jointly assess the situation, and the project management team gets a complete overview of all DBDs.

Based on this, the actual planning can begin.

Planning as Individual Work

In the next step, I usually encounter the next big challenge.

Everyone constantly complains about sitting in too many meetings.

But as soon as the planning phase starts, the project leader calls the first meetings to plan together.

I haven't figured out why this happens:

• Do people believe they'll achieve better results together?

• Do they want to save the time of individual work?

• Do they think the results of quiet work are flawed?

What's your opinion? Do you observe the same tendency? Do you have a theory about why this happens?

In my experience, planning in quiet isolation is a very important stage because it fosters a deep understanding of processes and priorities.

I like to say jokingly: "When the project management team finishes the plan, they can immediately throw it away."

That's why the project leader and every member of the project management team must take time to become clear about what exactly needs to be done in the next stage.

For this work step, project management team members need the following information:

• The review results:

  • Are there catch up items?

  • Are there any problems that need to be solved?

  • Have priorities changed over the last period?

• The project description with the project goals.

• The project plan with its Quality Gate Dates and Deliverables.

• A planning template listing the Drum Beat Deliverables typically relevant in this project phase.

Ideally, this information should be provided in the form of a central planning document.

As an additional information source, it's possible to ask individual project team members for advice.

I also recommend peer coaching - getting opinions from employees from other projects.

However, everyone should do this individually according to their own needs, rather than in large meetings.

The result of this planning step is a DBD backlog with all DBDs that each project management team member has planned.

The DBD templates, as I presented in my last article, should be filled out in a first draft.

This planning phase should be very short. The goal isn't to make perfect planning - it's about each individual developing a basic understanding of the further process.

Prioritization

While creating the Drum Beat backlog, it it is advisable to prioritize the Drum Beat Deliverables.

Since prioritising is always a matter of judgement, I suggest the following procedure:

• The newly found deliverable is first written at the bottom of the backlog.

• Then you evaluate whether the deliverable above is more important than the newly entered one.

• If the answer is “No”, the more important deliverable moves up one position and the process repeats.

• If the answer is "Yes," the order remains, and prioritizing the new DBD is complete.

Swarm Intelligence Comes into Play

Planning meetings are organised, during which the leadership team creates a common Drum Beat Deliverable backlog based on their individual functional experience and perspective.

The DBDs are sharpened, priorities are agreed on.

Now attention is also paid to available resources:

• Can the team handle all of this?

• Which compromises make sense and which don't?

• What are the effects of the compromises?

• What influence do these effects have on the Drum Beat planning of the current and future Drum Beats?

This stage of Drum Beat planning can't be completed in one day. To ensure everything is evaluated and nothing is forgotten, several days of planning are necessary here. Consultation with the project team is now more intensive.

At the end of this phase stands the prioritized backlog of Drum Beat Deliverables for the new Drum Beat with formulated Drum Beat Deliverables and assigned responsibilities.

I just wrote "consultation of the project team." But these words contain emotional volatility once again.

Direction versus Grassroots Democracy

Yes, there's the management philosophy that the team should find its own way and management should stay completely out of it.

My experience with this approach isn't good.

If you ask a team of 1,000 people for their opinion, you will get 1,000 answers. These 1,000 people will always agree that there is insufficient time and too few resources to successfully complete the project.

Then 1,000 pairs of eyes look at you questioningly and signal: Project leader, now tell us how you want to solve this Gordian knot.

I know what I'm saying now is controversial. If you disagree, please write it in the comments. I'm curious about alternative suggestions.

Leave a comment

I expect the project management team (6 to 10 people) to find the right Drum Beat Deliverables and formulate them accurately. If they can't do this, they're the wrong people.

I expect the project team to find a way to complete the necessary Drum Beat Deliverables with available resources in the available time.

Since my second expectation also needs a plan, the next phase of Drum Beat planning must follow.

The Project Team Plans Its Activities

Since we're now dealing with not just a handful of people, but many hundreds or even several thousand, many planning workshops now take place in parallel.

Each work team now plans its concrete approach to completing the Drum Beat Deliverables.

The focus is now on coordinating all sub-steps with each other:

• Who needs what, when, from whom?

• What exactly is needed?

• What exactly will be done when by whom?

• Are the prerequisites available?

• If prerequisites aren't given, who can create the prerequisites?

• Which matter must be decided by whom during the Drum Beat so work can proceed without delay?

The process is organized and moderated by the project team member responsible for the respective Drum Beat Deliverable.

The line supervisors of the functional departments must be involved in this planning phase.

It's important that they know what their people have planned for the Drum Beat, what capacities are needed, and what contribution they must make.

Here again lies an emotional challenge.

I experience that this isn't easy for some - not to say many - top managers to accept.

Of course, the project management team is allowed to adjust its DBD backlog or individual DBDs if it realizes during planning that this makes sense. However, the decision to do this lies solely with the project management team.

Putting the Finishing Touch - in the PED

The PED (Planning Event for the Drum Beat) represents the conclusion of planning.

Since very, very large project teams are involved in vehicle development projects, it's usually not possible to gather everyone in one place.

That's why it's important to very consciously select and invite participants.

The criterion is the question of which people must make the most important contribution for the next Drum Beat.

These can be project team members but also line supervisors.

The project management team is naturally always there.

The PED has a standardized process:

1. The project leader communicates the overarching goal of the Drum Beat.

2. Each Drum Beat responsible person briefly presents their Drum Beat Deliverable and asks if there are still open points that urgently need clarification. These points are recorded and scheduled for breakout sessions.

3. In breakout sessions, the affected team members clarify the open points.

4. The Drum Beat planning is formally concluded.

Now It Begins

If planning is conducted according to this process, it should no longer happen that project members question the plan, as happened to me in my first Drum Beat.

Nevertheless, not all questions are clarified and all problems solved with the PED.

For this reason, the ToDo’s written down in Drum Beat planning represent only a starting point.

From now on, all work teams look at their ToDo’s every two weeks and make the planning more concrete.

There are regular short planning meetings for this during the curse of the Drum Beat.

How working with ToDo’s in the functional departments works in detail will be examined more closely in my next article.

Do you have questions about this? Then don't hesitate to ask them in the comments—I'll try to answer them to the best of my knowledge.

Leave a comment

We can also chat.

I'll dive deeper into the details in the coming articles. Please subscribe to the newsletter so you don't miss them.

Subscribe now

If my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch

For many years, I had a metric on my shopfloor board that was probably very unusual. At least I don't know any other manager who worked with this KPI.

It was the "task completion speed" – the duration until completion of tasks that my management team had put on their task list.

The primary goal wasn't to work faster. It was explicitly allowed to optimize this metric by simply taking on easier and shorter-term tasks if it contributed to finishing faster.

I must admit that this metric was the most difficult one on the entire shopfloor board. It lay like a rock on the ocean floor.

Task completion duration took forever and was more influenced by tasks becoming obsolete over time than by them being completed.

The target value remained unreachably distant, and we continued discussing progress weekly without tasks being finished.

Anyone who knows me knows that once I'm convinced of something, I have a long breath to pursue it.

This is also true for my conviction that it's helpful to focus on the short-cycle finalization of intermediate results. Therefore, I set myself the task of making this a core value of the organization.

The Drum Beat, which I introduced in the last article, aims in this direction.

It's about cleverly planning short-term milestone goals and supporting implementation through processes.

I learned something important:

It works better when intermediate goals are not set by the person affected themselves, but when they emerge in the context of joint planning.

Logically, I also set intermediate goals for myself when introducing the Drum Beat – I'll tell you more about that in one of the next articles.

In this article, I want to go into more detail about the Drum Beat Deliverable, which I will abbreviate as DBD going forward, and explain how it should be designed so that it fulfills the purpose of realizing the right short-term results.

Requirements for Drum Beat Deliverables

Let's first look at what requirements such a Drum Beat Deliverable must fulfill so that it can deliver its added value.

As Godehard Gerling (Managing Director of go3consulting) correctly formulated, a milestone goal should be selected according to two criteria.

“Plan the things that:

1. Currently contribute the greatest added value to achieving the project goals.

2. Will hurt us the most tomorrow if we don't take care of them right now.

The Drum Beat Deliverable must primarily ensure effectiveness. It's about doing exactly the important things at the right point in time.

For this, service providers must coordinate very precisely with service recipients about what exactly is needed.

In the planning process, the DBD should facilitate necessary coordination by providing guidance that systematically addresses all relevant questions with the team.

Throughout implementation, the DBD must help to recognize target deviations early and to find corrective actions.

For this, there must be a responsible person who coordinates necessary activities and escalates if necessary.

From these requirements, information is derived that must be documented in the Drum Beat Deliverable.

What Information Must Be Contained in a DBD?

For the Drum Beat Deliverable to be implemented safely and efficiently, it must include critical information and convey it clearly to everyone involved.

This information includes:

• Result to be achieved

• Acceptance criteria for validating the completion

• Necessary prerequisites for processing

• Information about stakeholders who will continue working with this result or who need it

• Risks that could stand in the way

• The project member who takes responsibility for implementing the Drum Beat Deliverable

• The project members involved in implementation

This information is written down in a form.

The process of filling out the form ensures that all necessary discussions take place in a structured and methodical manner.

Here's what a Drum Beat Deliverable form can look like:

I will now explain each individual point in detail.

Title

This is not easy and requires careful consideration. But it's the most important step of all.

The title must clearly state what exactly should be finished at the end of the Drum Beat, and for this, you must first be clear about what is necessary and what is possible.

The search for the right title for the DBD is the actual core of Drum Beat planning.

As a rule, all DBDs of a Drum Beat are listed in a list.

In the overview of the list, usually only the title of the Drum Beat Deliverable and its responsible person are visible.

Therefore, it's important that the title is self-explanatory.

I frequently observe that when breaking down longer-term Quality Gate Deliverables, there's a tendency to split them into smaller packages and call these Drum Beat Deliverables. (I call this the longitudinal splitting of Quality Gate Deliverables)

Take as an example the splitting of the Quality Gate Deliverable "Maturity Level B Release".

Longitudinal splitting would look like this:

• Maturity Level B Release Cab

• Maturity Level B Release Chassis

• etc.

But that's not what we want.

The idea is to divide the lengthy timeframe into bite-sized intervals, essentially creating a temporal cross-section (transversal splitting) of the Quality Gate Deliverable.

The search for these intermediate results is, especially for inexperienced project teams, a challenge.

Here's the example for the correct splitting of "Maturity Level B Release":

Drum Beat 1 – Development suppliers are selected and operational

Drum Beat 2 – First system design is completed

Drum Beat 3 – Basic function development is completed

Etc.

Now you can of course also split longitudinally in addition, and that's sometimes even practical. This way, very extensive DBDs can be reduced and responsibilities can be better assigned.

For example, you can write these DBDs for chassis and cab:

Drum Beat 1 – Development suppliers for chassis components are selected and operational

Drum Beat 1 – Development suppliers for cab components are selected and operational

Drum Beat 2 – First system design for chassis is completed

Drum Beat 2 – First system design for cab is completed

Drum Beat 3 – Basic function development for chassis is completed

Drum Beat 3 – Basic function development for cab is completed

It can go even smaller by referencing each individual sub-system. However, there's a danger that too many DBDs emerge that can no longer be overseen in terms of quantity.

Therefore, it must be evaluated with a sense of proportion how many DBDs represent the best compromise between quantity and size.

I would say that up to 20 DBDs per Drum Beat are well manageable. With more DBDs, it becomes more difficult and only works with an experienced and well-coordinated project team.

In any case, it must be ensured that not too many DBDs are assigned to each responsible person simultaneously.

If the organization is obviously overwhelmed with the number of necessary DBDs, then the project content must be reduced by stretching the project timeline.

Here, it's better to have part of the product portfolio finished quickly and deliver the rest gradually, than to have everything at once but at a later point in time.

The opinion that you can increase the quantity of achieved results by putting pressure on the project team is a widespread but fatal misjudgment.

The Responsible

This brings us to the Drum Beat Deliverable responsible person.

They must ensure that all necessary ToDos are planned, executed, and completed.

If problems occur, they organize support, bring teams together to identify solutions, and make decisions to re-establish flow.

As a rule, Drum Beat Deliverable responsible persons are members of the project management team.

It's also possible to select project team members, but then careful attention must be paid that taking on coordination doesn't prevent them from completing their own work.

Confidence Level

If it's "High" or "Reasonable", then the project management team can trust that the project team will complete the DBD self-managed and reliably.

If it's "Moderate" or "Low", then the project management team must become active and analyze and eliminate the reasons for the low probability of success. It's a call for help from the project team.

The Confidence Level can change over the course of the Drum Beat.

If a DBD starts with "Moderate" or "Low", then measures must be implemented short-term that raise the Confidence Level to "High" or "Reasonable".

Likewise, it can happen that during processing the team's confidence becomes lower and the project management team must intervene.

Drum Beat

There's the possibility to also enter Drum Beat Deliverables in the Drum Beat Backlog that should be processed in a later Drum Beat.

For completed DBDs, it's documented here in which of the past Drum Beats the DBD was completed.

Recipient

This information is important because it enables exchange with the right people to ensure that exactly the right and goal-oriented work is being done and no misinterpretations can lead to inefficiency and delay.

Even in internal work, it's very important to always keep the "customer" in view and be in exchange with them to ensure that the developed solution really addresses their need.

The question about the recipient also prevents activities from being completed because "that's how it's always been done". If no recipient with need can be found, then the effort is pointless and must be avoided.

QG Deliverable

Status

There are the following statuses the DBD can be in:

• Backlog

• In Planning

• In Progress

• Done

• Blocked

• Spill Over

Most are self-explanatory.

Backlog DBDs are parked for future Drum Beats.

"Blocked" is an alarm signal because it signals that processing of the DBD is halted because there's a serious problem that cannot be solved by the team itself.

"Spill Over" means that this DBD could not be completed in its Drum Beat and therefore had to be rescheduled.

Description / Intent

At this point, it's better to write more rather than too little. The more information from the planning phase is documented here, the more goal-oriented work can be.

Definition of Done

The form in which this confirmation takes place should also be established.

• These can be reviews in which the result is evaluated.

• It can also be confirmation from the recipient or from selected experts.

• Likewise, defining an objective target value is a good Definition of Done when it's possible. For example, 100% of all planned bills of materials are released.

Definition of Ready

When all prerequisites are in place, processing of the DBD can begin, though attention must be paid throughout to ensure no decisions undermine these initial conditions.

Incomplete prerequisites affect the Confidence Level. The team must decide whether to proceed with processing anyway and if missing prerequisites can be resolved short-term.

If that's not the case, then the scope of the DBD must be adjusted. Maybe it's possible with less after all.

Under no circumstances may processing start according to the principle "hope for a miracle".

If prerequisites are not available, a decision must already be made in Drum Beat planning about how to deal with the then inevitably occurring problem.

Risks / Impediments

If significant risks are recognized, they are included in project risk management and processed there.

If they are small risks, they are written down here so that attention can be paid during the course of Drum Beat Deliverable processing in case it develops worse than expected.

Participants

An Example

So much for theory.

Here's an example of how such a Drum Beat Deliverable can look like.

Do you have questions about this? Then don't hesitate to ask them in the comments—I'll try to answer them to the best of my knowledge.

Leave a comment

We can also chat.

I'll dive deeper into the details in the coming articles. Please subscribe to the newsletter so you don't miss them.

Subscribe now

If my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch

There's something strange about vehicle development projects: they span years—yet time is always too short.

Whether it was a complete redesign of the entire product portfolio or just a minor facelift, the pattern was always the same.

• It starts off rocky.

• The further the project progresses, the more my daily work transforms into pure chaos: task forces I suddenly find myself in, top management reviews that stress me out week after week, and micromanagement that drives me crazy.

• What was planned as a structured project turns into complete chaos that somehow, miraculously, still gets finished in a halfway decent manner.

Do you recognize this pattern too?

After years of this experience, I decided to get to the bottom of it.

I analyzed why this happens—and developed a solution approach that can break this death spiral.

The Problem Lies in Understanding What Exactly Needs to Be Done

For this reason, creating this project plan is one of the first activities that must be carried out by the project team.

But is the entire project team really involved?

No, usually not! ...and with that, we already have the problem on the table.

Such a plan doesn't emerge from a blank sheet of paper.

There's usually a generic planning template as the starting document, which forms the company standard for development projects. (This planning guideline is often called the "development system.")

If you want me to go into detail about the development system, write it in the comments.

Leave a comment

It's mandatorily prescribed as a process document in quality systems, regularly audited, and its application is verified.

In this template, the important interdisciplinary dependencies in the project flow are pre-conceived and documented, common project management methods are applied, and experiences from past projects are incorporated.

On this basis, the concrete project plan is now worked out by the project manager and employees who are experts for project plans.

What does "worked out" mean exactly?

Typically, the ideal initial plan is compressed, squeezed, and tasks are parallelized until the desired or management-specified series introduction date appears achievable.

- So now the plan is finished. -

The dates for quality gates are set, deliverables are described, and important milestones are planned.

Now we can get started.

Everyone knows what to do. "We're not doing this for the first time" is the motto.

People know the company standard—this can certainly be assumed.

The fact that the concrete project plan no longer has much in common with the planning template is supposedly no cause for concern. If something is unclear to someone, they can just ask.

(You probably caught the irony right away—but sadly, this is often how things actually play out.)

The first surprise comes at the first quality gate:

Unfortunately, not everything that was planned has been completed.

There are always good reasons:

• "The time was too short to accomplish everything. That was actually always clear, but nobody listened to me."

• "The capacity wasn't sufficient for everything. There were too many other important priorities that prevented me from completing the work."

• "I didn't get the input from my colleague that I needed. It should have been clear to him that I needed it. It was implicitly in the plan. The project manager should have taken care of that."

• "Necessary decisions weren't made or were made too late. Management is never available when needed."

Now it is what it is, and we have to deal with the delays.

"Latecomer dates” are coordinated, and tracking systems are established to monitor their completion. ( In German language “Nachzüglertermine”)

Additionally, the project plan must now be re-planned because time can't be turned back.

The effort for rework and re-planning consumes the resources needed for the next task.

From now on, it only gets worse.

The Root Cause Lies in Poor Coordination and Poorly Detailed Planning

This is important and, in my view, indispensable.

However, if you expect it to map every detailed coordination between all employees involved in the project, it won't be able to meet this expectation.

Attempting to do so leads to the justified criticism that project plans are bureaucratic, confusing, unrealistic, and detached from reality. This is a criticism that the founding members of agile product development also addressed.

Who can plan years in advance what exactly and in detail must happen on which day or in which week? That's unrealistic, and attempting to do so leads to waste of time because things will turn out differently than planned anyway.

However, this fact must not lead to these detailed plannings not taking place at all.

Continuous Alignment Is Not Optimal

Usually, these discussions and detailed planning take place continuously during project work.

Project team members instinctively recognize the importance of these clarifications.

Therefore, permanent consultations take place between the project management team and the line areas, and employees also coordinate with each other.

The results are found in employees' heads, in meeting minutes, and in various tracking tools.

What's the problem with this?

I've actually found several problems:

1. This detailed planning takes place uncoordinated. Therefore, there's no certainty that all necessary planning is covered.

2. There’s no shared understanding of the agreements, as they tend to occur bilaterally or within small groups. As a result, affected parties are often neither involved nor adequately informed due to lack of awareness.

3. Since work continues in parallel, agreements are often outdated before their implementation can begin.

4. When decisions are necessary, they can only be made in relation to the one isolated case currently under discussion. For this reason, resource problems are particularly difficult to quantify, and prioritization occurs on incomplete data. The big picture overview is missing.

The Drum Beat Is the Solution

The Drum Beat replaces simultaneous planning and execution with three sequential, regularly repeating phases carried out by the entire project team simultaneously.

1. Planning activities for the upcoming three months.

2. Implementing the planned activities.

3. Reviewing status and closing activities.

Through the Drum Beat, the project consolidation points represented by quality gates in the classical model are supplemented by more frequent consolidation points.

Due to the short planning period, both high quality and realistic planning can be reliably guaranteed.

How Long Does a Drum Beat Last?

The length of the Drum Beat depends on the complexity of the project organization and the team's ability to plan quickly and precisely.

The ratio of planning time to implementation time must be in a healthy balance.

If the planning phase takes several weeks due to many detailed consultations and an inexperienced team, then the Drum Beat should span 3 months.

If the project environment is more simple and the team is experienced so that planning can occur in a few days, then the Drum Beat can be shortened to 2 months.

Drum Beat Deliverables

A project needs a clear goal.

Every quality gate demands transparency about what must be completed by then. The required status is described in the form of QG deliverables in the development system.

They are derived from the overarching project plan and reflect the concrete temporal and content-related necessities of the project at the respective Drum Beat point in time.

Unlike quality gate deliverables, they are not generic but tailored to the concrete project and its current status.

I'll address Drum Beat Deliverables in one of my next articles.

Please subscribe to my newsletter so you don't miss it.

Subscribe now

To-Do Planning

While Drum Beat Deliverables must be defined as concrete results, ToDo’s can be planned as activities to be executed.

However, within the framework of collegial coordination, it must be ensured that the affected team members agree on the concrete content of the contributions so that implementation is realistic and delivery will occur reliably.

The duration of a ToDo sprint is one week for a 2-month Drum Beat and two weeks for a 3-month Drum Beat.

Here again, a good ratio between planning time and implementation time must be maintained.

Reviewing Status and Closing Activities

At the end of the Drum Beat, the project team collectively examines what has been achieved.

• Have all Drum Beat Deliverables been completed?

• What does the concrete result look like?

• Can it be frozen as a basis for further work?

The review forms the starting point for planning the following Drum Beat.

And of course, a retrospective belongs here too:

"How did it go, and can we do something better in the next Drum Beat?"

With a well-coordinated team, planning is so precise that planned results are achieved with high reliability.

If compromises are necessary to enable the achievement of results, they are negotiated and decided during Drum Beat planning, and their consequences are considered in further planning.

Spill Overs

Despite strong focus on reliable delivery of agreed work results, it will always happen that something hasn't been completed.

We call this a "Spill Over."

It's important not to simply push these matters forward. They must be re-planned.

The first question is whether this activity, now delayed, is even still meaningful at this point.

In any case, we must prevent the first schedule delay from becoming a chain of schedule delays.

The goal must be that by the end of the next Drum Beat, the delay is caught up and no impact on the overarching project plan occurs.

Why Drum Beat and Not PI?

Isn't the Drum Beat simply a PI as defined in agile project management methods?

The answer is: Yes and No.

Just like a PI, the Drum Beat is short-cycle planning that follows a strictly prescribed schema.

The sequence of planning, implementation, and review/retrospective is the same.

However, at the end of the Drum Beat, there's no ready-to-ship product that generates short-cycle customer feedback and thus provides new insights for further development of the product.

This isn't realizable with a hardware product like a vehicle.

In this regard, the Drum Beat is more comparable to a classical quality gate.

It represents a milestone on the path to the next quality gate, just as the quality gate is a milestone on the path to the project goal.

However, the Drum Beat isn't planned out from the beginning of the project like the quality gate.

I would describe the Drum Beat as a hybrid mixture of PI and quality gate that realizes the advantages of agile approaches under the special restrictions and premises of a hardware development process.

After reading this article, many questions are going through your head?

Then don't hesitate to ask them in the comments—I'll try to answer them to the best of my knowledge.

Leave a comment

We can also chat about this topic.

I'll dive deeper into the details in the coming articles. Please subscribe to the newsletter so you don't miss them.

Subscribe now

If you found this helpful, don't forget to share it with others who might enjoy it too!

Share

If my newsletter resonates with you, please consider sharing it with others.

Share Uwe Mierisch