You are currently browsing the category archive for the ‘collaboration’ category.
In nearly twenty years of coaching PLM implementations, I’ve noticed something striking: these projects often mirror politics—not just in complexity, but in the blame game that follows when things go wrong.
When something goes wrong, people rarely see it as an opportunity to solve the issue together. They look for someone to blame instead.
That happens in politics and in Product Lifecycle Management. I wrote about it in 2019, The PLM Blame Game—and most of those observations still hold—although the emphasis has shifted.
But what if the real issue isn’t the system or the technology? What if it’s the human connections—or lack thereof—that determine success?
Political systems/ PLM approaches
In democracies, everyone debates priorities, but progress is slow. Stakeholders defend their own interests, consultants favor preferred solutions, and vendors promise the moon. Long-term plans such as digital transformation often stall.
The result is familiar: each leadership change resets ambitions, leaving users with mixed messages and less commitment – sounds familiar in PLM?.
Then there are the autocracies, where a single dominant view determines the path. Usually, that view comes not from the CEO but from the CFO or CIO. These leaders often have a limited understanding of product lifecycle management and instead rely on trusted networks.
That is why some companies choose SAP because “all enterprises run on SAP” or Teamcenter because “everyone in automotive uses Teamcenter.” Strategic consultants reinforce the same pattern with their own preferred solutions.
The result: Surface-level alignment, but resistance beneath the surface—another familiar PLM scenario.
In smaller companies, a populist version often appears. Without a strong strategic layer, the loudest voices from vendors and implementers shape the company’s view. That is the riskiest setup because vision and strategy are effectively outsourced. Early in my career, I often heard:
“You know solution XYZ, so tell us what to do.”
The result is predictable: no one in the company feels a true sense of ownership of the business outcome – the type of situations I have been mediating the most.

Of course, the analogy is imperfect. Countries usually lack competition, so citizens cannot simply switch. Still, it is a useful way to frame what happens in PLM.
They – not us – are the problem!
In the past, debates focused on who was to blame for project problems, often blaming the stakeholder who was not at the table.
Vendors and implementers blamed customers, vendors and customers blamed implementers, and implementers blamed vendors. My role in PLM mediations was to get everyone into the same room.
But one issue always remained:
Blaming the customer is difficult when the customer is assumed to be right – They are paying the bill and not always with pleasure.
Why 70 % of PLM implementations fail – or not?
For decades, we have heard horror stories about failed PLM implementations, each supposedly explained by one simple cause.
Depending on who tells the story, the culprit is the software, the company culture, poor user involvement, or unrealistic ambitions without a budget or understanding.
But the truth is more nuanced: many of these implementations did not actually fail completely.
People react strongly to the word failure because no one wants to be associated with it.
![]()
Yet, in software, ‘failing fast’ is often celebrated—it’s a way to adapt early. PLM is slowly catching on, with the rise of Minimum Viable Product (MVP) approaches. Instead of waiting for a ‘perfect’ big-bang rollout, companies now start with a working foundation and iterate as needs emerge.”
That only works if the company owns its vision and strategy. An MVP approach also demands end-to-end stakeholder involvement, because everyone contributes to the solution. At the same time, our limbic brain works against us: it pushes us to protect what we know and react strongly to change.
That reaction shows up in PLM projects too. The loudest critics get the most attention, which makes it easy to conclude a program failed—even when it is working for most people who have adapted to the change.
And now, a new trend has emerged:
PLM systems are failing!
Now, a new claim is gaining traction: PLM systems themselves are failing. With the rise of AI, traditional vendors are being blamed for failing to provide the right infrastructure or opportunities for AI-enabled capabilities.

After years of success built on legacy platforms, vendors now face growing pressure from opinion leaders calling for change.
Martin Eigner has made this point in several posts:
- Why We’re “Optimizing” Problems We Created Ourselves
- 50 % failure rate is not an accident
- My vision for the next 5 years
Oleg Shilovitsky has made similar arguments:
- Did We Solve PLM, or Just Learn How to Describe It?
- Who can replace the big three PLM and why that may be the wrong question in the Age of AI?
- Is Product Memory Just a New Name for PLM?
Prof. Dr. Jörg W. Fischer wrote:
- Will we ever solve PLM? We did, but AI has taken over.
- Digitalization has failed to deliver on its central promise! Why?
Doug Macdonald wrote about the shortcomings of Legacy PLM, which most companies imagine/practice:
- The shortcomings of Legacy PLM
- Could you manage the development of a toothbrush in a Legacy PLM system
I agree with much of this critique, for sure, if you still consider PLM a system rather than a product lifecycle management strategy implemented through a federated infrastructure of systems.
The posts I referred to highlight real problems from the past and suggest that new insights and AI might help us build better businesses. The question is whether that promise will be fulfilled.
Creating the human thread
AI could help businesses break through organizational silos by pulling together information across functions.
That would make concepts such as the digital thread and digital twin easier to implement without relying on dedicated interfaces.
This shift creates both opportunity and risk.
If AI reduces the need for siloed optimization, traditional middle-management roles will change. The key question is whether companies are willing to rethink their structures or stay constrained by Conway’s Law.
It could also make many methodology debates less important.
Today, we as consultants often promote methodologies shaped by our own experience or vendor narratives. The long-running eBOM–mBOM debate is a good example. Across industries and platforms, the answer is often more straightforward than the discussion suggests.
As AI absorbs more collective knowledge, the role of PLM experts and consultants will shift. At the Share PLM Summit in Jerez, we discussed what should come next: a stronger focus on human connection.
That is why I use the term human thread: the network of relationships that connects people across the business. Michael Finochario (Fino) touches on the same shift in his post on the changing balance between humans and technology, in his review of my session in Jerez.
Others are moving in the same direction. This week, Helene Älander shared a post that makes a similar point.
Helene’s post and the related discussion suggest a growing belief that transformation depends less on technology alone and more on human connection and motivation inside the company.
A quote from Helene’s post, and I recommend reading the full post and thread.
One lesson has stayed with me ever since:
Transformation rarely fails because of technology. It slows down when the distance between executive ambition and middle-management reality becomes too large.
For now, I call this the need for the human thread. A successful transformation starts with an end-to-end human connection across the business, with people treating that connection as a shared priority.
Because people are intrinsically motivated by a human connection.
The human thread requires a new approach, new forms of workshops and learning sessions where leaders, managers, and employees work together on the desired business flow.
Helene Älander points in this direction, and Share PLM supports it through initiatives such as Share The Nest.
Also this year at the Share PLM Summit in Jerez, Andreas Wank described how Pepperl+Fuchs made a breakthrough by bringing people together. As Fino in his review post quoted:
No one on the team wanted to make a decision because every decision affected someone else. So they put 30 people in one room for a week and forced them to make decisions. Not perfect decisions. Working hypotheses. That was a critical insight: In PLM, waiting for perfect certainty kills momentum.
The year before, at the 2025 Share PLM Summit, Andrea Järvrén already shared a similar lesson, describing how Tetra Pak used design sprints to advance its PLM work by prioritizing human interaction.
It is an unstoppable trend – the human thread popping up in more and more conversations.
Conclusion
The time for blaming systems, technology, and methodology should fade into the background. Companies need to focus on building business flow through the human thread—the human connections that drive commitment, motivation, and change.
So, here is the question: Are we ready to stop blaming systems and start building the human thread? Or will we keep repeating the same patterns, just with fancier technology?

Recently, I have been reading some interesting posts beyond all the technical discussions related to PLM and AI. Is PLM becoming obsolete? Are we heading to a new type of infrastructure based on MCP agents? Are these agents an example of new ways of collaboration?
Collaboration – it pops up everywhere!
Chad Jackson wrote about the results of their Lifecycle Insights MBSE survey. For me, MBSE is the starting point for a modern product portfolio containing products based on hardware and software. MBSE is also a great example of working in what I call the connected mode.
Here is a quote from the article that triggered me:
The 𝐧𝐮𝐦𝐛𝐞𝐫 𝐨𝐧𝐞 𝐫𝐞𝐚𝐬𝐨𝐧 organizations deploy MBSE is not simulation or architecture development. It is 𝐞𝐧𝐡𝐚𝐧𝐜𝐞𝐝 𝐜𝐨𝐥𝐥𝐚𝐛𝐨𝐫𝐚𝐭𝐢𝐨𝐧 𝐚𝐧𝐝 𝐜𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧 — at 67%. But here is the uncomfortable part.
Only 24% reported actually achieving collaboration as a business outcome. That is a 43-point gap between intent and result. Traceability is even worse — 48% deploy MBSE for it, 9% say they have realized it.
What if the problem is not that MBSE fails to deliver collaboration — but that most organizations 𝐧𝐞𝐯𝐞𝐫 𝐝𝐞𝐟𝐢𝐧𝐞 𝐰𝐡𝐚𝐭 𝐛𝐞𝐭𝐭𝐞𝐫 𝐜𝐨𝐥𝐥𝐚𝐛𝐨𝐫𝐚𝐭𝐢𝐨𝐧 𝐥𝐨𝐨𝐤𝐬 𝐥𝐢𝐤𝐞 in measurable terms?
Chad Jackson’s article aligns with many other discussions I had with companies related to PLM (and MBSE) – itinspired me to focus this time on collaboration.
How do we measure collaboration?
My 2015 blog post has the same title: How do you measure collaboration? The post was written at a time when PLM collaboration had to compete with ERP execution stories. Often, engineering collaboration was considered an inefficient process to be fixed in the future, according to some ERP vendors.
ERP always had a strong voice at the management level—boxes on an org chart, reporting lines, clear ownership and KPIs flowing upward. You could see how the company was performing.
From the management side, accountability flows downward. The architecture of the organization mirrors the architecture of the product, and the architecture of the product mirrors the architecture of the organization.
We have known this for decades; it is Conway’s Law. Yet we are still surprised when silos emerge exactly where we designed them.
The Management Dilemma
In many of my engagements, the company’s management often struggles to understand the value of collaboration because there is no direct line between collaboration and immediate performance. Revenue can be measured. Cycle times can be measured. Defects can be measured. Even employee turnover can be measured.
But collaboration? What is the KPI?
It is a fair question. If something cannot be quantified, it becomes subjective and depends on gut feelings. And if it cannot be tied directly to quarterly results, it often becomes optional.
The problem is not that collaboration has no impact on performance – look at the introduction of email in companies. Did your company make a business case for that?
Still, it improved collaboration a lot, and sometimes it became a burden with all the CC-messages and epistles exchanged.
Collaboration has an impact, deeply and systematically. But its impact is indirect, delayed, and distributed. It reduces friction, can improve shared understanding and prevent expensive rework.
The return on investment on collaboration is real, but it does not show up as a clean, linear metric.
For a hierarchical and linearly structured organization, horizontal collaboration is often hard to “sell.”
Back to Conway’s Law
Organizational structure shapes communication patterns. Communication patterns shape systems.
If your organization is vertical, your product will be vertical. If your incentives are local, your decisions will be local. If your teams are isolated, your solutions will be fragmented.
You cannot expect horizontal behavior from a vertically optimized structure without friction.
Disconnected collaboration initiatives fail because they try to overlay horizontal tools on top of vertical incentives.
Attempts like a new collaboration platform or using shared workspace technology to incentivize collaboration are examples of this approach.
But the underlying structure remains untouched. People are still measured on local performance. Budgets are still allocated per department. Promotions still reward vertical success.
First question to ask in your company: Who is responsible for your PLM/collaboration infrastructure for non-transactional information?
Most likely, it is in the IT or Engineering silo, rarely on a higher organizational level.
And then we are surprised when collaboration stalls?
The Myth of the Tool
Whenever collaboration becomes a pain, people look for IT tools as a cure.
“We need better platforms.”
“We need integrated systems.”
and now:
“We need AI – the AI agents will do the collaboration for us.”
Tools matter, but they are amplifiers. They amplify existing behavior. They do not create it. While finalizing this article, I saw this post from Dr. Sebastian Wernicke coming in, containing this quote:
Agents are software. Maturity is culture. And culture, inconveniently, doesn’t come with an install package.
If trust is low, a collaboration platform becomes a battlefield. If incentives are misaligned, shared dashboards become weapons. If fear dominates, transparency becomes a threat.
Collaboration is not a software problem. It is a human problem. Which brings us to something that is rarely discussed in boardrooms: the intrinsic motivation of its employees.
The Limbic Brain Is Always There
Beneath the rational layer of strategy and planning sits something older: the limbic system. The part of us that cares about belonging, safety, recognition, autonomy, and purpose.
Collaboration thrives when the limbic brain’s needs are met. It collapses when they are threatened.
- If people feel unsafe, they protect information!
- If they feel undervalued, they withdraw effort!
- If they feel controlled, they resist alignment!
You cannot mandate collaboration if the emotional system of the organization is defensive.
The question is not “How do we force collaboration?”
The question is “How do we create conditions where collaboration feels natural?”
And that requires leaders to connect to the human, not just to the role or an artificial intelligence solution. They should be inspired by this iconic image from Share PLM:

Besides a difficult-to-quantify ROI, there is another reason why collaboration struggles to gain executive traction: it rarely creates immediate success.
It prevents future failure, and we humans in general do not prioritize prevention, thinking of our environmental, financial and potential even health behavior. Where prevention has the lowest cost, most of the time, fixing the damage lies in our nature.
For companies, it is easier to celebrate the hero who fixes a late-stage integration disaster than the quiet team that prevented it months earlier through cross-functional dialogue.
For me, the firefighters are the biggest challenge to successfully implementing a PLM infrastructure. The image to the left comes from a 2014 presentation when discussing potential resistance to a successful PLM implementation.
In vertical systems, firefighting is visible. Prevention is silent and therefore collaboration activities feel like a cost center rather than a strategic lever.
Where to Push, Where to Invest?
If you cannot directly measure collaboration, where should you push? Not in tools alone, slogans or one-off workshops. Invest in shared experiences.
When people meet outside their vertical silos, something subtle shifts. They see faces instead of functions. They understand constraints instead of assuming incompetence. They replace narratives with conversations.
Note: shared experiences are not the same as planned online webmeetings that became popular during and after COVID. They have a rigid regime of collaboration enforcement, back-to-back in many companies, most of the time lacking the typical “coffee machine” experiences.
Also, when looking at events where people share experiences, there is a difference between a traditional vertical PLM/CM/IT/ERP conference where specialists focus on one discipline and on the other side, a human-centric conference, where humans share their experiences in an organization.
The Share PLM Summit in May last year was an eye-opener for me. Starting from the human perspective brought a lot of energy and willingness to discuss various insights – collaboration at its best.
Events, summits, workshops—when done well—create human connection. They remind participants that behind every deliverable sits a person trying to do meaningful work.
The focus on the human perspective is not soft. It is strategic because collaboration is not primarily about information exchange. It is about relationship quality and trust.
The Real Question
The question is not whether collaboration is valuable. The question is whether we are willing to adjust our vertical incentives to make it possible.
Because collaboration is not free, it requires time. It requires emotional energy. It requires psychological safety. It sometimes requires giving up local control for global benefit.
In systems terms, it requires shifting from local optimization to whole-system optimization.
That is uncomfortable.
But if our products are complex, interconnected, and rapidly evolving—as most are today—then vertical thinking alone is no longer sufficient. The world has become horizontal, even if our org charts have not.
And perhaps the real challenge is not how to measure collaboration, but how to design organizations where collaboration is no longer something we need to sell at all. An article from McKinsey might inspire you here for this transition – for me, it did: Toward an integrated technology operating model.
Beyond AI
While everyone talks and writes about AI, I do not believe AI will solve the collaboration issue. For sure, AI collaboration with agents will increase personal and organizational effectiveness, but it never touches our limbic brain, the irreplaceable part that makes us typical humans and unique.
There will always be a need for that, unless we become numb and addicted to the AI environments. There are various studies popping up on how AI “untrains” our brain muscles, reduces patience and deep thinking. Finding a new human balance is crucial.
Conclusion
Triggered by Chad Jackson’s post about MBSE and collaboration, I took the time to deep-dive into the aspects of collaboration in the PLM domain. How do you manage collaboration?
Come and share your experiences at the upcoming Share PLM 2026 summit from 19-20 May in Jerez. The title of my keynote: Are Humans Still Resources? Agentic AI and the Future of Work and PLM.







Hi Jos, Knowing your background in methodology and education, I wanted to share a longer article with you: “What is…
Interesting reflection, Jos. In my experience, the situation you describe is very recognizable. At the company where I work, sustainability…
[…] (The following post from PLM Green Global Alliance cofounder Jos Voskuil first appeared in his European PLM-focused blog HERE.) […]
[…] recent discussions in the PLM ecosystem, including PSC Transition Technologies (EcoPLM), CIMPA PLM services (LCA), and the Design for…
Jos, all interesting and relevant. There are additional elements to be mentioned and Ontologies seem to be one of the…