Is it taking too long to solve the quality problems that occur during the product development process?!
Whether it is because of the complexity of the product system or the lack of actual skills of the engineers, it takes a lot of time to solve the quality problems and troubles that occur in the product development process, which has a great impact on the overall schedule and has become a major problem for the development organization. How can we improve our problem solving ability?
The aim of Lean Product Development, which we recommend and practice, is to develop products in such a way that they do not cause quality problems in the first place.
Contents of this article
Quality problems are caused by a lack of understanding of the product’s operating principles and architecture
I believe that there are two major causes of quality problems: human error and lack of understanding by engineers.
I believe that both problems are addressed by including a mechanism in the development process to detect problems as early as possible through design reviews and unit tests.
In a sense, it is a competition between companies to find problems as early as possible upstream, or to create a development process that does not create problems, and as a result, I think this is where the difference between companies can be made.
I think the common thread among many companies’ efforts is to change the development process to one that does not create problems.
Set-based development, which is a key element of the lean product development method we are promoting, is a method of development while learning. It is believed that development engineers will not create problems during development as their understanding of the product’s operating principles deepens during the learning cycle.
In other words, it prevents problems from occurring due to lack of understanding, which is one of the factors that cause problems.
So, what kind of understanding is lacking?
The common denominator in the development departments of many manufacturing companies is that the number of people who fully understand the principles, or architecture, of the entire product has been drastically reduced.
Due to the increasing division of labor in product development, each engineer is often in charge of only a small part of the overall system, and although they have a certain amount of knowledge and experience with the units and parts they are in charge of (although even this is sometimes in danger), there are fewer and fewer people who can properly explain the connections between units, the overall configuration, and the distribution of functions in the overall system.
When you repeatedly develop the same type of model, you can do the development itself even if you don’t understand the whole thing because you keep making small improvements for each part.
During the development process, knowledge is lost from engineers and technical organizations who have spent several years without questioning the coordination between units, or the functions and performance that are established by the architecture (overall configuration).
Even veterans who had a deep understanding of the operating principles of the entire product would retire without feeling the need to leave the company with knowledge that would not be sought after by future engineers.
About 70% of quality problems are inter-unit coordination and architectural problems
Experience has shown that more than 70% of quality problems that occur during development are problems with inter-unit coordination, that is, the interface between units or between components.
Even if it is a design problem within a unit or component, most of the problems are caused by not fulfilling the role determined in the architectural design.
When it comes to reusing designs and past unit designs, I believe that the reason why units and components that worked fine in past models do not work in newer models is almost certainly due to the fact that we do not realize that the interfaces or the function and performance allocation between units have changed.
The concept of modularized design is widely used as a method that enables design reuse and greatly improves the efficiency of development, but it will fail if it ignores the allocation of functions and performance based on architectural design.
Designing the architecture, in other words, the overall configuration, has the very important task of allocating functions, performance, and quality assurance mechanisms.
Repeated development of similar models will neglect this architectural design, creating many holes in the architecture and spreading the problem.
Problem solving is like a doctor’s diagnosis of a disease, looking for the true cause
I believe that solving quality problems in product development is just like a doctor interviewing a patient to find the true cause of the disease.
The patient’s symptoms, where does it hurt, when does it hurt, what kind of pain, how often does it hurt? These are just the symptoms that eventually appear on the surface.
From the combination of symptoms, several possibilities come to mind, and we check them one by one.
A poor doctor (and I am not accusing anyone of this) will not be able to think of a wide range of possibilities and will settle on a single possibility.
“It’s just a cold. It’s just a cold. “It’s just a cold.
But it’s not uncommon to hear that there’s actually a scary disease hiding in the background.
A good doctor has a way of verifying this possibility, saying, “This kind of check will give you this kind of result.
If that check is off, I check the next possibility. Or, to see if there is anything I didn’t hear fully in the interview, I face the patient again to confirm the symptoms, or the phenomenon that is happening.
A doctor’s knowledge means that he or she has a thorough understanding of the structure of the human body.
In a normal state, the human body is kept healthy by the coordination of many organs, blood and other body fluids.
It is not for a layman to talk about the workings of the human body, but doctors use this knowledge as a base to identify the causes of abnormalities.
When a quality problem occurs in a product, it is also a symptom of something abnormal.
It may be a sign, or the symptom may rarely be reproduced.
To solve quality problems in product development, think of the possible causes of the phenomenon while considering the principles of the product.
I believe that the best way to solve a problem is to hypothesize many possibilities and then eliminate them one by one to get to the true cause of the problem.
To do this, it is absolutely necessary to understand the principles, configuration, function distribution, and performance distribution of the entire product.
I don’t mean to make a distinction between good doctors and not-so-good doctors, but in addition to knowing how the human body works, a good doctor is able to draw out possible possibilities and hypotheses from the symptoms that are occurring, and I think this is a part of experience and ability (or sense) apart from knowledge.
The same applies to problem solving in product development.
I believe that a good technician who can solve problems has a base of knowledge about the product and the ability to draw out possible causes from the symptoms.
Learn product architecture and improve organizational problem-solving skills
As I mentioned in the beginning, in the product development of many manufacturing companies, the people who have a full grasp of the entire product architecture and operating principles are no longer in the company, and furthermore, in the repeated development of existing products, the ability of the organization to solve problems has deteriorated due to the continuous design of partial improvements without the need to return to the product principles.
If this is the case, I believe that by going back to the principles of the product and architectural design again, we can improve the strength of the product and also enhance our ability to solve problems when they occur.
Now, the question is how to regain the lost knowledge of product principles, etc. In concrete terms, I think the only way is to learn them honestly as an organization.
I have come up with the following methods.
- Structuring the transfer of knowledge from the remaining veterans who understand the entire process
- Systematic learning by using tools among members who do not know the whole story.
I will explain each of these methods below
Each of these will be explained.
Structure the transfer of knowledge from the remaining veterans who understand the entire product
If there are still veterans in the company who understand the entire product, then a system to retain their knowledge in the company should be created and implemented as soon as possible.
Specifically
- Leaving the knowledge in the form of reports
- Passing on the knowledge orally in the form of lectures
The following two methods can be considered.
It would be best if the veteran could write the report (we recommend A3 report) comfortably, but there are many veterans who think, “Don’t you understand that? Rather than leaving it up to the veterans, I think it is better to take the initiative of the people who will receive the knowledge.
The first step is to systematically discuss what kind of know-how is hidden, that is, what is the so-called “tacit knowledge” that veterans take for granted.
In other words, define what needs to be passed on.
After deciding on some themes and the contents to be handed down, assign a person to be in charge of the handing down, and the assigned member will have the task of writing the report.
The members who are given the theme will write the report by asking for the know-how from the veterans.
Naturally, the cooperation of the veterans is necessary, not only to respond to the interviews, but also to review and give advice during the process of writing the report.
In addition, higher level managers need to see the situation as much as possible and participate in giving advice.
Let’s proceed with the understanding that this will be an important work to recover the “knowledge” assets of the organization.
There is also a way to pass on knowledge orally in the form of a lecture, although it may be less dense than leaving a report.
Ask a veteran to decide on a theme for disclosing tacit knowledge, and pass it on to multiple members in a lecture format using the required number of days.
If the veterans themselves are aware of the problem to some extent, it will work well, and since the lecture materials will be left behind, it will be possible to avoid the know-how from disappearing completely.
The only disadvantage of this method may be that the responsibility for handing down the knowledge is distributed compared to the report method, which gives responsibility and motivation to the person in charge of receiving the information.
In any case, don’t leave it up to the veterans and the field, but make sure that the management intervenes to ensure the completion of the inheritance.
Systematic learning by using tools among members who do not know the whole story
The following are two tools for organizational members to learn and master the structure and principles of the entire product themselves.
- Functional structure development diagram
- Cause-and-effect relationship map
It doesn’t matter which tool you use, form a team and give them the mission of representing the overall product structure and principles with the tool.
If a group of people who do not know the whole product get together and work on it, they will not be able to complete it easily.
It is important to realize that we don’t know a lot.
It’s also important to realize that we don’t know much, and it’s very meaningful to discuss things with other members.
If the members can’t solve the problem, they will ask around to see if there is anyone else who knows about it. This also leads to the activation of internal technical communication or the inventory of internal knowledge, which has a very significant effect on the activation of the development organization.
The two tools themselves are not that difficult to create. The difficulty is that you don’t know what the architecture is.
Try to deploy it as a management-led, key activity for your organization.
Here is a brief description of each tool.
Functional structure development diagram
The functional structure diagram is a tool also used in VA (Value Analysis), etc. It analyzes the functions of a product hierarchically and links the decomposed functions to the unit structure and component structure.
Specifically, the hierarchy of functions is drawn on the left side, and the structure of units and parts is drawn on the right side, and the two are connected.
The figure below shows a functional structure development of an vacuum cleaner.
The right side of the functional structure development diagram is the so-called component structure diagram.
In VA, this diagram allows us to understand the cost of the parts, and by reading it as the cost of the function, we can check what kind of cost is being incurred for the function, and aim to change to an appropriate cost structure.
With this diagram, we can understand what units the function is broken down into and what kind of linkages exist between the units.
Causal Relationship Map
The causal relationship map is explained in detail in another article, “Accelerate Product Development Innovation with Causal Maps”
The causal relationship map is a very important tool in the lean product development methodology. It is a diagram that connects customer value variables and design variables in a causal relationship.
It is a tool that shows the relationship between customer values through design variables and what kind of technological development should be done to seek new customer values, based on the basic premise that the main purpose of development is to increase customer values.
It is a very useful tool to get a bird’s eye view of the current product in terms of customer value and technology.
The figure below shows a causal relationship map for a vacuum cleaner.
Causal relationship maps can be used in many ways other than for the purpose of helping the organization understand the composition and principles of the overall product and improving problem-solving capabilities, as explained here.
First of all, I would like to see cause-and-effect mapping become an integral part of the development process, and I hope that it will be useful in revitalizing the development organization by increasing the level of proficiency in creating cause-and-effect maps within the organization.
Please refer to the following reference articles.
Reference Articles：
Accelerate Product Development Innovation with Causal Maps
Summary
The goal of a product development organization is to develop products without causing quality problems in the development process.
In order to achieve this, one of the directions we aim to take is to promote reform of the development organization by adopting lean product development methods.
However, even in such a situation, I think it is difficult to reduce the occurrence of quality problems to zero in product development.
Therefore, what I have been explaining in this article is how to improve the ability of an organization to solve problems when quality issues occur.
I have talked about how a good doctor can find out the cause of a disease from the patient’s symptoms, and how the problem-solving ability in product development has a lot in common with the way the problem-solving ability should be.
The conclusion is that the most effective way to improve problem-solving ability is to deeply understand the structure, composition, and principles of the entire product, in other words, the architecture.
It is necessary to structure the flow of daily activities and processes in such a way that the entire organization can have a deep understanding of the entire product.
Let’s design a management-led mechanism for the organization to learn, and ensure that it is implemented.
I believe that reforming an organization can only be accomplished by learning the methodologies described in this article and having the leadership to implement them.
We have a lot of experience in implementing various methodologies and management techniques to enhance the organizational strength of product development organizations.
We are happy to consult with you about organizational reform of your development organization.
Please contact us using the form below.
We will contact you as soon as possible.
