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.