Structuring Problems in Development Organizations (Part 2)Conflict Resolution Diagram in Product Development Organization (Cloud)

How to Create a Conflict Resolution Diagram (Cloud)

In the second session, we will begin with an explanation of the TOC cloud (conflict resolution diagram).

As we discussed in the first session, we believe that problems that occur in an organization are caused by human behavior.

And human behavior is determined by the evaluation criteria of the organization. This can be thought of as the standard for personnel evaluation. When an organization achieves results as an organization, people act toward the goals set by the head of the organization or the behavioral goals that are directly directed by the head of the organization. This is the “evaluation standard” or the “objective” of the action.

Furthermore, these evaluation criteria are derived from the policies of the organization as considered at a higher level, the management level.

The “policy” is considered by the top management, and multiple goals or evaluation criteria are set by the middle management in line with the policy.

People then take action by undertaking or selecting some of the multiple evaluation criteria.

The cloud (conflict resolution diagram) is completed by placing appropriate sentences (sentences containing predicates, not words) in the five boxes A, B, C, D, and D’ as shown below.

First, the “action” causing the UDE is placed in D.

Next, in D’, the opposite action of D, or the action that should be taken, is placed. The important thing to remember is that D and D’ are not compatible within an organization.

Once D and D’ are entered, the next step is to consider the purpose of each of D and D’. The purpose of the action is to think about why the action is being taken, or as mentioned above, what are the things that are causing the action to be taken, as a basis for people to evaluate the action, and then put in the appropriate sentence.
Put a B for a D and a C for a D’.

The most important thing in the cloud is how to find these different evaluation criteria of B and C. We try to capture the dilemma that is caused in the organization by these two evaluation criteria.

Finally, A, this is the common objective of B and C. If B and C are the organizational objectives of the middle managers, then A would be the major objective of the top management, or the top policy.
In other words, A is more abstract or from a higher perspective than B and C.

Creating a cloud can be difficult if you are not used to it.
A→B→D, or　A→C→D’, with different perspectives taken from a higher level of abstraction, to the middle, and finally to concrete actions.
Furthermore, the original aim of the cloud is to capture the dilemma within the organization that is causing the problem accurately, simply, and without assumptions, so language and written expression skills are essential.

Now then, let’s take the UDEs (bad symptoms) mentioned in the previous article as an example to create a cloud.

The responsible party is unclear.” Consider the UDE that says.

Let’s think about it together. What kind of situation can be assumed to cause this UDE?

Isn’t it ideal for a development project to be carried out by a single development team under one strong promotion leader?
Here, perhaps some of you may disagree, but let us first consider this state of affairs as a starting point.

This strong promotion leader has extensive knowledge of the product that is the subject of the project.
Not only does the leader have his or her own area of expertise, but he or she must also offer opinions and make decisions about technologies and other matters outside of his or her expertise.
Members other than the leader trust the leader and consult the leader about all their problems.

In other words, all information is gathered by the leader.

In addition, the daily work of these leaders is visible to all members.
So members naturally know what other members are doing and what they are struggling with.

Suppose this is a state of affairs that is, in a sense, going well.

So, my own feeling is that many companies these days have a project structure that is centered around a specialized organization.
I assume that the purpose of this is to clarify the areas of expertise of the engineers, to commonize the technologies in their specialized fields in the company’s product line, and to efficiently deploy the specialized technologies in the products.

It is sometimes called a matrix organization, but it may also be aimed at streamlining product development and preventing disparate products from being created by specialized teams divided by field of expertise, since they can efficiently develop multiple product models.

The matrix organization is a team in charge of a single product (called a vertical organization) and an organization that organizes specialized fields (called a horizontal organization), and the matrix organization is designed to control both the vertical and horizontal sides of the organization well.

When the matrix organization was just born, the vertical organization still tended to be stronger, and the leader of the vertical organization had a strong influence on the members, and product development went well. However, as the matrix organization continues for a long time, the members’ sense of belonging to the specialized organization gradually increases, the members become closer to the horizontal organization leader than the vertical organization leader, and the information to the vertical organization leader is lost.
Furthermore, other team members can see the actions of the members in the specialized organization, but they gradually lose sight of the members in other specialized organizations, i.e., other specialized engineers who are developing the same product.

Since there are multiple specialized organizations, the number of so-called leaders increases. And when the members’ sense of belonging to the professional organization becomes higher than their sense of belonging to the vertical organization, the influence of the vertical organization leader declines.

In contrast to the vertical organization leaders, who have less influence and less information, the horizontal organization leaders gain more influence and have more say in the product project.
However, the leader of the horizontal organization is not responsible for the product being developed. They also show a tendency to stick to their area of expertise and speak out differently than their objective, which is to launch the product and make it successful.

In parallel, the competence of the vertical organization leader will decline. By not receiving real-time, serious information from members in different technical fields, the vertical organization leader is weakened in both name and reality.

This highlights the problem of who is responsible for the many half-hearted horizontal leaders facing in different directions and the weakened vertical leaders, and who is willing to fulfill their responsibilities. I think that this is the essence of the UDE called.

What is the dilemma here?

I believe that the problem may have been caused by the accelerated matrix organization to efficiently develop multiple models.
In other words, I believe that the problem may have occurred as a result of a conflict between the need to enhance the efficiency of multiple model development by strengthening the organization by function (horizontal organization) and the need to develop individual models in the best possible way by maintaining the organizational strength by model (vertical organization).

Both the efficient development of multiple models and the solid development of individual models may have occurred under the common goal of “continuing to develop good products.

These two objectives are not in conflict with each other, but rather, they are two objectives that need to be achieved at the same time, but each of these objectives requires completely different actions.

This can be represented in the cloud as shown in the figure below.

We believe that the dilemma of strengthening the organization by function (horizontal organization) and maintaining the organizational strength by model (vertical organization) has caused a UDE in which the “responsible party is unclear.

From the top management’s point of view, they have a major policy to increase the company’s profit by continuously developing good products anyway, and the middle level managers under them, following the top management’s intention, strengthen the function-based organization in order to contribute to the profit by establishing a system that can efficiently develop multiple models at the same time, but the individual So we have a UDE in which the real person in charge becomes unclear, at the expense of the objective of focusing on the quality of the model, and at the same time, the small responsible persons become disorganized and unclear.

However, there are still elements to consider.
The efficient use of multiple models can be paraphrased as a focus on expanding the product lineup, the emphasis on the quality of individual models is a bit vague, and there is the view that this may be unavoidable if development is challenging.

Or, to put it more simply, there may be the idea that there are just not enough excellent leaders, or that there were not enough people with the right qualities to become leaders in the first place.
However, it seems that the emphasis on product lineup expansion and low-risk product development, rather than taking on new challenges, focusing on a single model, or strengthening horizontal ties, may have contributed to the inability to create strong leaders.

Thus, it is important to think deeply about the nature of the problem, using UDEs as a starting point, and we could first try to create one cloud for one UDE.

Difficulties in Creating a Cloud

The steps and process of creating a cloud are as explained above, but it can actually be quite difficult if you are not familiar with it.

There are a few points that are easy to make mistakes and we will tell you about them.

The first thing to keep in mind is to make sure you understand that the cloud is an objective reflection of the facts as they are happening.

In other words, it is not a reflection of your opinion.

It is created as if it were a mirror of what is happening right now.

The most common mistake that I myself first fit into is to put solution-like ideas into the cloud.

Remember also that D and D’ are actions.

And B and C are the objectives that cause the actions D and D’, and A is an even higher objective, a larger objective that encompasses B and C.

It is also important to grasp that the level of abstraction rises from concrete actions in the order of D→B→A.

Validating the Cloud

Creating a well-crafted cloud is the result of problem solving.

If the cloud is not created correctly, that is, if it does not accurately and objectively capture the current situation, it will be impossible to find a solution to the problem.

Therefore, we check the cloud after it is created to make sure it is done correctly.

The check is done by reading aloud to see if the logic is consistent.

The cloud is connected by the necessary condition logic.

It is checked by reading aloud as follows

To be A, it must be B.

To be B, it must be D.

To be an A, one must be a C. To be an A, one must be a C. To be an A, one must be a C.

To be C, one must be D’.

D and D’ are incompatible.

If you read this out loud and find any parts that feel uncomfortable, it is possible that the cloud is not done correctly.

Let’s examine the cloud we have created.

In order to keep developing good products, multiple models must be developed efficiently.

To develop multiple models efficiently, authority must not be concentrated in the hands of a single leader.

To continue to develop good products, the quality of each model must be improved.

To improve the quality of each model, authority must be concentrated in the hands of a single leader.

Not concentrating authority in one leader and concentrating authority in one leader are incompatible.

What do you think?

If you read them together and are comfortable with the logic connection, then the configuration of the cloud is fine.

In the next issue, we will explore the root cause of all the problems by creating clouds for several more UDEs and considering whether we can write a common cloud for all UDEs.

＞＞Go to Part 3: Finding the Root of the Problem (Core Crowd)

＜＜Back to Part 1: “Viewing Organizational Problems as UDEs

Reference articles：

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