Email is Not Enough: Why Product Development Needs More for Collaboration

Do you remember when you first got email? Mine was through work and I remember something clicking in my head when I realized what it meant. It’s changed the way we work. We no longer had to get on the phone to communicate remotely. It enabled faster and more accurate decisions. But I have to admit, lately I haven’t been as much of a fan of email. If you’re honest with yourself, do you really like your email? Regardless of how you feel, one way or the other, I see some problems in how well it supports collaboration in product development. Let me explain.

From a general perspective, many would agree that email, especially at larger companies, is a success disaster. By that, I mean that the use of email is so widespread and is used to communicate so many things that is simply becomes overwhelming. As a result, email has become one of the primary sources of distraction from worker productivity in the office. In some cases, it goes beyond that to become an unhealthy addiction to work. There’s a litany of other issues with email beyond these. Do a search of “managing email” and you’ll literally find hundreds of articles offering advice and guidance on how to keep email from doing your job.

While the general email issues certainly apply to product development, there are other email issues specific to product development. But before we delve into those, let me provide a little background. Remember a few weeks ago in the post on the PLM Live Blog Debate, I mentioned that it’s good to be challenged on the positions you take. Well, yesterday Oleg Shilovitsky published a post with some counterpoints to a comment and a post that I had made about social computing in product development. I had stated that a failing point for email in product development was that it wasn’t centralized. He said that actually, it is centralized. And he’s dead-on correct. Actually, I should have been more specific. The problems I see with email for collaboration in product development isn’t centralization, it’s centralized accessibility. Let me explain the difference between the two with an example. Let’s say I wanted to review any and all discussions about a specific sub-assembly in a product. If we were using emails, we’d run into two categories of problems.

  1. Emails aren’t associated with design or engineering objects. They aren’t associated with specific models, spreadsheets, documents or any other type of artifact or construct that represents that sub-assembly. You might be able to use a search capability based on attachments. However replies by default do not include attachments. What about searching by terms or phrases? If the entire engineering staff has diligently used a part number on all of their emails, then you could be all set. But let’s be honest, that’s highly unlikely. All this means that across the organization and even in your own individual inbox, it’s very difficult to find every email related to a specific sub-assembly.
  2. Email accessibility practices are individual based. Another issue is that emails are exchanges between individuals. I’m sure we’ve all had that issue where we weren’t included on the original email distribution list. Catching up on earlier conversations or branched threads is practically impossible. Many email systems do have a group sharing capability, but I don’t know of any organization that has successfully deployed and utilized this capability. Furthermore, think about what happens when an engineer leaves the organization, gets promoted or archives off their email. IT can certainly provide access to their manager or, if necessary, do a search for other people. But realistically, those emails are not widely accessible in the organization. Because of these issues, finding emails related to that sub-assembly across the entire organization is practically impossible.

In summary, from my perspective, I see some real problems in using email to enable collaboration in product development. But this is where social computing comes into the picture. There’s been a lot of buzz and movement around it in product development. Why? Fundamentally I think it addresses the two categories of problems that are outstanding with email.

  • When done correctly, social computing in product development creates an association between a instance of collaboration and the object that is the context of that collaboration. As a result, you don’t need to hope the email author happened to use the right text string to enable a search or always used the option to keep the file attached to the email. All you need to do is look at the conversations related to that sub-assembly. That’s all.
  • Correspondence in social computing is also in the public domain within an organization. So you don’t have to worry about being copied on a specific email string or become concerned when someone leaves the organization (at least in terms of their archived contributions). Again, all you should have to do is set your context to that sub-assembly and you see what you need.

Is social computing ready for product development now? I don’t think we have a conclusive answer to that question as of yet. Siemens PLM has built Teamcenter Community on top of Microsoft’s SharePoint. Vuuch is offering an interesting solution. PTC has launched Windchill SocialLink recently, which is also built on Microsoft’s SharePoint. Dassault Systemes is developing their own SwYm collaboration spacebased on Bluekiwi’s technology soon. I’m sure we’ll see more. But it’s early/

What do you think? How do you feel about email? Other problematic areas I missed? What about social computing? Any negatives I missed? Is the context the real enabler?

Take care. Talk soon. And thanks for reading.

Chad Jackson is an Industry Analyst at Lifecycle Insights and publisher of the engineering-matters blog. With more than 15 years of industry experience, Chad covers career, managerial and technology topics in engineering. For more details, visit his profile.