Shh, don’t talk out loud about PLM!

Phew, as a PLM fan you had to take a deep breath last week: Two well-known bloggers lowered their thumbs in the headlines: Joe Barkai: “Why I Don’t Do PLM” and Oleg Shilovitsky: “Are PLM conferences dead?

Curiously, both pull on the opposite ends of the rope. For Barkai, the classic view of PLM as a “single version of the truth” falls short, while Shilovitsky conjures up the basics behind the PLM idea.

Barkai: „I find it fascinating that traditional PLM software vendors are not realizing how the Internet of Things and the connected enterprise are breathing a new life into the PLM space that does not quite know how to reinvent itself. After decades of using enterprise PLM software, it is still common to hear at a PLM conference a speaker announcing, “Let me give you my definition of PLM.” Or those never-ending debates about eBOMs and mBOMs and where PDM ends and PLM begins.“

Shilovitsky: “I know many people struggling with their PLM decisions and fighting alone to balance tools, budgets, organizational and cultural changes and timelines. Companies are struggling with very basics things – Part Numbers, Change Management, Revisions, and others. To discuss the real problems, can be an opportunity. This is the foundation – the story. This is a single unit… If a single unit doesn’t sell, making it broader or scaling it up won’t solve the problem.”

To be honest, depending on which colleagues I talk to in our company, it could turn out similar. But there is one thing we are all pretty sure about: Writing PLM in bold on an invitation or an advertisement takes some courage these days.

So are the best times of PLM over?

Companies survive in the market because they listen to their customers and adapt their offer to new requirements and possibilities in good time! Yes, the basics are still the low-hanging fruits, and the pioneers are taking care of the more demanding potentials in the product lifecycle, where the integration of disciplines, tools and processes is at stake. Some PLM providers, for example, are using their experience and their current portfolio around the virtual product to expand their offering towards the internet of things and the digital twin.

This highlights the dilemma: PLM, unlike ERP or financial accounting, has never been a self-runner. The PLM idea has always had to be particularly convincingly motivated by the sponsors.

And this has often not been successful, as my colleague Rolf Stübbe puts it in a nutshell in his blog post “20 years of PLM: Why do many still doubt the benefits“: “Despite the renewed increase in attention for PLM, I notice that the term still has a large, cumbersome, tedious and uneconomical flavour. Supposed lighthouse projects such as the almost endless Teamcenter introduction at VW and Dassault’s licensing policy, which was one of the reasons for the Code of PLM Openness Initiative, are representative of the many pinpricks that have tarnished the reputation of PLM over time.


It’s like Monty Python in the Fawlty Towers episode of “The Germans”: “Don’t mention the war!” PLM: Everyone thinks about it, but everyone tries to avoid the term. 

Yet times have never been better for the PLM idea than today. The pressure in companies is high and continues to rise in order to take advantage of the opportunities offered by the digital transformation. But storytelling must get better. The old stories and complicated definitions are certainly no longer suitable, and the PLM concept as an advertising medium is only of limited use. Storytelling and project marketing belong together right from the start. It starts with the goals. Here I am with Oleg Shilovitsky: we shouldn’t throw out the baby with the bathwater. Crude promises and obscure visions that are doomed to failure do not help, on the contrary. It is better to package the low hanging fruits attractively, give the project a meaningful name and do everything possible to ensure that the initial, manageable goals are achieved.

Agile physical product development?

My last blog post was about teams that only become really agile through experience. Today, the focus is on the challenges that agility brings to engineering.

Almost 20 years after the Agile Manifesto, agile software development has become widely accepted. It is no longer about whether, but only about best practices in detail and agile scalability. The success and ease of use of task boards, for example, have led to agile procedures also finding enthusiastic users outside software development where tasks are processed in a team.

This finally led to the increasingly intensively discussed question of whether physical products could also be developed more efficiently with an agile approach.


For many years, there have been established product development processes that have reached great maturity and support successful development. Why abandon them and take on the risks of a completely new approach?

The more unclear the requirements on the product are and the less known the technology to be used, the less suitable classical project management methods are, because they are very strongly forward-planning. It is precisely this tendency to start projects despite initially incomplete requirements that we are increasingly observing. Digitization and new technologies require new business models or new technological capabilities. This speaks for an agile approach, as it was invented to deal with ambiguity and not-yet-knowledge.

Is that even possible?

The decisive question here is: Are agile methods from software development at all suitable for mastering the challenges of “classical” product development? In contrast to software, physical products are developed with a much greater division of labour. The production of faulty components causes high consequential costs and the validation depends on physical prototypes. It is not possible to present a new, functioning and potentially deliverable stand every two weeks. Solutions for such problems require a creative further development of the known agile process models. A very simple example: The teams of different domains use different sprint durations. While the software team delivers every 2 weeks, the mechanics team delivers every 6 weeks. It is important to synchronize the sprints so that a common increment is achieved every 6 weeks.

The challenge

The challenge of introducing agile methods is therefore twofold: On the one hand, it is necessary to adapt the agile methods from software development to the conditions in product development. On the other hand – and this brings me back to my previous contribution – a lot of agile experience is needed to successfully make such adjustments. In order to resolve this contradiction, one should bring together the pioneers who dare to venture into new territory with experienced “agilicans” who master their craft in software development. Mutual learning and sharing of knowledge leads to a better mastery of product development under rapidly changing conditions.

Black Box IoT?

Who wants to buy a pig in a poke? Especially when you are entering completely new territory with it… The first stroller, for example: you are already aware that you need it, but the decision between a small pack format or the bicycle trailer combination is more difficult.

The last time I bought a baby carriage was some time ago (now I am an expert in buying skateboards). But if you’re just about to make a choice, I recommend a dark model, because you can’t see the dirt so clearly.

An IoT system is usually not as sensitive to dirt, but its selection is all the more complex. Especially since many companies are breaking new ground with it and can already despair of the selection of the right criteria.

Here I have two good news for you. First: Which IoT solution fits is easy to try out. A Proof of Concept is a very good way to test a solution without major risks before you decide on a system. And secondly, as much as IoT offers new opportunities, smart business processes are based on good old business virtues:

  1. Are you sure what your IoT business will look like and that it will stay that way for a long time? Probably not. IoT is a very volatile market where a lot is happening right now. So your IoT system needs to be responsive and best adaptable by the business department itself. The keyword behind this is “low code”, which means no time-consuming programming to map your processes. And if that’s not enough, the system should be so modular that you can simply “reload” additional components.

  2. Does your IoT business emerge on the greenfield or does it expand your existing business? If the second is the case, then your IoT system should be able to talk to the rest of the IT world in your company: Spare parts orders, for example, should generally have passed through financial accounting once. Open or even certified interfaces are the most important thing here as well.

  3. Do you manufacture industrial goods? Do you also have to do with spare parts and maintenance? Then your new best friend in IoT new territory becomes the “Digital Twin”. But only if it’ s also suitable for industrial use: it must be able to map the components of your system in detail (preferably with the corresponding 3D model), know the current parameters such as software statuses and, in particular, be able to document changes after maintenance or conversion.

To be honest, the connection of devices is usually only a question of fiddling, but usually not a fundamental problem. Step by step, standard protocols for machine-to-machine (M2M) communication such as MQTT (Message Queuing Telemetry Transport) or OPC/UA (Unified Architecture) are gaining acceptance and making life easier for everyone involved.

So: Just try it out with a Proof of Concept! If you also pay attention to the three touchstones, you’re in the running. Then the possibilities of “Analytics”, “Big Data”, “Data Driven Processes” or “Predictive Maintenance” are open to you.