Are Projects Still Needed or an Old-Fashioned Relic of Yesterday?
Part 3: Balancing Agile and Project Management in Mechatronics
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.
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:
This process applies to both — hardware development AND software development.
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.
If you have any comments or feedback on this topic, please write them in the comments.
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!
And if my newsletter resonates with you, please consider sharing it with others.