Lean is an organizational philosophy and process which embodies respect for people, elimination/reduction of waste, and continuous improvement. This holistic system can help product development teams - at Toyota and Honda (where Lean was born), they have proven that this methodology delivers products in 1/2 the time with 1/2 the staff size, as compared to others in the auto business. One key aspect of the Lean culture is that experimentation to learn and improve is encouraged – here is an excellent video by Honda on the 'Value of Failure'.
In the Lean world, organizations use a balanced perspective: equal parts people, process, and technology. As they strive to make improvements for a given process, it is important to make baseline measurements in order to have something to compare against after any changes are made. Thus, the "before" and "after" are critical to ensuring that the proposed experimental changes that were considered to make improvements actually need to pass the comparison test. In some cases, the experimental change to improve the process might have negative side effects and end up introducing undesirable characteristics. It is very important to watch the data to know what is happening – good or bad.
For some organizations, esp. those that take on a "you can't manage what you don't measure", they may start to think that everything needs to be measured – and this takes on a life of its' own. What they end up doing is generating a mountain of data and not much of an idea on how to extract useful information. These organizations should strive to scale back to just the essential data collected – only what is needed to determine Key Performance Indicators (KPI's). That is a separate topic that would need to be discussed at a later time.
In many non-Lean organizations, the product development culture looks toward software-based tools as the silver bullet – which may be partly driven by the companies that are selling software tools! From a Lean perspective, tools have their place, but do not drive the process. Some of the "Leanest" companies on the planet use "paper and pencil" or whiteboards to track information – and later enter this into a simple paper or excel spreadsheet. Having a real-time database that updates information every microsecond may be overkill unless that step is critical to the process.
Organizations that strive to become Lean start with the process. For the portions of the process that require recording information, the early stages of a process improvement would typically require simple, manual methods to track the results. As the process improves over several iterations (based on the data and on the experience and needs of the team), they may want to add tools that will help with the specific portions of the process that require data collection and/or algorithmic processing. The emphasis is on only spending resources (time, money, staffing) on the areas that provide the highest level of value – quality, productivity, time to market, and other factors as appropriate that are balanced by the Lean organization. Typically, a single person would guide the overall product development process – a Chief Engineer, who would embody the "Voice of the Customer" along with the deep understanding of the capabilities of the Product Development Organization and the Manufacturing Organization.
Process improvement consultants can typically help development organizations to better understand their process, to recommend potential changes that would improve the process, and to clarify the requirements for software tools that might be able to assist with the process. Note: Since the tools are constantly changing and evolving, other product development consulting firms that are familiar with a wide range of tool solutions (point or integrated) would be in the best position to discuss how each specific commercial tool would match with the requirements for a given process flow. In an ideal world, one might be tempted to create/develop a custom tool based on the requirements, but this would typically have the highest cost of ownership – a more pragmatic approach would be to select the tool that fits the best for short term and potential long term needs – and make slight adjustments to the process as needed.
In addition to specific point tool solutions that meet product development requirements, organizations may choose to utilize Product Lifecycle Management (PLM) tools to coordinate efforts between multiple product development teams, to help ensure that the process is being followed.
From research that Clarum Group has done, it has been shown that modern product development is most often a risky proposition for organizations, since only ~1/3 of all products that start are able to finish within specifications, on budget and on time. Improving the process for development is commonly needed – and the ideas outlined above may help your team on the quest to manage complexity with increased levels of success.
Andrew Cahoon is the Managing Director of Clarum Group in Austin, TX (Process Improvement Consulting) – he has more than 30 years experience in developing high tech products (supercomputers, IC design software, microprocessors) and has expertise in Lean methods, Six Sigma, Change Management, and Project Management.
This article has been cross-posted onto the Clarum Group Blog as well as the Zero Wait State Blog, courtesy of Steve Porter, Principal at Zero Wait State
Comments
I have a slightly different view on failures in NPD.I think many of this failures provide valuable lessons to organization and individuals - many of the PLM providers do claim today to reduce the failure rate but what probably they can achieve is prevention of failure in communication and collaboration - related to core technology their is less scope to what they can do.So even though NPD is a risky proposition - its a risk which organization has to take to develop products through collective experience of initial failures and trails - this cannot be completely termed as failures
RSS feed for comments to this post.