Structuring Problems in Development Organizations (Part 3)Fundamental Problems of Development Organizations

Completing the Cloud for Three UDEs

In the second article, we have just created a cloud for UDEs where the “responsible party is unclear”.
In this issue, we will try to create a cloud for another two UDEs.

Of the 15 UDEs listed in the first issue, we will choose those that seem important and have different qualities from “the responsible party is unclear”. This time, we will address the following two UDEs.

• Schedule delays are the norm
• Fewer engineers are available to understand the entire product

Following the procedure described in the second article, we will represent the two UDEs in the cloud.

First, let us consider the nature of the problem of “schedule delays becoming the norm.

Although there are many possible factors that could be contributing to this problem, and each company’s situation may be somewhat different, there are a few things in common, so we will consider this issue in some depth.

First, let’s consider a few hypotheticals as to why the dates are being delayed

• They are trying to proceed with a schedule that was originally unreasonable.
• Unforeseen problems always occur, and it takes time to deal with them.
• Poor quality on the first prototype and time consuming to resolve quality issues

What dilemma we have here, in my experience, seems to be the root cause of trying to proceed with product development at the product planning stage with a mixture of unestablished and established technologies, and with an unclear level of technological perfection.

You won’t know anything unless you build a prototype first! I feel that the company itself has come to believe that it is natural to start product development with a large technological risk on its shoulders.
I think they are unaware of the fact that they are not even thinking about solving major technical problems before building prototypes, or “haste and speed” so to speak.

Intuitively, many people believe that the fastest way to solve a problem is to create something immediately. Toyota’s development method is also called “set-based development,” in which small experiments are repeated to build up knowledge on technical issues, and all technical issues are solved before detailed design begins.
This may also sound obvious at first glance, but many development organizations in the manufacturing industry are not able to do this. In general, we read point-based design as a way to start detailed design with a single point of contact, leaving a number of technical risks unresolved.

With this background in mind, I have considered the following cloud.

When I examine this cloud, I don’t feel particularly uncomfortable reading it aloud, but there is something about it that still doesn’t feel right to me personally.

This is because it seems too extreme to say that you have to solve all the technical issues before you can start.

It is not a bad thing that technical issues arise after development has begun. In fact, it is natural for technical issues to arise during development, and I think there may be a problem with the ability to solve technical issues in the first place.

What are the organizational behaviors that make schedule delays the norm?

For example, what about the hypothesis that many members of the development team are assigned to product development without sufficient knowledge of the product?

Suppose that as the company grows, the number of employees continues to increase and the number of models developed continues to increase to keep company sales up.

If the balance between the number of veterans and mid-career employees who have experience in product development and the number of young people who have newly joined the company is gradually changing, wouldn’t the average level of product knowledge as a team be declining?

Furthermore, if, in order to efficiently develop many models in a short period of time, the division of labor is promoted, the development process is standardized, and model development is carried out mechanically rather than being left to the engineers’ abilities, won’t the development capability of the organization eventually decline and the problem solving ability also decline?

If this is the cause of the normalization of schedule delays in product development, what kind of dilemma is being created there?

So I thought of another cloud.

What do you think?

Personally, I think the second cloud fits better as a cloud for the UDE that “schedule delays have become the norm.

Thus, in creating a cloud, it is important to verify in one’s own way whether it really captures the essence of the problem, apart from scrutinizing the logic of the cloud by reading it aloud.

Next, considering the essence of the third UDE, “the number of engineers who can understand the entire product is decreasing,” I hypothesize that what is happening is that there are fewer opportunities to gain knowledge of the entire product in the course of daily development work.

In order to gain knowledge of the product as a whole, one needs to know what people outside of one’s own responsibilities are doing. I think that if you just look at the day-to-day development activities and see what kinds of things they are struggling with and what kinds of issues they are working on, you will begin to understand the “technology” that other people are doing.

You may also need to look at the process of integrating the development of the entire product.
Through the process of combining and connecting the individual subunits, and through the integration of the subunits and then testing the integration of the subunits together, we can understand the connections between the subunits.

As you think about it so far, you may have noticed that the same dilemma of the matrix organization may be involved as in the case of UDE, where the responsible party is unclear.

Many companies I have seen have a professional organization-centered development structure.
Although they are not completely out of touch with people in other technical fields who are developing products, they think only about their own areas of expertise and do not share in real time the current work and concerns of people in other areas.

If a problem arises in another area, they may learn about it, but they do not directly see how the person in charge of the problem worries about it, consults with others, and how the problem is resolved.

A matrix organization is also referred to as a vertical or horizontal organization. Both are important, but if you don’t keep track of the good and bad points of both, you will end up being drawn to the characteristics of one or the other.

Creating specialists will foster the company’s technology, but I fear that if the area of expertise becomes smaller and smaller, those engineers will become useless in other areas.
I also feel that as the sense of expertise grows stronger, attachment and attachment to the product as a whole will diminish.

I think the conflict is between developing the technology of individual ministry areas, or elemental technologies, and developing the ability to assemble the entire product by bringing together elemental technologies.

Since the same cloud with unclear responsibility is boring, we have changed our perspective a bit and considered the following cloud.

Now, we have three clouds for three UDEs.

Finding Core Crowds (Root Causes) Using the 3-Cloud Method

Three of the 15 UDEs were selected to create each cloud.

UDE1: Responsible party is unclear

UDE２：Schedule delays are the norm

UDE３：Fewer engineers are available to understand the entire product

The TOC (Theory of Constraints) problem-solving framework shows how to discover the core cloud by finding commonalities among the three clouds, called the 3-cloud method.

Specifically, from the three clouds, three A’s (A1, A2, A3), three B’s (B1, B2, B3), three C’s (C1, C2, C3), three D’s (D1, D2, D3), and three D’ (D’1, D’2, D’3) are extracted, and commonality in the text is extracted.

Personally, I would prefer to take the method of creating a new cloud of commonality by carefully deciphering the three clouds, rather than the method of mechanically finding commonality in the sentences in the form of Japanese language skills.

Let’s look at the three clouds above and consider the common dilemma.

In each case, the company’s well-meaning approach has left something else behind, and as a result, a variety of problems have occurred.

Looking at these three clouds and considering the situation of actual development organizations, it seems that various companies have prioritized expanding their existing businesses and product lineups and continuing to release product lines that can demonstrate technological progress faster than the competition, even if it is something small, and as a result have left behind the idea of developing organizational capabilities to consistently develop superior products by putting customer satisfaction and quality first for each product.

In my own way, I have created a cloud that integrates the three clouds as follows.

What do you think? Does this apply to your organization?

Essentially, I feel that the company has been operating by prioritizing the efficiency of model development over the development of engineers, and the bill for this has come due.

Of course, this is not true for all companies, but I believe there is at least some commonality among the many companies I have supported, as I mentioned at the beginning of this article.

I can see circumstances where sufficient preparation has not kept pace with the increase in the number of employees and the number of models developed, but it appears that the emphasis on continuing to make products there without failure, regardless of the level of the engineers, has destroyed the potential for product development that would have surprised both customers and the company by trusting the potential of the engineers and leaving them to it.

What is important is how to get out of this situation. In cloud creation, we seal off the idea of what should be done in the future, and first of all, we objectively, calmly, and correctly assess what is happening in the current situation.

I would be very happy to hear your opinions on this idea and this cloud.

Now, I randomly selected three UDEs to create three clouds, and from them, I created one cloud that represents the common content of the three clouds by expressing what they have in common.
In the TOC, we call this the core cloud.

Abstracting and expressing the common content from the three clouds can be a bit of a difficult task.

While simply summarizing the statements into common content, the core cloud is completed by deciphering the essential issues.

The core cloud is taken as a hypothesis that maybe this is the root cause of all the problems, the underlying dilemma. Yes, it is. At this stage, it is just a hypothesis.

However, at least 3 of the 15 UDEs are represented in the cloud.

In the next article, we will examine whether this core cloud is causally related to all 15 UDEs, except for the 3 UDEs.
If the core cloud is causally connected to all 15 UDEs, then solving this core cloud will solve all the major problems of the development organization.

Stay tuned for the next installment.

＞＞Go to Part 4 “Examining Root Causes with Causal Relationships

＜＜Back to Part 2: How to Create a Conflict Resolution Diagram (Cloud)

Reference article：

What is TOC? ~Theory of constraints applicable to product development