Product Development Pitfalls |
by Tony Parker, Avance LLC |
Focus Summer 2012 |
Around our office, we have forbid ourselves from using the word “easy” when discussing client projects. Utter that word too often and Murphy’s Law will eventually let you know that nothing is ever as simple as it first looks. The majority of these complications stem from issues that occur when sharing data with clients or strategic partners throughout the development process. CAD drawings and 3D models, product definitions and specifications, test results, compliancy reports, photo renderings, technical illustrations and more all comprise my definition of “product data”. The intent of this article is to shed light on common issues that hinder the process, with the hope it draws attention to refining your own design data control process or sharing best practices within the MAPP community. Whether you are a full-service processor that offers turnkey product development resources or a provider that relies on strategic partners throughout the development cycle, many of the same challenges exist when managing product data. Minimizing the potential for errors will certainly benefit you and your client’s profitability and garner trust from your client that their intellectual property is in good hands.
Moving Upstream
1. Keeping It Confidential It certainly is not uncommon for a plastics processor to service a variety of clients that compete in the same market space. Ensure your agreements are current and proper protocols are followed for each, especially when transferring data to strategic partners that serve you.
2. Who Owns What? Also, be explicit about items to which the client does NOT have entitlement. You may have developed trade-secret processes that efficiently manufacture a complex product. If the client chooses to move production elsewhere, those processes remain part of your intellectual property unless it was previously agreed upon otherwise.
3. Know Your Role Some clients can be very dictatorial by nature, controlling all aspects of the development process, and perhaps even imposing on your own. Others can be more passive, revealing just enough information to consume excessive time and resources to complete their programs. Vetting new clients early to learn their habits and expectations can be helpful in putting together the right program plan. At project kick-off, assignment of roles and responsibilities should be clear.
4. Specification Revelation Texture selection appears to be one of those often overlooked examples. A part has been designed with shallow draft angles to accommodate fit into an assembly, and texture specifications at the time of kick-off were “To Be Determined”. Once tooling is complete and sample parts approved, the client wishes to select a texture requiring much greater draft. At that point, the client must weigh compromising texture selection or possible tooling re-work. We try to cast a broad net to gather and lock down as many specifications as possible at the beginning of a design project. Mechanical, environmental and aesthetic considerations, along with certification or compliancy requirements, cover a broad range, but may not capture all. Be proactive in pursuing potential “hidden specifications” with your client.
Moving Downstream
1. Archival Responsibility Be very clear with your client about what, if any, product data you will archive, in what format and for what length of time. There are a number of situations that can necessitate the recovery of archived data, whether for your own use or to the benefit of the client. Revising a product design and its accompanying production tool based on its original data is inherently less costly than recreating that data from scratch.
2. Revision Control and Data Storage But even these systems require disciplined use to be effective. Approved design models shouldn’t languish as email attachments for long-term storage, nor reside somewhere in the “My Documents” folder along with pictures from your last vacation. Regardless of process, avoid errors by keeping all client data centrally stored and consider an offsite backup solution for additional protection.
3. Data Disseminator Conversely, if you are not managing your client’s design data, be cautious of executing revisions that are not originated through a formal process. Consider this scenario: The client has a processor build a tool and run production of a part that was originated with the assistance of an outside design firm. The client accepts the lot, but inquires if the parts can be made more rigid during the next production run. To be helpful, the processor recommends changing material, adding ribs, etc, to improve the part. The client approves verbally, but does not engage in a formal change order process. The tooling and material are modified, so the next time parts are delivered, they are not to print. The design firm, the processor and the client ultimately spend time investigating and rectifying a situation that could have been avoided by following procedures. In summary, reviewing your current processes may reveal program risks and inefficiencies in the way you currently manage design data throughout the development and production cycle. When investigating process issues unexplained by the obvious, consider the data trail leading up to the event in question. Continuous improvement in these areas will give you a competitive advantage while impressing upon your clients that their product data will flow smoothly. Tony Parker is a principal and design engineer with Avance, LLC, an Indianapolis-based product development consultancy. The past fifteen years of his career have focused on design process using 3D CAD and rapid prototyping technologies. He can be reached at [email protected]. |