Product Structure Matters: Part 1

By Jonathan Scott

Product structure matters because it is the lingua franca of product development. Everyone needs to understand how they fit into the top-level design, and how they impact other areas of the design.

Since I am not talking about some cool new software tool or exciting piece of hardware, I’m going to need to work hard to convince you that my message bears some significance for your business. So,  like me, see if you remember a few too many project postmortems where you’ve heard things like this.

“Our left hand never could seem to figure out what the right hand was doing, and having five hands didn’t help. By the time we realized we missed something, it was too late to go back and design it right.”

“If the power guys and the controls guys could have shown me what they meant to do here, I never would have put the cooling where I did.”

It only took a few comments like these before I was convinced that communication in our shop was a problem in our process. These were not the type of communication problems that were solved by 3D models, electronic workflows, e-mail status reports, or more cross-functional meetings, but in my estimation, the root problem was that we lacked a common tool for sharing our design “plans.” We had not devised a way to publish nor to read our plans in a way that every discipline and function could understand. I could always find the electrical engineer or manufacturing person I needed when I had a technical issue, so talking through the change or problem or idea wasn’t the challenge. It all seemed to boil down to not knowing what some other function was working on and how their work might affect mine. And, this doesn’t even scrape the surface of how these issues were amplified when we started engaging subcontractors for parts of the design.

As a mechanical designer, I couldn’t understand where all of my great tools were failing me. 3D parametric design seemed to keep our department all on the same page (when Gary changed his subassembly, I got the updates the next time I opened the master assembly file). PDM was helping us keep revisions straight and saved us from stepping all over each other with concurrent changes. But it all fell apart when the electrical engineer changed a motor or the purchasing agent gave me the next-best thing to the gear I specified.

I realized that we had tools to communicate spatial relationships (3D CAD), calculations (spreadsheets), and requirements (word processors), but nothing to communicate our design structures. Sure, we had ERP, but our system wasn’t set up to manage revisions, so it was a non-starter to try to use it as a design and development tool. The next closest thing we had (and this only evolved over time) was a collection of spreadsheets; I managed mine, Gary managed his, etc. and never the twain did meet, at least not until the project was complete and we were wrapping up documentation.

So now I’ve worked my way back to why product structure matters. I believe it matters because it is the backbone of product information in the engineering and manufacturing organization. With a place to store, create, and manipulate product structure, everyone in your business can understand how responsibilities are divided and can work from the same “plan” —  a constantly evolving baseline.

Configuration Management

Some of you are saying to yourselves, “yeah,  yeah, this is nothing new – hasn’t this guy heard of Configuration Management?”  You’re right on the money; I’m not introducing anything new here. Standards like EIA-649 and philosophies like CMII preach this same message. I’m just not sure that everyone is aware how the lofty theories of Configuration Management trickle down to the in-the-trenches work of product development (it took me a long time to make the connection).

To rephrase my position: Product structure is the secret sauce of Configuration Management needed to make your product development recipe a success. To reach success, however, begin by looking at how you view your design data.

Product structure is an outline, made up of items in a hierarchy, and documents are the details that fill in this outline to complete the total picture. Each item in the multilevel, parent-child product structure has a relationship to one or more documents that specify that item.

What’s needed is PDM that can manage your CAD (MCAD and ECAD), that can manage your product structure, and that can leverage one into the other.

With a place to store, create, and manipulate product structure, everyone in your business can understand how responsibilities are divided and can work from the same “plan.”

Again, there are those that will point out that 3D CAD already has a product structure. The challenge is that only mechanical designers with the right software tools and know-how can work with that structure. Furthermore, who models paint, glue, and detailed circuit-board components? When was the last time you let the manufacturing engineer reorganize your subassemblies?

So there you have the crux of the matter: what’s needed is PDM that can manage your CAD (MCAD and ECAD), that can manage your product structure, and that can leverage one into the other (with structure copy, compare, and synchronization tools). With PDM like this in place, you leverage what’s done in MCAD and ECAD (no data re-entry), you give everyone a product structure manipulation tool and, in the process, you create a central hub for communication.

Product structure matters because it is the lingua franca of product development. Everyone needs to understand how they fit into the top-level design, and how they impact other areas of the design. Project managers need to know which parts of the design are fully defined and which ones are a bit behind. Purchasing and manufacturing need to feed back their constraints before design is complete. Once everyone has a common tool to use for these purposes, the communication can start to flow.

Next month, we’ll look at how adopting this item-centric viewpoint can provide benefits beyond solving communication problems we face in the design phase. The item-centric view can shorten time-to-market, increase the accuracy of sales proposals and quotes, and tremendously simplify the lives of field service personnel. Stay tuned.

Jonathan Scott is a principal consultant for Razorleaf Corporation based in Williamsburg,Virginia. Send your comments on this article to[email protected].