Prototype Parts and Product Development Lifecycle

Posted on: January 7th, 2013 by admin 3 Comments

by Jon M Quigley

A few recent experiences have led me to believe many do not know the reason for prototype parts. Consider organizations that employ an iterative process for developing products. The automotive world typically uses this sort of product development method. In iterative product development, we build increments of the product learning from each increment to improve the subsequent increment culminating ultimately the increment that will make it to production. We do this to reduce risk and to ensure we do not spend BIG money for engineering work when we are missing some key information about the potential product.

Let us review the following all too frequently occurring story. An organization has an iterative product development process in place. In this example, the defined process has four levels of prototype parts, with each level having specific objectives to be achieved and a definition of the part’s level of sophistication. We have a brief list as an example of the product iteration by phase below:
1. mechanical mock-up (form only)
2. form and basic functionality
3. form and all functionality
4. all of the above built off production parts and process

At the start of the project, the project manager works with engineering to identify the objectives to be met, the prototype parts required and the tests conducted (see previous blog). The supplying vendors determine the scheduled build of the prototype parts, at least in part. Here is where the problem arises. We sometimes see a project schedule that requires scheduling the next phase of the design going to prototype by the supplier, before we have gotten the previous version of prototype part and learned anything.
There is no ability to learn about the first iteration of the product before the next iteration of the product is sent to prototyping. In essence, we have built a prototype part that will not add any value to our project in terms of design advancement or improvements. Moreover, any design flaw not found and corrected in the previous iteration will likely reside in the next iteration of product. You are relying on luck or happenstance to eliminate the design flaw.

We purchase prototype parts to learn the things we do not know about the product. If we are already building the next iteration of product before we have critiqued the present iteration of product, we have put the organization and project / product at risk. We are in fact, wasting the organizations money. Prototypes are used to mitigate the risks associated with developing a product. We are mitigating risks and improving the product quality as we move through the process rather than leave all quality securing activities to the end of the product development lifecycle.

This does not mean there are no solutions. There are three possibilities:
1. Eliminate the prototype
2. Develop rapid prototyping ability
3. Develop modeling and simulation capabilities

First, eliminate useless prototypes. If you do not have questions or specific information to be uncovered via testing, there is arguably no need for the prototype. If you have no intention of learning from one level of prototype to advance the subsequent part iteration, save the money and eliminate the prototype. You will likely need that money to manage change requests due to elimination of the prototype part.

The second possibility is to look for ways to reduce the time to build prototypes through rapid prototype techniques. We still require the time to test the prototype but if the lead time for acquiring the prototype is sufficiently reduced, we may not have these interference fits with project demands. This requires a new way of thinking within the organization often including investments in new equipment.

The third possibility is to make use of modeling and simulation. These tools can reduce the needed prototype parts. Reduce the need, not eliminate. We must still test to understand the real stimuli and response, comparing our models to actuals.

Additionally, modeling and simulation requires a mental shift from the way an organization may work at present. The entire development organization must be prepared for this transition. Use of models and simulation require a development philosophy change. Modeling and simulation activities can reduce dependencies upon prototype parts however this is not a quick solution. Neither does it remove the need for prototype parts. These tools will reduce the need for some prototype parts as we are able to determine some attributes of prototype performance virtually.

If you are not going to learn something from the prototype, eliminate it. Take time in the beginning to understand what is at risk and use prototype so reduce that risk. If the prototype lead time is too long, find ways to shorten the lead time. Do not waste your time and money making prototypes that meet a checkbox but does not improve the product and reduce project risk.  Better still, do not plan your project to waste money expose the project and the product to these risks.

Tags: , , , , , , , ,

3 Responses

  1. David White says:

    I totally agree with the statements in “Prototype Parts and Product Development Lifecycle”. You might include, however, that one reason for Prototype is that the customer needs more parts to do is System Development. As a supplier, one tends to plan for the unexpected and have a few more parts on order even if they don’t get built or processed. The counter argument to avoid building prototypes is to build another lot only because the customer needs more. Generally, prototype systems are made up of prototype components. Many, if not most, of these parts are not approved for production and are not already available on the production floor. Special orders are made for these parts. I have experienced Release Engineers, who are responsible for the supplied component in his/her organization, attempt to gather the plans of various groups who will ultimately need to build a system for all aspects of testing. It never seems to fail the someone has failed to consider the x project (something very important that no one is awhere of and requires your part).

    • admin says:

      You are right David White! Sometimes our customer needs parts for their evaluation. This is helpful as their review of the product may help clarify some of the requirements as well as gain a greater understanding of the future use of the product by the customer. If the customer gets this part / product and assembles or processes it in anyway, the actual material will help them understand how their portions of the manufacturing and handling processes need to work.

  2. Gus Pestoni says:

    I have to thank you for the efforts you’ve put in penning this blog. I really hope to check out the same high-grade content from you later on as well. In fact, your creative writing abilities has motivated me to get my own, personal blog now.

Leave a Reply

 

Recent Blog Posts

Single Sign On provided by vBSSO