I saw this article on a process visualization tool called Spaghetti map. The process is relatively intuitive and is a systematic way to visualize the physical space in which processes occur. We have used it at Ximedica on processes that end up literally looking like a bunch of tangled spaghetti!
 |  |
About a month ago, I posted an article here about a little known and little-applied field of engineering called tribology – the study of interacting surfaces in relative motion. It’s a subject that I studied in college, and I thought it would be interesting to write about it. If you missed that post, you can see it here.
Little did I know that my colleagues here at Ximedica would soon run with the topic – but not in a way that I could have imagined at the time. Spurred by a comment posted on the article, one of the research team members approached me with the idea of applying the fundamental equations of tribology not just to surface interactions, but to human interactions.
Specifically, could we apply tribology to the human interactions that lead up to and take place in an operating room?
| |
Context is everything when doing front-end, qualitative research for product development. It’s one thing to ask open-ended, probing questions about the task under consideration, but it’s another to ask those questions in a setting that allows an interviewee to interact with his or her environment as he or she answers. In someone’s “natural” environment, you will get much deeper recall, demonstration and insight than you typically will in a focus group facility. But, when you are interested in doing this type of work with health care clinicians, being able to do a deep extended interview in a clinical environment can be the stuff of dreams – due to the hectic and sometimes chaotic nature of clinical healthcare settings. Imagine trying to interview an emergency room nurse about a particular device that she regularly uses – in the middle of the emergency room. 
| |
Ask any fan of F1 racing—or, if you can find one, someone who has ever driven a Ferrari to its performance limits—what makes these cars go so fast, and you are likely to get the same answer: the brakes. To the uninitiated, this might seem counter intuitive at first, but it readily makes sense. Nobody would push these 700 horsepower monsters towards corners at blurring speed without the confidence in their ability to slow down rapidly at the last moment. As product developers, we can draw valuable lessons from this simple fact as we seek ever faster means to take concepts from the lab to the commercial market successfully.
| |
My latest "aha moment" related to product development came during a recent training class on Customer Requirements. The familiar model for medical device development dictates that we start with customer (user) requirements, translate them into design inputs, design the product, develop design outputs, and then build the device. In the end, we try to get them all to line up so that we can perform verification and validation per FDA requirements. Often, there is some other requirement that isn't really a customer requirement—be it an internal business requirement or desired product feature—that we must try to fit it into this model. In my experience, it often feels awkward labeling these requirements that don't necessarily come from the customer, but still must be included in the device design. My "aha" came when the instructor put a name to these nebulous requirements: "design constraints." Of course they are! I knew what design constraints were, but had never used that terminology in conjunction with the FDA model. For example, a surgical instrument may require a size restriction to fit in the instrument case. This size restriction is not necessarily a user need, but really a design constraint that will limit the final design of the instrument to that size or smaller. Or perhaps the device maker wants to use a particular technology for product. Alternative technologies may solve the problem; however the solution is limited to the technology of choice—i.e. it is simply a design constraint.
| |
I recently attended the Advanced Problem Solving and Root Cause Analysis Workshop provided by Worchester Polytechnic Institute. Jim Leonard taught a structured root cause methodology for problem solving, which I found very useful. The steps in this comprehensive method include:
Emphasis was placed on gathering information to specify the problem through a series of control questions related to the "what, where, when, and size" of the problem. Multiple case studies demonstrated that the problem is usually half solved once the control questions are answered (which reminded me of the ending of the G.I. Joe cartoons from my childhood—"Now you know, and knowing is half the battle"). I have studied other root cause techniques including the 5 Whys,Ishikawa fishbone, events and casual analysis, and the informal interview. While I still believe these techniques are valid, I see each one as alternatives to the different steps of Leonard's problem solving process, but none as a complete structured methodology.
| |
