Bringing Lean Methods To The Front End Of Medical Product Development
Most companies are familier with Lean principles. Lean is about eliminating waste from any business process, usually manufacturing. Institutionalizing the culture of holding regular kaizen events on the manufacturing floor to eliminate wasted time, effort and resources can achieve remarkable results in a very short time. However, the benefits may be harder to achieve or accept culturally when the process being optimized is less tangible and visible. Though the principles of using Lean across all phases of product development were well documented by Toyota, I’ve seen fewer companies, at least in the medical hardware and software/IT spaces, adapting Lean to the front end of product development. It may be that someone’s idea of waste in these functional areas may be someone else’s primary responsibility. That doesn’t mean that Lean can’t be used to optimize these functions, but be prepared for some surprises as to how much waste you find. I don’t mean don’t do it, though. My experience is that if engineers are aware up front that their jobs are safe, they will readily see the benefits of eliminating waste and being more productive, even if their roles or daily tasks change in the process. I suggest starting small with training in Value Stream Mapping and working up.
I’m curious to hear others experiences in bringing Lean methods into the front end of medical hardware or software product development. Your thoughts?
craig@mhealthconsulting.net
Craig,
In my experience in medical software development as well as software and product development in other verticals, you have to be a little careful in applying lean principles to product design. Design requires openness, trial and error (some waste), and maximum feedback loops about what works and what doesn’t. The best designs may actually encourage “waste” in the very beginning in an effort to find and hone the design that works.
In other words, it’s up to users to define what the value is in value stream mapping. For developers it can be largely unknown and unknowable without constant feedback from users of the product. Developers up front may need to spend a lot of “wasted” ideas and work finding the what does work for the users.
Leonard, you make a good distinction and I should have been a bit clearer in my terms. I agree, the so-called “fuzzy” part of front end product development requires exploration and experimentation, which is usually not part of a Lean cycle — although I’m seeing more and more companies treat this as a managed and optimized process also.