Collaboration is vital to any engineering process, but the actual mechanics of such collaboration can vary widely both in theory and in practice. Not helping at all is the fact that the term itself has been long hijacked as a piece of technical vocabulary, serving to push new products and features in a protracted marketing war including PDM, PLM, ERP, and ECM, and now CAD. When we throw “real time” in there, confusion mounts as to what exactly that is supposed to imply. More specifically what does that mean for engineering? Do engineers want it? Will it work? Morpheus might say that collaboration is everywhere. It is all around us, even now in this very room. You can see it when you look out your window or when you turn on your television. You can feel it when you go to work, when you go to church, when you pay your taxes. For purely creative and/or artistic ventures collaboration can be organic, boundless. For engineering however, collaboration must necessarily be coupled with a critically important concept: change management.
How we work is fundamentally changing, not just in engineering, but across all disciplines involving information management and collaboration. There’s an escalating revolution in enterprise software, where the grand unification dreams of the past are now being set aside. Spoiler alert: there really can’t be one system to rule them all. It’s not that we haven’t tried to forge the one system in the fires of Mount Doom. But in many cases we tried and failed. Instead of a single-vendor monolithic solution, there’s renewed emphasis on specialization within a larger heterogeneous mix of options. Tools in collaboration, communication, and analysis that aren’t bound to their masters like their monolithic precursors, but instead flourish in an alliance of interconnecting and distributed technology. And here we all stand, at the turn of the tide.
No doubt the accelerating drumbeat of technological innovation is imposing economic, social, cultural, and emotional effects on the human condition across all boundaries of geography, industry, and expertise. Engineering and manufacturing are no exception to this relentless technological tide. Both are undergoing a transformation that may be as profound and broadly evolutionary as the Industrial Revolution if not more so. What drives this acceleration? All invention and discovery is drawn in part by standing on the work of those came before. But as the breadth and depth of that knowledge increases, and the utilization of it similarly scales, we’re faced with an exponential curve of innovation and discovery. Consequently that also means a metric crapload of change. It can be exhilarating; it can be depressing. That precise dilemma has been a primary motivator as to why I write in this space at all – understanding what this means for engineering in general is crucial for the future. But before we get all wrapped up in singularity monsters that look like Caribbean pirates, the end of economic scarcity, or whether the guy who just handed you a Frappucino is really a Cylon, let’s take a step back. Way back. Let’s go back in time, through the ages of time and space… all the way back to last month.
Right behind Stonehenge and an improbability drive, Geometric Dimensioning and Tolerancing (GD&T) is somewhat of an engineering enigma, if there ever was one. Developed as a language for precisely communicating design intent, the ASME standard has been in existence for over half a century. The benefits of GD&T are very real, providing a reliable and verifiable means to ensure parts function and interface as intended, while reducing scrap rates normally driven by unnecessarily restrictive rectangular tolerancing schemes. Yet, at the same time, GD&T is largely not institutionalized in engineering curriculums, nor is training widely delivered to engineers at companies of all shapes and sizes. Some companies hold an utter disregard, and don’t utilize GD&T at all in their engineering. Model Based Engineering (MBE) promising to annotate GD&T directly into 3D models as Product Manufacturing Information (PMI), continues to suffer 
One of the most frustrating aspects of the Product Data Management (PDM) and Product Lifecycle Management status quo is just how much of the core practice is steeped in a configuration management tradition, harkening back to the days of the battle of Dagorlad, or in other words, a really, really, REALLY long time ago. These time-tested configuration management rules have but one fault: they were chiefly devised in a world absent of all the seemingly magical computing technology of this age. Yet many are never revisited, because it’s more than just a simple matter of contemplating new possibilities, but rather an intractable struggle against well entrenched software and organizational foundations. There are many such hard tenets of PLM lore that are often quoted as absolutes, be it that tradition and entrenchment has lasted since the ancient days (about 1965 or so).
At the heart of any enterprise system, be it Product Lifecycle Management (PLM), Enterprise Content Management (ECM), or Enterprise Resource Planning (ERP), beats the steady pulse of change management. Truly understanding the evolution of any complex system necessitates some form of change methodology. It’s interesting though, that outside of engineering/manufacturing circles, change management in of itself seems relatively unknown. Even mention the term change management outside this realm of expertise, and the first reaction typically is “Oh, you must mean organizational change management.” Qualify the term as engineering change management or document/asset change management especially and (with a few exceptions) it’s generally a world of deer and headlights. Alarmingly, it seems the tenets of change management are to be forever confined to the a world of engineering complexity, not because of their lack of relevance but perhaps their lack of accessibility. In contrast, witness the explosion of web applications that focus on real-time co-editing of content, sacrificing structure for immediacy. As the pace of business accelerates, there is mounting pressure to adopt those immediate models. Is this the death of change management?
Is engineering getting a little crowded? In this brave, new world of