The comments on my article about the history of PDM and PLM took the discussion further than I expected, and they sharpened my position. PLM was real, but its value has to be assessed through the work it delivered and the effort required to sustain that result, not through the label, the marketing, or sweeping claims in either direction.
I asked readers what their early systems managed, and they brought in document control at Atari, plant databases, manufacturing instructions, CAD integration projects, and Excel. They also disagreed, sometimes sharply, about what the software could actually do, and that disagreement is worth examining, because the same product name can refer to different releases, configurations, integrations, and customer experiences. A history written from a vendor’s perspective can look different from one written by a customer trying to make a particular assembly open correctly.
The Capabilities Existed Before the PLM Label
Alongside the disagreements, there was an important point of agreement. Doug Macdonald recalled that Sherpa already supported item lifecycle management, workflow, BOM and change management, and MRP integration in 1990, and Brion Carroll agreed that the broader offering existed before it was grouped under the PLM label. I want to check the period documents, but the agreement itself helps sharpen the question. If these capabilities already existed, we should be careful about drawing a clean line between PDM as file storage and PLM as the arrival of lifecycle management, because the name and the capabilities did not necessarily change together. That supports Doug’s criticism of the naming story, but it does not establish that the work customers needed was imaginary, or that everything delivered afterward was unchanged.
Bobb Omel’s account makes the business need concrete. He described managing Document Control and Drafting at Atari in the 1980s, where an engineer on his team developed a system to track parts and documents and then added the ECO process. In his recollection, the effort began with the work they needed to control, and neither of them came from marketing or sales. Mark Reisig described another path through drawings, databases, and plant assets, while David Thomson and Christian Barlach pointed to plant and ship design, where managing information through a design database deserves its own place in the history. These accounts need their dates and details documented, but they already tell me to ask broader questions than which vendor first supplied a CAD vault.
The timeline itself needs the same care. Brion recalled being assigned to bring Computervision PDM to market in 1984, while Doug’s earlier podcast account described first encountering it at Ford in 1985. An assignment to introduce a product and a customer’s first encounter are different events, and a precise history needs to record them that way.
What Does It Mean to Say PLM Worked?
The more difficult exchange concerned success itself. Doug challenged the tendency to describe an ambitious outcome and then attribute the gap entirely to the industrial customer’s implementation, while Andreas Lindenthal challenged the opposite conclusion of dismissing what companies have successfully achieved using established PLM systems.
I need to answer both. If an implementation achieved its objective, we should document that success, and if it depended on extensive integration work, expensive maintenance, or capabilities unavailable to many customers, those facts belong beside the result. A successful case establishes what was achieved in that case, not how easily another company could repeat it, and equally, a difficult or expensive implementation does not establish that nothing was achieved. This is where broad statements about legacy systems stop helping, because we need to know what was connected, who used it, which business task improved, and what it took to keep the result working.
The CAD Integration Debate Needs Records, Not the Word “Integration”
The same precision is needed in the CAD integration debate, because storing a drawing, managing the dependencies of a 3D assembly, and providing an interface written for a customer are different accomplishments. Doug described how customer and consultant interfaces operated in the earlier market, while Andreas described a specific Pilatus experience in which the available solution did not meet the company’s 3D CAD requirements. Those accounts remain disputed, and the next useful step is to put releases, supported relationships, and implementation records beside each other, since arguing from the word “integration” alone will not resolve them.
Portfolios, ERP Boundaries, and the Spreadsheet Question
Paul Empringham and Christine Longwell brought the discussion back to the broader software portfolio. Acquisitions can add real capabilities, but making those capabilities work together in a customer’s operation is another task, and a vendor’s ownership of several products tells us little about the effort required to connect them with the systems a manufacturer already uses. Christine also raised the question of where work should pass to ERP or another application, and I would examine that boundary task by task. Different companies can assign responsibilities differently, a broad label such as quality covers more than one kind of work, and the useful question is whether the next person or system receives what is needed to act.
Keith Hoover’s question about Excel was funny, but his follow-up made a serious point that spreadsheets can remain after significant PLM investment, which Brion acknowledged and Charles Allard Jr extended to email. The presence of a spreadsheet does not by itself tell us whether the enterprise system failed, because it might support an exceptional task, a flexible analysis, or a handoff nobody has properly addressed. We need to open the spreadsheet and understand its job: who maintains it, what information is reconciled there, and what would stop working if it disappeared.
What is my conclusion?
These are also the questions shaping the historical chapters of my book. Software introduced important forms of control and coordination, people continued to perform work around its boundaries, and the history needs to explain both with enough detail to show what changed.
I think we need to assess PLM through the work and not the label. We should assess PLM through the work it delivered and the effort required to sustain that result, which means marketing claims deserve scrutiny and so do sweeping claims that established systems cannot deliver anything meaningful.
For the next stage of my research, I would like to compare a concrete success and a concrete limitation using the same questions. What was the objective? Which information and teams were connected? What required custom work? Who maintained it? And what remained in spreadsheets, email, or someone’s daily coordination routine?
Just my thoughts…
Disclaimer: I’m the co-founder and CEO of OpenBOM, an AI-powered PDM and PLM platform for engineering and manufacturing teams. My opinion can be unintentionally biased.
