Chad Jackson

More Reclamation Work for Collaboration: Providing a Product Development Context

November 22, 2010

In the last post on collaboration, we covered a lot of issues surrounding collaboration. It’s been overused. It’s been used without specificity. As a result, we all cringe a little bit whenever we hear it being trotted out to describe another process or set of engineering software.

More Reclamation Work for Collaboration: Providing a Product Development Context

In the last post on collaboration, we covered a lot of issues surrounding collaboration. It’s been overused. It’s been used without specificity. As a result, we all cringe a little bit whenever we hear it being trotted out to describe another process or set of engineering software. We laid out a table that described the various aspects of collaboration that really could be applied to any type of company or functional organization. But for engineering organizations, that information lacked context. You see, teams don’t just collaborate, they collaborate about something. The collaboration has a context. And that’s what is outlined in the table below.

Here’s a quick run down of what it all means.

  • The left column lays out the major categories of work specifically for engineers. They certain do get involved in designing products, documenting products as well as verification and validation in the design phase, but they also have wider enterprise responsibilities. As much as engineers might abhor it, they do need to participate in governance and oversight processes. Furthermore, engineers are often the ones that provide leadership to resolve issues for a product throughout its lifecycle.
  • The middle column describes some of the finer detailed activities that occur within each category of work. Collaboration plays into each of these types of activity whether its making a decision or building a 3D CAD model. This middle column is by no means comprehensive but it is detailed enough to get the idea.
  • The right column lists digital deliverables upon which the collaboration happens. These deliverables often act as the baseline of knowledge or product definition around which a decision has to be made or a deliverable needs to be finished.

This framework can be used to provide some clarity around why and how you’re collaborating. We can construct sentences that describe the collaboration with specificity. Let’s use the following on a few examples: the team collaborated using <technology> on <digital deliverable> to <work activity>.

  1. The team collaborated using a web-sharing session and a conference call on a 3D CAD model to finalize tolerancing values.
  2. The team collaborated using instant messaging on a requirements spreadsheet to finalize part selections.
  3. The team collaborated using an internal blog on the project schedule to collect project status and define corrective actions.

Now we’ve provide a context in terms of the technology, the digital deliverable and purpose or activity behind the collaboration. Now there’s no confusion between any of these items. We need this level of specificity to distinguish where technologies best fit, who uses it and for what purpose. It provides a context to the term collaboration such that it can be useful again.

What do you think? Are there more categories of work? Are there other digital deliverables that should be included? Does this sort of context for collaboration provide value? Sound off and let me know what you think.

Take care. Talk soon. And thanks for reading.

Share this post
LinkedInTwitterFacebookEmail
Loading cart ...