fbpx
 

Process Theory Versus Practice

In the medical space, we are responsible for documenting all design decisions, tracing every product requirement to a verification protocol, and creating a design package for the FDA. This includes documentation of such calculations as the tolerance stackup, failure mode effects and analysis (FMEA), life-cycle estimates and testing, accelerated aging, structural analysis, and mean time before failure (MTBF), for example. In the event of a problem, it’s likely we would be audited to determine whether we used good engineering practices to design some feature that did not perform as desired. The documentation package for a typical medical device project is roughly two thousand pages.

Since we already have the discipline to design to these guidelines, it’s easy to justify them as good practice for any project. As consultants, we want to provide our clients with a complete design package that they can look back on down the road and understand why a feature exists, what aspects of it might be important, and how a small change might impact the rest of the device. It also helps me because I can barely remember to bring my lunch to work, much less the design basis for a feature from a project I worked on last year.

From an efficiency perspective, it may appear that using these tools when not required (by an agency such as the FDA) is adding baggage to a project. It is true that not every tool is appropriate for every project. However, one of the values we bring to our clients is the discipline to choose the right tools, to use the process tools efficiently, and to get our clients to understand them, too. For example, we always make a concerted effort to develop a detailed product specification at the beginning of every project. While spending a week or a month hashing out requirements might seem wasteful, it helps us understand the project constraints and client expectations. Most importantly, this time is well-spent if it forces our client to make decisions about the product now that might prevent expensive changes later.

I’ve found a good method to implement a specific process theory tool that is not already part of the culture is to start small and to do the work myself while getting input from others. We don’t demand that a client create the detailed product spec. Instead, we create the product spec ourselves based on our understanding and go to the client for clarification. How heavy should the product be? How much should it cost? Will the user control this feature or is it hard-coded? etc… Then, the client will review the draft and make comments. Generally, it’s eye-opening to the client and they start to see the value, especially if it identifies things that might have been hidden otherwise. This is likely to provide similar results for most process tools.

Have you ever looked back and wished you’d implemented some process theory before things went wrong?



Every challenge is different – Tell us about yours.