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.

Oleg Shilovitsky sparked this discussion by exploring an interesting question on his own blog: Is There a Need for “Real Time” Collaboration between engineers? In that article he concludes:

“Collaboration can empower organizations and people. In my view, it applies to engineers too. However, it is sometimes hard to find a fine line between collaboration that empower people and some prescriptive “collaboration processes” and activities that lock people down to a specific functions. How to [do] that?”

Prescriptive collaboration as described above is a bad thing, because it’s limiting a human process by the artificiality of particular software functionality. Before we pop trying to figure out how exactly to Kung Fu through that limitation consider this: engineering collaboration in many ways has to be prescriptive collaboration. Not because of software functionality. Not because some jerk blogger like me said so. Instead, prescriptive collaboration is a necessary evil to maintain integrity of engineering design. And the need for that discipline rises with the complexity of the design, how many people are involved in its creation, and the consequences of design failure. So is this the end of the discussion? No, not at all, because the real problem is that engineering collaboration, for the most part has been over prescriptive. There’s room to change that and in so doing fostering more innovation. So what do you need? Besides a miracle.

To understand how engineering collaboration could work requires understanding engineering change, but usually that involves getting lost in an endless parade of workflow diagrams and methodologies that will have you begging to get put back in the matrix so you don’t have to deal with it anymore. So we’re going to simplify, man. So here’s the short-short version of change:

1. Identifying Change: What needs to change and why?
2. Accepting Change: Is this good? Will this mess anything else up?
3. Making Change: Change all the things!
4. Enacting Change: When is the change real?

Most engineering change processes as they are today are carefully structured to preserve design integrity, and in so doing are linear and inflexible by nature, often enforced by the CM equivalent of Agent Smith. These methodologies are modeled after extinct paper legacies including artifacts like check in/check out. They are collaborative processes by the purest definition, but are intrinsically serial which makes change so burdensome that many smaller projects abandon such an approach entirely, settling instead for brute force methods that can never scale (Like our friend Excel).

So along comes “real time collaboration” which equates with simultaneous edit. That means two or more people making changes in parallel and each seeing those changes as they happen. Otherwise referred to as coauthoring. When you ask people what they want for making changes coauthoring is what they will ask for in the belief that this is a viable change process on its own. They keep using that word, but I do not think it means what they think it means. While available on the document front in the form of Google Docs and Office 365, only recently has this approach debuted for CAD design, specifically with Onshape. And while it is most certainly a technical marvel that it works at all, by itself it cannot be a viable change solution except for the simplest of designs.

To illustrate let’s look at change through the lenses of classical engineering collaboration and “real time collaboration”:

Real time collaboration eliminates barriers for making a change, but in so doing, severely undermines the ability to control change. So we’re improving the capacity for innovation in one stage of the change process at the expense of the entire rest of the process. Welcome to the desert of the real. Considering a very tight team of 2-3 people and compact design with few requirements, this might just be marginally viable, but anything beyond that and it’s not long before you’re in complete chaos.

One might make the argument that for developmental engineering, where a product doesn’t yet exist in the field, might justify using a more relaxed change process. But any modern design has complex and non optional dependencies including regulatory, environmental, and safety considerations. Changes can cause product failure, and depending on the application may threaten property and even human life. “Real time collaboration” might work for your 3 pages of co-authored Matrix fan fiction. But it’s otherwise a non-starter for any legitimate engineering design.

But before you surrender any hope of collaboration to the machines, the path to streamlined engineering change is a solved problem in the software universe. I’ve written about this at length in a number of places, especially Fork Over Your Engineering Changes over on the GrabCAD blog. Because software is subject to many of the same challenges as engineering physical product, the change methodologies are indeed relevant and are applicable to massively complex products undergoing massively parallel change. What does change look like for this methodology?

Software Configuration Management (SCM) does exactly what we hope to do. Remove the barrier to making changes while still preserving integrity of all changes and the overall product. Up to now, it’s been an impossible dream for CAD, but Onshape has already taken a tentative first step, albeit an incomplete one. While you can branch designs in the online CAD/PDM tool, merging the design back into another is an overwriting process and does not exhibit the conflict management of a typical diff as used in source control.

While you could use comparison tools to analyze different versions of the same design to qualify changes, it’s dangerous to do outside of something like a relatively simple (and short) Word document. That’s because some otherwise critical design changes aren’t readily apparent visually. Take for example a change in hole size which might change the type of fastener fit, and ultimately the strength of the joint. Visualizing a changed model that may also be flooded with surface changes from minor adjustments like fillet radii may make understanding the most impactful changes difficult. Tools need to be in place the explicitly identify variations in model versions and precisely catalog what changes are carried over in the merged version for something like this to work. What good is a phone call if you’re unable to speak?

So do you still believe in engineering “Real time collaboration” Neo? We can’t dodge bullets just yet. But when the tech is ready, you won’t have to.