Structuring Problems in Development Organizations (last issue, Part 5)Injection and Future Reality Tree

Injection Breaking Core-Cloud Logic

In the last issue, we went as far as representing the chain of problems (UDEs) from the core cloud dilemma as a status tree.

We were able to verify that the 15 problems (UDEs) listed in the first article are cascaded from one core cloud and two starting UDEs.

In this final installment, we will focus on the core cloud and explain how to approach resolving the core-cloud conflict.

This core-cloud rivalry is made up of a variety of intra-organizational circumstances.
What this relationship indicates is that

• In order to “prioritize short-term profit improvement” in B, the company must put up with a variety of problems.
• The existence of many problems comes at the expense of C’s “balancing customer satisfaction and employee development.

This is the case.

We also believe that there are several circumstances and assumptions behind this core-cloud conflict, and that these assumptions exist for each arrow that indicates the logic of the cloud.
The assumptions may differ from company to company, but as an example, in order to “increase the value of the company,” in the logic between A and B, “short-term revenue growth must be a priority,” because “company-wide revenue is not growing as fast as it should.”

Thus, to establish the connection of the cloud logic, because … . The following is a list of assumptions that we will make about each of these assumptions.
The following figure shows the assumptions and preconditions that complement the logic of the core cloud.

The assumptions written in the red ground box are the assumed logic that complements the arrows in the cloud, but the assumptions shown above are only a sample, and each company’s situation will be different.

Please think carefully and organize your assumptions as you will also be using these assumptions in your approach to breaking down the cloud logic and solving the problem.

I think it is normal to think of a solution (solution) to a problem as what measures you will take to solve it, i.e., what actions you will take. Of course, thinking about action itself is not a mistake, because in the end, some action must be taken to solve the problem.

However, in TOC (Theory of Constraints), the next step after structuring the problem is to think about what kind of state to achieve.
In other words, the next step after structuring the problem is to think about what kind of state the various problems will be changed (solved) by creating, rather than what kind of measures or actions will be taken to solve them.

The reason why we do not think of measures and actions immediately is, I believe, that when we think of a problem as an action to solve it, it becomes a coping strategy, or we think of what we can do immediately, which makes it difficult to make significant progress.

This is because I believe that instead of deciding on actions for immediate solutions, it is important to first decide on a goal (goal) that may be far away in order to make a big change, and then to make a plan that will allow us to recognize the difference between the current situation and the goal (goal) and make step-by-step progress.

In TOC, in order to set the goal (target), the solution at this stage is called “injection,” and the goal (target) is determined after considering what the “state” of the solved problem is like.

In Part 4, we described the state of many product development projects in the form of a status tree. This is a way of structurally capturing the problem, and in TOC, it is the answer to the question, “What should be changed?

The next step in TOC is “what to change,” which is expressed in the form of a “future tree.

In this series of articles, we will not create the future tree. The reason for this is that while the current situation tree can be considered common among multiple companies, it is difficult to discuss the future tree in a common manner because the circumstances and environment of each company differ greatly.

In this final article, however, I will explain how to create a future tree (in other words, goal setting with a solution to the problem in mind) from the current status tree that has been created.

The status quo tree showed that the problems (UDEs) in the organization are connected in a negative chain of problems starting from the core cloud.

In contrast, the future tree will show how the problems (UDEs) that have been solved are now connected in a positive (positive) chain, starting from the ideal state (injection) that breaks the logic of the core cloud.

We defined the bad symptoms occurring in the organization as UDEs (Undesirable Effect), and we define the opposite of UDEs, i.e., desirable symptoms, as DEs (Desirable Effect).
The future tree then looks like the figure below.

The form is similar to that of the current situation tree. However, the Future Tree represents a chain of good things starting with the Injection.

Injections are created from the cloud.
In this case, one core cloud and two UDEs are the starting point, so we will use the core cloud and the two UDE clouds, three clouds in total, as clues to create the injection.

Injections are not created mechanically. It is a game of ideas.

The following is only an indication of the approach to twist the injection.

Injection will be used to break the logic of the cloud, i.e., to break down the logic. And there are several ways to think about breaking the logic.

1. What do we do to ensure that the need C is met even if we take the action D?
2. How do we act on ‘D’ so that the need ‘B’ can be met?
3. Can we make good use of the resources (people, goods, money, etc.) that D and D’ are competing for and make them compatible?
4. Is there a third action that satisfies the two needs of B and C at the same time?
5. Can the conflict be resolved by nullifying or changing the existence of the assumption?

Injection, again, is not a measure or action, but a “state.
Many people do not understand this at first and think of actions to be taken, but instead, they twist and turn, even if they think it may be a bit far (or difficult to achieve), with the feeling that it would be nice if this were the case.

It is not just thinking of a desire. If you cannot confirm that the logic of the cloud, or the conflict structure, is invalidated by making that state, it is meaningless as an injection.

Injection takes a little time and deep thought.
Injection may not be all that good.

• There are significant obstacles to getting to the state of Injection.
• There are side effects to getting to the state of injection.
• It is obviously impossible to begin with.

In fact, these three thoughts tend to subconsciously enter your mind (assumptions) and stop your ideas. When you come up with injection ideas, write down the obstacles, side effects, and why you think it is impossible together.

There is not necessarily only one injection. In some cases, several injections can be combined to break the logic of a single cloud.

From the core cloud derived from the theme of this article, structuring the problems of a product development organization, thinking about injections (solved state) is truly a challenge so big that it is directly related to management reform.

Injection, in and of itself, should be a management goal.
It should also be able to be used in the formulation of a three-year mid-term management plan.

Reference article：

Thinking process learned from “The Goal 2”

Study best practices and create injections

Injection depends on ideas, but the most effective way is to learn from best practices in product development and actively incorporate what can be incorporated.

We recommend learning from successful examples of Toyota’s Lean product development and Job Theory, which is attracting attention as a new marketing method, to understand the essence of the method and incorporate the essence of the method, rather than just copying the form of the method.

The three key elements of Lean product development are

• Chief Engineer System
• Set-Based Development
• A3 Report

After gaining a deep understanding of the aims of each, the key points of practice, and what each is aiming for in conjunction with the other, we will incorporate them as injections and verify whether they lead to problem solving.

Job Theory is a new marketing method that eliminates the product perspective and considers things 100% from the customer’s perspective. While it is important to learn this method itself, its potential as an injection method emerges when considering the advantages and disadvantages of product planning by development engineers.

If we think of Toyota’s chief engineer system as a superman who manages not only technical development but also marketing, design, manufacturing procurement, service, and sales in a single integrated manner, and at the same time, if we focus on the fact that at Toyota, the project leader of development conducts product planning in the first place, we can break the stereotype that product planning has been the job of a department specializing in planning.

Injection is not a good idea unless you eliminate the assumption that such a thing is impossible or can’t be done.

Let’s create good injections by learning best practices that have been successfully adopted in the world, not only Lean product development methods and job theory.

As we discussed in the first article, we are working with our clients on how to use the TOC (Theory of Constraints) framework to structure development organization problems, discover the root issues, view lean product development methods as best practices, and implement the learning from these best practices as solutions to organizational issues.

Our approach is described in more detail in a separate article, “Organizational Transformation Strategies for Product Development with Lean Development, Job Theory and TOC”

See also.

Related Articles：

What is Toyota-style lean product development?

The Path to Problem Solving

In this five-part series of articles, “Structuring Problems in Product Development Organizations,” the main flow of explanation has been to derive what the root causes of the current problems in the organization are and what chain of events is causing them.

In other words, the core cloud shown in the third article shows the structure of conflict that is the root cause of many problems, and the status quo tree shown in the fourth article is a diagram that identifies what kind of chain of problems is caused by the root cause.

In this final installment, we explained how to derive an injection (a resolved state) from the core cloud.

I also talked about how we can learn from best practices in the world to derive the injection, and how we use Lean product development methodologies in our company.

I would like to conclude this series of articles by briefly explaining the process of creating an action plan to actually solve the problem, following the flow of the TOC.

1. Identifying the Core Crowd (up to Part 3)
2. Structuring the problem with a status tree (Part 4)
3. Twist the Injection (learn best practices)
4. Create a future tree from the injections
5. Modify the future tree to account for the side effects of the injection
6. Set steps (intermediate objectives) to overcome obstacles and achieve injection
7. Create a plan of action (transition tree) to achieve intermediate objectives step by step

In the TOC framework, the first step in identifying “what to change” is steps 1 and 2 above, and “what to change to” is steps 3, 4, and 5.

Although not mentioned in this article, the TOC approach is to do “what to change” and “what to change to” and then move on to “how to change”, and this part is steps 6 and 7.

By proceeding to step 7, a detailed action plan for problem solving is created.

The TOC framework avoids jumping to ad hoc measures to deal with problems, and instead, firmly recognizes the current situation (“What to change?”), sets a goal to be achieved at a high level (“What to change to?”), and then creates a plan that is specific and fully considers obstacles, side effects, and other factors.

Then, through this framework, we overcome the six resistances within the organization, which are listed below.

1. They do not recognize the problem they are trying to address as a problem.
2. Disagree on the direction of the solution.
3. Do not believe the solution will solve the problem.
4. This solution, if implemented, will cause negative impacts.
5. There are obstacles preventing implementation of the proposed solution.
6. Fear of the unknown that will result.

How do you feel? Does your company have this kind of resistance among upper management and departments?
The main aim of the TOC framework is to persuade others to be aware of these issues.

Now, thank you very much for your patience with this five-part series.

As a framework for problem solving, we have utilized the TOC (Theory of Constraints) framework, especially in the phase of “What to change?” We have tried to capture the problems of product development organizations as a structure by using UDE, Cloud, and Status Tree.
This is just an attempt to find common problems in the companies we have seen.

We would be very happy to receive feedback from you, the readers of this article, in terms of common problems.

We have also explained the general flow of our approach in terms of what to change to and how to change it once we have structured the problem.

If you agree with our approach to the problem and would like to work together with us to solve it, we would be happy to cooperate with you.

Please contact us by clicking the “Contact Us” button below.

＜＜Return to Part 4 “Examining Root Causes with Causal Relationships

＜＜＜＜Return to Part 1: “Viewing Organizational Problems as Bad Symptoms

Reference Articles：

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