In physics there are two widely accepted schools of thought about the operating principles of this place we live called "the universe" - quantum mechanics and Einstein's theory of relativity. The "holy grail" of science is a theory that unifies these into a central explanatory body of knowledge for the meaning of all things in the universe. Some even call this a "search for God." Of course, there's a lot more to it than that (multi-dimensional space, superstring theories, space-time, etc.) but we won't get into all that, mostly because I am not a physicist.

So too, in product development, are we in search of a unifying system for how to create profitable value in our own business universe. Compounding this challenge is the fact that there are far more than two schools to unionize. An infinite garden of forking paths stands before any manager. Any process worth its salt can show results in a real-world situation and its hard to choose among a pool of things that all have reasonable credibility. From the no-nonsense approach of QFD to the bizarro-world of hypnosis market research, every bit of process minutiae you can think of probably worked somewhere, yes, even quality circles.

To go back to the metaphor of physics, the arguments around the unification subject have a lot to do with the space-time continuum, and how matter and energy behave inconsistently amongst all the things physicists thought were laws. Today, many scientists have had to rethink what they thought about "hard science," realizing that many laws share the weakness of explaining what is being perceived by the observer rather than what is actually happening under the hood. Anybody who's interviewed a customer about what they want in a product should be able to identify with this problem.

Again, the parallels in development work reflects the same issues. While we can input formal processes such as gate systems, concurrent engineering, early supplier involvement, etc. any can fail when participants are not clued into the fundamental logic of the system, i.e. what's going on under the hood. However, while they have yet to identify the properties or conditions that explain the universe's behavior, it's starkly clear what the missing ingredient is that would unify all ends of your product development system: Communication.

That may seem like a cop-out to many of you. "D'uh, where's the 'aha'?" you might ask. "Is this about -ick- 'knowledge management?'" Many of you reading this have probably been subjected to an unending barrage of pitches for IT products that promise to help you "unleash your knowledge assets," and while I agree much of this is hyperbolic marketing BS, these products can be a legitimate solution, but too many people rely on it as a recipe rather than an ingredient. So how is what I preach different?

Here are the distinctions:

• Data - these are facts, plain and simple
• Information - data in context, you know what the data means
• Knowledge - information in context, you know the significance of the info
• Understanding - knowledge in context that you can apply in decision making

When most try to accomplish better communication in product development, they typically only make it through the first two levels and scant few make it all the way through. If this describes you, you may have also heard terms like "analysis paralysis" and "ready, fire, aim" where actions are either held up until the final decision must be rushed or where a hasty decision is made based on poor knowledge and understanding of what was communicated. Regardless of what style of development you follow, whether you are a six-sigma company, have a balanced scorecard or employ a cadre of Jonahs, none of these can work well (or work together) with poor quality communication.

Bad communication manifests itself in a myriad of what can be called "information defects." Just as a physical defect such as a hole-punch that is 1/8" too small can wreak havoc on the shop floor, attaching the wrong version of a CAD drawing to an email is an information defect with equal if not greater negative impact. Going a step further, projects with poorly defined or cryptic goals, and staff that is too disconnected from the corporate charter, also represent damaging communication quality.

What can you do about information defects? Here are a couple simple things to consider:

1) Standardize meta-data when possible. "Meta-Data" is information about information (e.g. last time this file was checked out, name of author or even the deliverable due date). Product Data Management (PDM) software does an excellent job of automating meta-data to CAD drawings and engineering communications, which is very helpful with things like version control and workflow. Try to decide what meta-data is actually helpful to the people doing the work, remove anything extraneous to reduce noise, and then make sure that data-set is always included.

2) Increase information frequency and availability through push and pull systems. While you don't want to flood people with unnecessary communication, "push" information techniques like tickler files and email triggers can be good reminders and catalysts when not overdone so as to become annoyingly ignorable. Network-based reporting systems with web-access are "pull" information techniques that can ensure that someone can always get a piece of critical data without the delay for human intervention. See the "Visual Information Pull System (VIPS)" mentioned in our web review below.

3) Build quality into your communications. Spend extra time when assembling information for someone else to prevent damaging information defects. Consider applying the Japanese mistake-proofing techniques from manufacturing (poka yoke) to your communications. For more of my pablum about information defects, we refer you to a previous issue of TCP - Issue 1.12, "Zero Defect Product Development".

3) Set goals and make them clear to all. This is the most important, yet most difficult aspect of communication to accomplish because it requires uncomfortable things like honesty and trust. Goals are typically unstable creatures, making it frustrating to keep your entire company current on what is important in a turbulent economy. This is compounded further by the fact that this level of information can easily be political and threatening to people's egos and security. However, isn't the mark of great leadership the ability to surface and broach issues that others won't even acknowledge?

Send me your Top Ten List suggestions - gregg@roundtable.com

---

Interested in sponsoring this newsletter?
For a list of terms and rates, send an e-mail to gregg@roundtable.com or click here.

Return to MRT Homepage