Contents of series of articles
Part 1: Viewing Organizational Problems as Bad Symptoms (UDEs)
Part 2: How to create a conflict resolution diagram (cloud)
Part 3 Finding the Root of the Problem (Core Cloud)
Part 4 Verifying Root Causes with Causal Relationships
Part 5: Lean Development Methods to Break the Logic of the Core Crowd
Examining Root Causes with Causality
In the last issue, we created one core cloud from the three clouds created from the three UDEs, considering the actual situation happening in the development organization.
Once again, the core cloud is shown below.
In this cloud, engineers are gathered in each technical area to specialize in a particular area of expertise, and by dividing the workforce, the priority is placed on streamlining the development of existing products at the expense of both customer satisfaction and employee development.
Both of these ideas, improving short-term profitability and balancing customer satisfaction and employee development, should not be discarded, but the dilemma is that only one of them can be achieved because only one course of action can be taken.
Here, once again, is a list of the 15 UDEs listed in the first issue.
- A lot of time is taken up with chores
- Responsible parties are unclear
- A lot of rework is occurring
- Failure is denounced
- Similar failures are repeated
- Fewer engineers understand the product as a whole
- Young employee turnover is increasing
- New concept products have not been created for a long time
- Veteran’s knowledge and know-how do not remain in the company
- Not knowing what others are doing or what is going on
- Schedule delays have become the norm
- Lack of independent prototyping and proposal of ideas
- Young people do not realize the growth of their technical skills
- Know-how is not documented
- Failure to understand the real issues and potential needs of customers
I feel that the first thing that is likely to happen as a result of promoting the efficient use of engineers is that “the number of engineers who can understand the entire product is decreasing.
By dividing the workload of engineers into a so-called matrix organization for efficient utilization, once “communication with members in other technical areas becomes less frequent” and “opportunities to see up close the situation of developing the entire product decrease,” it is likely that the number of people who are familiar with their specialized areas but not with the overall connection will gradually increase.
In addition, as specialized organizations are subdivided and individual technical areas are linked together to create an entire product, problems are more likely to occur at the connection points between specialized areas.
In other words, although technological innovation within a technological area is progressing, problems tend to occur at the interface between areas.
It is often said that if one person does all the development, there will be few problems, but if more people are involved and the work is divided among them, there will be as many interfaces as there are people, and problems are likely to occur there.
From the core-cloud dilemma, the first bad thing that happens is that
- Communication with members of other technical areas becomes scarce
- Reduced opportunity to see up close how the entire product is being developed
- Problems are more likely to occur at the connection points between areas of expertise
Three situations are expected to occur.
These are not included in the first 15 UDEs listed, but we will take them as additional ideas.
We will connect them as causal relationships from the source of the arrow to the destination.
The idea is that three symptoms arise from the core-cloud dilemma, two of which are “less communication with members of other technical areas” and “fewer opportunities to see up close how the entire product is being developed,” leading in a chain to the UDE of “fewer engineers who can understand the entire product.
In the figure, the yellow background squares represent the UDEs originally listed, and the white background squares are the additional symptoms. Also, the ellipses written on the two arrows indicate the AND logic of the two arrows, i.e., that both are valid and the result at the arrow ends is produced.
We will further extend the above diagram with this concept.
We are going to look at what problems are connected in the negative chain of events that derive from the core-cloud dilemma.
After much consideration, we have created a chain of events as shown in the figure below.
All 15 UDEs listed in the first issue are represented in the figure.
The squares with yellow backgrounds are the UDEs originally listed, and the squares with white backgrounds are the symptoms added.
For 13 of the 15 UDEs, we can see that they are connected by a chain of events from the core cloud dilemma.
However, for the two UDEs marked with an asterisk (*), “Failure to understand customers’ true issues and potential needs” and “Know-how not documented,” although they are related to the other UDEs, they are not connected by an arrow from below, i.e., they are not occurring as a chain from the core cloud.
These two UDEs, then, are the starting point for the other symptoms.
If all UDEs are connected as a chain from the core-cloud dilemma, i.e., causally related, then this would indicate that if the core-cloud can be solved, all UDEs may be solved.
However, in the diagram we have examined, two UDEs occur regardless of the chain, which means that in order to solve all UDEs, the core cloud and these two UDEs may be the only way to solve all problems.
Also, in the lower left corner of the figure, there is a square with a pink background. It states, “Efficient development of the model lineup is required.” This is a prerequisite for the symptom of a “stronger specialized organization.”
Conversely, without this precondition, the core-cloud dilemma itself may not occur, and can be considered a clue to solving the core-cloud.
In TOC (Theory of Constraints), a diagram that links the chain of UDEs and other symptoms that started from the core cloud dilemma with causal relationships is called a status quo tree (CRT).
And this can be called the structure of the problem in a development organization.
It shows that many problems, not only in development organizations, are complex, but often there are only a few underlying problems.
The status quo tree can be a much more complex diagram if you drill down into the details.
If you follow it logically, you may find a chain of conditions or symptoms that are not well represented.
The important thing is to be able to grasp the source of the chain without omission.
In this study, we concluded that the core cloud and the two UDEs are the starting point from which all the bad symptoms are connected.
It is important to see whether or not the organization and management can agree that this situation can be explained by a chain of three root problems, or in other words, that the bad symptoms can be explained by a chain of three root problems.
First, let’s share the situation of this chain within the organization and have a deep discussion about it.
In the next issue, I would like to talk about how to find solutions to reform the development organization from this status tree.
So, please look forward to the next issue.
>>Proceed to the final article “Lean Development Methods to Break the Logic of the Core Crowd”
<<Return to Part 3: “Finding the Root of the Problem (Core Crowd)”
※ Based on the author’s experiences while working for a manufacturing company and his actual experiences supporting companies as a consultant, the author has created a story of organizational reform of a product development organization using the TOC framework.
Since it is based on actual experience, it is a very realistic story. Although I have not been able to explain the solution in this article, the solution is presented as a case study in the book.
Please refer to the book as well. For more information, “Break the Common Sense of Product Development Organizations!!” Please refer to the publication guide. Please refer to the publication guide.