» » next post - Dan Jones: Lean in Product Development
« « previous post - Michael Ballé: Learn to solve your engineering problems of today to design better products tomorrow

Jim Morgan: Great people make great products

By , - Last updated: Thursday, March 7, 2013 - Save & Share - Leave a comment

I would like to extend my thanks to Michael Balle’ for the opportunity to respond to this question.  There are already many very good responses; I hope I can make a small contribution.  For me, product development is the center of the universe, where unique value is created from nothing…. or it’s not.  And that’s truly what is at stake.  It can seem complex and a little daunting.  But there is little that is more important to the success of an enterprise – and, in my view, it can be the most meaningful and rewarding work you ever do.

Although a bit redundant, it is none the less important to emphasize previous respondent’s cautions about manufacturing tools transferred directly into the product development environment.  It demonstrates a fundamental lack of understanding of the work.  I also agree it is very difficult to adequately answer your question without more information about your current situation.  In fact, it is more likely that I may do more harm than good without proper knowledge.  So I thought I would ask some questions and make a few observations for you and your colleagues to consider.  How do you start to bring lean into product development?  First understand your current state.

First, it is probably important to understand my bias.   I see product development as an integrated system comprised of three interdependent elements; People, Process and Technology.  As you work to “improve” one it is important to consider the potential impact to the other two elements.  It is also important to look for potential synergies when you truly understand these interdependencies.

Great people make great products.  There is no doubt that “People” and People systems are the  most important part of a product development system.  It is unfortunately often over looked as we jump to “process or tools solutions”.  There are a number of “People “questions you might want to consider.  First, do you have a system to encourage the achievement of technical mastery on the part of your engineers?  This is more than formal education.  Do you have mentoring processes that enable the transfer of tacit knowledge?  Do you have mechanisms and tools that help to identify gaps in knowledge and develop plans to close those gaps?  Secondly, does your whole team align around delivering value to the customer?  Does everyone involved understand how they uniquely contribute value?  Do they have sufficient understanding of critical product attributes, manufacturing processes, cost and quality drivers?  Third, does your organization enable “cross-functional calibration?  Including your critical suppliers?  Fourth, do you have a “go to gemba” culture?  Do you have cross-functional, intense design reviews around the product?  Do you go to the plant? Talk to the folks who have to build your products? Do you go and see your product in the field?  Talk to customers? Or do you have “excel engineers” who never leave the conference room?  There is a saying at Toyota, “never trust an engineer who does not have to wash their hands before they eat dinner”.  This is powerful and true in any product development environment, even if only metaphorically.  Fifth, and finally, Do you have Chief Engineers who own the product and it’s development from beginning to end?  And do you have a system to develop them?  What about other PD leaders, do they have deep technical competence and passion for the product?  There are many tools, mechanisms and processes that can be effective in improving your people and people system capability.  Far too many to get into here so I will ask you just one more question.  If you truly believe that the best people develop the best products, do you have effective means to attract, develop, place and retain the best in your industry?

Developing products is a process.  It can sometimes be difficult to see, and it is definitely not the same as stamping metal, but it is no less a process.  My first question is, do you actually understand your current development process?  It may be quite different than what is written down.  And don’t forget support processes like tooling up, supplier sourcing or engineering budgeting.  Second, do you understand its capability?  Have you done a process capability study?  Do you know where the failure modes are?  Have you done a gap analysis? Third, is there clear quality of even criteria throughout the process?  Do you have a plan for every part so that you understand critical relationships?   For example, it is important to focus on compatibility before completion in engineering complex systems.  Fourth, are roles and responsibilities clear?  For everyone, including suppliers?  Does everyone understand their role? Fifth, are your work streams well synchronized?  Simultaneous engineering can be complex; different work streams are usually interdependent.   If they are not well synchronized, your process will have lots of re-work.    Sixth, is your product/cycle planning aligned with larger business objectives?  Do you make it an important part of your hoshin or BPR process?  Finally, and perhaps most importantly, is fast cycle learning and continuous improvement built into the process?   Your product development process is very important – it can be a true competitive advantage.   But it is possible to get carried away with a PD process focus and all that goes with it.  You know this is happening when you start to worry more about excellence in PD process metrics (making them all green) than in product excellence.

There are powerful tools that can super charge your product development system.  But they should be designed to enable your people and enhance your process.  There are numerous potent CAD and CAE tools and there is definitely not enough time to go through a technology analysis here.  One question to consider here is.  How many translation or storage steps does your current technology suite require?  There is often a great deal of waste associated with each one.  Second, what are your key communication tools?  Are they simple, accurate and accessible?  Is information available when required, cross-functionally?  Third, do your tools enable systems engineering and the understanding critical product attributes?  Fourth, do your tools encourage direct engagement and cross-functional collaboration or do they promote isolation?    Finally, do your tools support your people, or, are your people slaves to your technology?

So, I haven’t even scratched the surface and I feel like this answer is already too long….and I am not even sure I have helped…   At a high level, my suggestion is to start with a rigorous analysis of the current state.  Please do not skip to diagnosis and countermeasure development.  Make sure everyone on your team understands how potentially powerful improving your product/process development system can be.  It influences nearly everything. Ask lots of questions, cross-functionally.   Identify clear, specific opportunities.  One good way to do this is through the monosukuri process where Suppliers, product development engineers, manufacturing engineers, purchasing professionals and plant supervisors examine every single element of the product and the product value stream, laying our every piece on kama kuri boards (along with competitors products in some cases) and understanding the total cost/benefit of every element of every subsystem of the product and how it could be improved.  This is an excellent way to get everyone engaged.  And that is a good place to start…

Post to Twitter

Share this post...Tweet about this on TwitterShare on Google+Share on LinkedInBuffer this pageShare on FacebookEmail this to someonePin on PinterestShare on Tumblr
Posted in Uncategorized • Tags: , Top Of Page

Write a comment

*