The blueprint for Product Development Process Reform is a PDCA cycle using TOC’s Future Tree

Why is it that we have tried implementing Lean development methods and other techniques, but they don’t actually improve our problems?

In recommending Lean product development methodologies to our clients, we often hear, “We actually tried it, but it didn’t work.” We have heard some of our clients say, “We actually tried it, but it didn’t work out. When we asked them about the details, we found that in many cases, they were trying to introduce the method in a tokenistic way, without a clear idea of what they wanted to change and how, and the main reason was that the overall picture of the reform was not well designed.

Organizational reform is all about designing the overall picture of reform, and using the blueprint to realize it through repeated hypotheses and testing!!

Development organizations have endless problems, such as dealing with the regularity of development schedule delays, eliminating rework, and increasing employee motivation. This session will discuss the causes and solutions for organizations that have tried grasping at straws to introduce Lean, Agile, CCPM, etc., but have seen no improvement even one year after the introduction of these methods.

Why is it that Lean development and other methods do not produce results?

• The A3 reporting system was introduced throughout the organization, but nothing has changed after three years.
• Tried the set-based development method, but it does not shorten the development period nor does it lead to a reduction in quality problems.
• We introduced CCPM, but it is too difficult and the field is confused.

We sometimes hear voices like these.

Why did you introduce the method? I ask.

• I want to prevent the same mistakes from being repeated.
• We want to preserve the know-how of veterans in our company.
• To shorten the development schedule.
• To stabilize quality problems.

We want to solve problems that are common in development organizations, such as

So, why do you think these objectives can be achieved by implementing the methodology? I ask.

• Because I was convinced by the explanation of the method.
• Because I read about it in a book and thought I could do it.
• Because other companies have succeeded.

These are the answers we usually get.

Why is it that the introduction of the method does not produce results?

Let me conclude

This is because we have not created a blueprint for achieving results.

A blueprint, in other words, is a roadmap from the current situation to the achievement of some result.

Without a roadmap, relying only on the case study itself or your own intuition will not work.

Even if you are convinced by the theory of the method, or you think you understand it after reading a book, if you do not create a solid blueprint in your own way, the wonderful theory will end up as mentalism.

Let’s look at the pitfalls in more detail.

Pitfalls when you want to raise the level of knowledge in your organization with an A3 report

Many books have been written about Toyota’s A3 report.

We also encourage the creation of an A3 reporting culture and believe that an A3 reporting culture provides various benefits and is a great weapon for development innovation.

However, simply changing conventional reports to A3 reports, forcing organizational members to write A3 reports, and controlling the amount (number) of A3 reports written will probably not produce any results.

This is because they do not understand the essential meaning of A3 reports as discussed in the Lean product development methodology.

The essential meaning of the A3 report culture can only function effectively if there is a strong demand for the distribution of information, both from the side that wants to communicate information (which can be paraphrased as knowledge) and from the side that explores and utilizes the information.

I want the information I have to be widely communicated and utilized.

We want to utilize internal information to develop high quality products.

After creating such motivation within the organization, it is necessary to design a system from the viewpoint of how to create a system for efficient information distribution.

What is often discussed is why the A3 format is good?

What makes it different from the current report?

The important thing is, however, is the system currently in place to ensure that important internal information (knowledge) is effectively utilized?

By starting from the question, “What is the best way to get the best results?”, Toyota seems to have a successful example (A3 report).

Is there anything we can learn from it or incorporate?

And the idea is that the objective is only the effective use of information within the company.

Reference article： “A Case Study of Organizational Change to Improve Report Writing”

Pitfalls of Implementing CCPM (Critical Chain Project Management)

I believe that many people have an eye-opening experience when they hear the explanation of CCPM.

They think that just by incorporating this kind of thinking into schedule management, schedule delays can be greatly reduced.

There are many successful examples of CCPM, and I do not mean to deny the method itself, but there are many challenges to putting it into practice.

The question is, can we really reduce uncertainty and risk in the schedule by having some people in the organization learn CCPM, take away the buffer from each member’s declared schedule using the CCPM method, and shift to centralized management of the buffer?

What kind of uncertainty does each member have about the task processing?

Is the buffer really the true cause of the current schedule delays?

Will the project leader have a firm grasp of the unique problems and issues faced by each member of the team?

Can all members understand the CCPM concept and cooperate with the leader?

Are the obstacles and risks in the implementation of the program understood, and are the methods for dealing with these obstacles and risks determined?

However, the question is whether the leader of the project has sufficient knowledge and experience in general project management before the CCPM methodology.

Who can determine that?

In reality, there are a variety of issues, and I think we need a blueprint regarding system transition, such as what frequency of checkpoints, trial and error, or hypothesis testing will be used when trying CCPM from the current approach.

Reference article： “Project Management Learned from the Critical Chain”

Understand that organizational and process reform is about making change

Improvement or reform is about bringing about change within an organization.

Of course, there are reforms that produce big results with small changes, but in most cases, it is about building on small changes and gradually improving results while winning big results over time.

The idea of making changes is very important.

Most of the problems I have seen in product development organizations have been problems that have grown little by little over a long period of time.

In many cases, the organization is not trying to create a problem, but rather, while trying to do something good and creating something good, it has created a little bit of bad change that is not so obvious as a side effect or the price to pay for achieving the good, so it has taken time to notice the problem.

In other words, you have to understand that it took a long time for the organizational problem to become apparent, because it took a long time with little by little small changes to create the problem, and conversely, it often takes a good deal of time to solve this problem as well.

Organizational problems, in other words, can be thought of as the culture of the organization, the habits and quirks of the organization.

Even human habits are not so easily cured, are they?

Therefore, if you think of organizational and process reforms as taking time to make changes, like curing organizational habits, it will be easier to see the roadmap for reform.

Deciphering Change with Causal Logic

The key to deciphering change is causal logic.

If you do xxx, you get xxx.

There is a cause, which leads to a result.

Change is caused by some cause (or trigger).

And the change that occurs is the cause of the next change.

Everything that happens in the world is connected by cause-and-effect relationships.

For example…

Many of the organization’s members will write quality reports
↓↓
The report will be read by many people
↓↓
Internal knowledge information is utilized within the organization

In other words, the idea is to think of organizational reform in such a way that positive things will happen in a chain reaction from a single change.

Design a TOC (Theory of Constraints) future tree of how change will occur

We recommend using the TOC (Theory of Constraints) thinking process when implementing organizational and process reforms using Lean product development methods, or any method, not just Lean development.

When analyzing the current situation, we create a status tree. （For the TOC Thinking Process, “What is TOC – How to Apply it to Product Development Organizations” Reference）

We then recommend using the Future Tree as a blueprint for how to make changes, i.e., reform.

What is the Future Tree in TOC (Theory of Constraints)?

The future tree in TOC is a diagram that shows the chain of changes that will occur in an organization when some action is taken or measures are deployed in problem solving or organizational reform, using cause-and-effect logic to show the chain of events.

If we can confirm that the objectives we want to achieve can be achieved in this future tree, we can hypothesize that the reform will be successful through the measures we are about to take.

In TOC, the measures to be implemented are called “injections.

What changes are triggered by the injection are, in other words, the blueprint for problem solving and organizational reform.

The figure below shows the shape of the future tree.

If the changes that occur through the causal logic from the injection include desirable results (DE), and if one of those desirable results is the outcome that the organization is seeking, then it is a correct blueprint for reform.

The future tree is a diagram in which the source of the arrow is the cause, leading to the result at the end of the arrow, causing a chain of events.

The causal relationship of each arrow does not show the same strength.

Some causal relationships are strong, while others are weak.

Also, the time from cause to effect is not the same for all.

Some results are immediate, while others take a long time.

The future tree is a blueprint for reform, but it does not take time relationships into account.

It is only a representation of the overall flow, and a detailed plan that takes into account the time axis should be made based on this future tree.

Checking the progress of reforms with the future tree and PDCA cycle

The important thing in problem solving and organizational reform is not to lose sight of the big picture in the process of implementation.

That is why blueprints are so important.

The so-called PDCA cycle, the cause-and-effect logic expressed in the future tree is only a hypothesis.

It is necessary to periodically check whether changes are occurring as hypothesized.

It is important to turn the PDCA cycle as small and as fast as possible. This is because that is the lean way of thinking. （Reference article： “What is the difference between Lean, Agile, and Lean Startup?”

While checking whether each arrow in the future tree is causing change as planned, if no change is occurring, we will assume that there was an error in design and correct the method.

Discover why deploying a methodology does not produce results

The starting point for this article was that sometimes the adoption of a method that seems necessary for organizational change, such as the Lean product development methodology, does not actually produce results.

Now, as you can probably tell by this point, the reason for the lack of results must be on the future tree.

As a result of adopting the methodology, there are areas where the expected changes are not occurring, and the changes are not leading up to the important results.

So, if you are worried about the lack of results, you can go back to the blueprint and examine which changes are not happening so that you can correct the way you are proceeding.

Let’s consider the aforementioned example of improving reporting (e.g., creating an A3 reporting culture).

Hypothesis of Change

Many of the organization’s members will write high quality reports.
↓.
The report will be read by many people.
↓↓
Internal knowledge information is utilized within the organization.

If the quality of the reports was to be improved, knowledge assets were to be better utilized, development waste was to be eliminated, and the schedule was to be shortened, but if the results do not show up over time, it means that some of the above changes may have been flawed.

You may have been thinking about changing to a higher quality report in the first place, but the quality may not have been high enough to make the next change.

Or perhaps the quality of the report did indeed improve, but the number of people who wanted to read it did not increase.

The quality of the report may have improved, but the number of people who wanted to read the report did not increase.

Many organizational problems have deep roots.

Looking only at the theory of the method, it may seem easy to reform, but I believe that in many cases, it will take several attempts.

While increasing the precision of the design of reform is one method, I believe that a shortcut to reform is to think about achieving the goal as soon as possible through fast-turn PDCA while rotating hypothesis testing in small steps.

To draw a workable blueprint

Drawing a viable reform blueprint to achieve lofty goals requires a certain amount of knowledge and experience.

Learning methods from books is not enough to draw the right blueprint for reform.

We support the reform of product development organizations by using lean product development as one of our weapons, and in fact, our approach to reform is characterized by a “lean” way of thinking.

We hope that you will take advantage of our unique reform process that combines TOC (Theory of Constraints) and Lean product development methodologies.

We also offer “trial seminars” on our support methods to help you understand our organizational and process reforms.

Please click below for details.