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?
Engineering change management practices arose well before any of the current software technologies digitized them, having previously been manifested as heroic spreadsheets governing forests of paper, stuffed in endless file cabinets, and accompanied by change authorization forms piled from here to the moon. Often entire departments were purposed just to manage, file, sort, copy, and redistribute only the paperwork involved with authorizing and maintaining engineering change. Any longtime veteran of engineering can easily recall document control departments, that in many ways are now largely defunct and replaced by enterprise workflows.
As a replacement for the paper-centric universe, the PLM, ECM, and ERP systems of the day have carried forth the traditions in an electronic fashion, usually for the better. Usually. Many of the systems in place were directly derived from their paper-centric forbearers, and still carry similar limitations in bureaucracy and accessibility. Sometimes that accessibility is notably worse, from both a usability and flexibility standpoint. Why? For reasons of user interface, licensing, and/or specific software/hardware technologies, accessibility of these systems can be worse than their paper ancestors. That’s an easily resolvable problem, but a common problem nonetheless. At least a notable benefit has been realized by replacing the routing and processing of physical forms to electronic equivalents moving at the speed of the intranet.
The engineering change methodologies have managed to get by in engineering, where the burden of formal change management has been a fair price for system and product integrity. Unfortunately, the relatively rigid and serial nature of change from the past has been preserved as is. Change is generally allowed only if it has been authorized, and systems have little to no tolerance for ad-hoc or parallel changes. With respect to CAD, I described this in more detail in It’s Time for Check In to Check Out. But again, the economies of very complex systems have justified both the expense and pain. Mostly.
So what’s the larger problem? Wander off a certain radius from engineering or down to a company under a certain size and change management all but disappears. The unfortunate reality is way too many organizations are getting by with brute force, passing documents back and forth manually like monkeys working on Shakespeare. The bottom line is change management as offered in the various enterprise tools is neither accessible nor agile enough to be effective at those scales. And no amount of Sharepoint is going to fix that.
It’s concerning that proven change management technologies on a large scale are all but abandoned when moving to the small scale. Where do you see adoption regardless of scale? You certainly see it in software source control. Software source control allows change to happen in every direction (via forking), but its incorporation is authorized (with merging). The universal adoption is readily apparent, be it a few hundred lines of an open source app written by a single individual to the millions of lines in a complex engineering project written by a global team. It’s solid recognition that change management is necessary but also must be accessible to all.
Yet in document circles, things seem to be headed in the opposite direction: toward oblivion and utter chaos. Case in point, the proliferation of real-time simultaneous editing in authoring web platforms aiming to replace desktop counterparts. These are often targeted specifically at Small to Medium Business (SMB). The coolness factor of watching everyone edit a document quickly fades when you understand there is no change control. All change is throttled with or without authorization with the hollow argument that a version history acts as some sort of insurance. It’s an all-you-can eat buffet of information anarchy. So I ask again, is this the death of change management?