 To be successful and profitable (to meet the needs of the business) every product is a collaboration of multiple groups. As an engineer, in the past I’ve been as guilty as most at jumping into a new design assuming I understand all the requirements. After all, I’m smart, I can design it. But then later I’ve had to rework designs because I’ve missed a critical feature, misunderstood a requirement, picked a component that wasn’t supportable, etc.
I believe that one of the most important elements of a successful product is typically ignored or overlooked. Good design cannot happen if the designers don’t understand everything the product must deliver, how it must deliver it, how it affects other groups, the target cost, and timelines. But the design isn’t the only critical element in bringing a product to market. Parts must be sourced, purchased and delivered, other parts need to be fabricated, then assembled, tested, packaged, stored, delivered to the customer, and often serviced. Everyone involved, in all of those steps needs to understand what the intent is, what the limits are, and what to do if something doesn’t meet those intents. The design specification is the one document that should capture all of that information. If you Google product specification you will find lots of examples discussing a product design specification (PDS) or product requirements document (PRD) as it applies to a software product. These same documents are even more important for a multi-disciplinary product. There are more teams involved in the successful implementation; hence more need for clear and thorough sharing of all the requirements. I have always combined the PDS and PRD, but regardless if there’s one document or many, they should be referenced and organized in one place where all the required information can be clearly documented and accessed. The product spec starts with the business case. After all, we’re trying to make something someone wants to buy and we want to sell it at a profit so that the company can continue and grow. The business case should outline what functions the product must have, who it will be sold to, where it will be sold, in what volumes, and at what cost. Obviously, if one document is going to include everything required by all parties, it can’t be created and completed day one. It will continue to evolve as the details are developed. Industrial design will take marketing data and develop form and function, engineering will take the functional requirements and the industrial design and develop the detailed designs, supply chain will work with engineering to source materials and help plan production, manufacturing will take the designs and bills of material and plan assembly etc. A typical comment is that there’s not enough time to write a spec or that we already know what we want and there’s no need for a spec. At a recent manufacturing peer to peer group meeting we were discussing a design specification for a relatively simple automotive part. The spec had multiple revisions and had grown to approximately 60 pages. Someone in the group piped up and said every one of those revisions was a lesson learned. A thorough specification that is used, maintained and reviewed by all stakeholders will help plan more efficiently, avoid problems, achieve business objectives, and almost always reduce the overall time and cost of product development. In future blogs I will explore how to use the design spec to plan efficient and effective conceptual and detailed design, custom part fabrication, assembly, testing and quality control. An important hint – knowing how the spec will be used will make writing one much simpler and quicker. |
RSS Feed