Culture eats strategy AND technology for breakfast

We all understand the importance of collaboration. We know, at least intuitively, that by collaborating people can accomplish more than they could as separate individuals. Yet, product companies that try to achieve effective team collaboration often find that collaboration, like corporate brand, is not well-defined and frequently discounted as too touchy-feely for structured engineering work.

 

cultureeatsstrategy-442x3051

How, indeed, do we make the point that collaboration in product engineering is important? Surely there are some meaningful and tangible values beyond the infrequent Kumbayah moments of positive project reviews, team-building exercises, and high-fives.

Multiple research projects identified both tangible and “soft” benefits of collaboration. These are too numerous to list here or even pick a few, but an old report “Companies Without Borders – Collaborating to Compete” by the Economist Intelligence Unit is a good place to start.

The quantifiable benefits of collaboration in engineering organizations can be summarized in a few high level themes, although when it comes to proving a “hard” proof of return on investments, some analyses make wrong assumptions about efficiency improvements.

  • Faster time to market
  • Increased design reuse
  • Fewer mistakes and design changes
  • Improved manufacturability
  • Greater overall “organizational IQ”

Engineering Software: Collaboration Help or Hindrance?

Recognizing the potential value of collaboration, product organizations have responded by investing in engineering tools such as CAD and CAE software, and in process governance PLM tools. These tools have contributed significantly to improving the efficiency of design engineers in accomplishing highly complex individual tasks.

However, these engineering tools are myopic and create blind spots, especially when it comes to gauging the impact of certain design decisions on downstream activities, a challenge exacerbated by distributed engineering and design teams, outsourced manufacturing, and elongated supply chain networks. Engineering teams need effective methods and tools for effective multidisciplinary collaboration when decision-making must traverse functional, hierarchical, and business unit boundaries.

But, as some will quickly point out, collaboration isn’t exactly free, especially in global engineering and manufacturing organizations, where collaboration levies additional burden such as overhead of versioning and managing multiple design and prototyping iterations, and coordinating engineering and manufacturing partners in remote facilities.

Ironically, sometimes the best intentions to engage in design collaboration fail in the face of the harsh reality of poor IT systems implementations that hinder the engineers ability to share and reuse design information and best practices: incompatible software, multiple information systems that are not accessible to the entire organization, or systems that treat important non-engineering design as BLOBs (Binary Large Objects) that cannot be indexed and searched for.

“Culture Eats Strategy for Breakfast"

Obviously, engineers need to see the value in collaboration. They need to agree that spending extra time creating and sharing information, and then applying it downstream, for example, in manufacturing and service operation, is worthwhile. They also need to see value in reusing known concepts, existing designs and available inventory parts.

Sadly, many such collaboration and reuse opportunities go fallow. We see design teams ignoring manufacturability constraints and serviceability considerations. We see engineers designing new parts rather than using an existing design, or, better yet, modify a design to allow the use of a part already in inventory or available from an approved supplier.

Some of the issue may be attributed to mediocre collaboration tools and suboptimal implementation and process workflow, leading to poor utilization of methods and systems. But technology alone cannot be blamed for lack of interest in collaboration, and merely replacing one PDM system by another might not result in increased utilization, better collaboration and higher team productivity.

Peter Drucker famously said, "Culture eats strategy for breakfast." The origin of the quote actually appears to be Ford Motor Company’s CEO Mark Fields who mistakenly attributed it to Peter Drucker.

And I might paraphrase Drucker’s saying: “Culture eats strategy AND technology for breakfast.”

Consider the following ideas to help instill a culture of collaboration and utilization of design collaboration tools:

  • Reject the culture of “not invented here”, reinventing the wheel and of poor reuse, and instill a spirit of collaboration based on tangible operational and strategic benefits such as faster time to market, fewer mistakes and design changes, and improved manufacturability.
  • Establish product development process consistency and drive to reach a higher level of coordination within the company and in the supply chain using standardized methods.
  • Drive to achieve greater cohesion among functional areas, including those of suppliers.
  • Make collaboration an integral part of product development process by frontloading multidisciplinary decisions that, by definition, necessitate cross-functional collaboration.

Articulate a clear value definition for collaboration and publicize tangible benefits achieved through design collaboration and reuse.

 


A Part Number Anthology part-number-anthology-small

Part numbering. For most engineers, this two-word phrase is all it takes to conjure up especially strong feelings about what it means to be “right”, and what it means to be very, very “wrong.” We've assembled a handful of our part number greatest hits in this eBook anthology.

download_free_ebook_button

 

 

 

  • I find the source of engineerings problems is to listen to IT tell us how we should do our jobs!!!

    I was at Boeing when the calculator showed up in engineering, 1977. I was instrumental in implementing PC based 3D CADKEY into Boeing while on contract with 747 flight deck, 1986. Our biggest enemy? BCS (Boeing Computer Services) seeing that they may be losing control of the computers were quick to put limitations on what we could do. Programming was in their realm and you better never forget it. They would walk into the Drafting room like the gestapo. They even tried to stop us from using the programing available in CADKEY. Sadly, they won and made sure all CAD was only authorized on Catia, even though CADKEY was a much better system with more potential.

    I quickly became a CADKEY VAR and proceeded to sell virtually every Boeing supplier, CADKEY, since it was the only cost effective 3D CAD solution that could work with the workstation based Catia. In 1995 PC based Catia 5 (the high end CAD systems were dragged kicking and screaming to the PC) showed up and Dassault convinced Boeing that they could handle all of their engineering with their PLM and MBD solution. I have watched as Boeing has tried to implement this unworkable system by adding Band-Aid on top of Band-Aid. Dassault is responsible for keeping Boeing one of the most ignorant and isolated manufacturing companies. Their lack of interoperability is beyond belief.

    No, IT is not totally responsible for the state of engineering at Boeing today. But it is the one that put it on an unworkable path with its huge lack of applicable knowledge of the original manual “Document Control” system. Engineering does not create “data” it creates documents!!

    • Hi Joe,

      Thanks for your comments. Yes, I have seen how poorly selected/implement PLM can lead to poor utilization and collaboration. There’s also market research that shows that management dissatisfaction with software (and vendors) is often a result of low utilization, not pure functionality.

      Fundamentally, if there is no culture of use and collaboration it’s very easy to blame the software and IT, especially in a complex environment like Engineering.

      Along the same lines, and reflecting on your comment “Dassault is responsible for keeping Boeing one of the most ignorant and isolated
      manufacturing companies”, I studied how companies select PLM/PDM software. I found that mature companies pay as much attention to the vendor’s long term strategy and expect high level of transparency.

      • Hi Joe,

        Maybe it is time for some to pay attention to the culture and deliver something they can actually use.

        Mature Companies.. hmm sounds a bit oxymoronic

        Putting IT in charge of engineering is like putting a CPA in charge of a company!!!

  • :-)