It was one of those moments that stay in memory for a long time.

I was invited to give a keynote speech, and I talked about project management and transformation. During my presentation, I mentioned the DCVI concept — a method that is very close to my heart and on which I have already written an article here.

The session was engaging, with interested participants asking thoughtful questions and participating in stimulating discussions.

During the Q&A, someone from the audience asked a question I had already thought about a lot in advance:

“Isn't DCVI essentially the same as PDCA?”

I felt caught off guard and thought:

“Wow, these people really know their stuff—they've hit the nail on the head.”

But the question also reminded me how often we use methods and concepts without thoroughly discussing their essential characteristics.

Yet it's precisely this deep engagement with the subject matter that brings the clarity needed to truly realize the benefits of these approaches in practical application.

That, in turn, inspired me to write this article.

I want to take a closer look at the difference between DCVI and PDCA – two approaches that both stand for structure and improvement, but nonetheless emphasize different priorities and mental models.

I hope you enjoy reading this and that it helps you apply both approaches in their optimal use cases.

What is PDCA?

In the 1930s, American Walter Andrew Shewhart developed a three-stage process for quality assurance in production processes.

The process consisted of the following phases:

Specification — Production — Inspection

William Edwards Deming, a student of Shewhart's, developed this cycle into the widely known PDCA cycle we recognize today.

It consists of 4 steps:

P — Plan D — Do C — Check A — Act

This sequence is called the Shewhart Cycle or the Deming Circle, named after its inventors.

After World War II, Deming introduced the method in Japan, which led to the Deming Circle significantly influencing the development of quality management methods in Japan for decades.

(Source: Demingkreis – Wikipedia)

Through this path, the Deming Circle found its way into the Toyota Production System, which, with its methods of Kaizen (Continuous Improvement) and Genchi Genbutsu (Problem Solving & Error Prevention), became a foundation for modern quality assurance methods.

I can still remember very well times in my professional life when the Toyota production system was on everyone's lips and really everyone in the industry studied it and tried to apply it in their environment.

In recent years, it's become somewhat quieter. I'd be very interested to know if younger colleagues are familiar with terms like Kaizen and Genchi Genbutsu. Please let me know in the comments.

Due to this history, the Shewhart Cycle or Deming Circle is reflected in the fundamental ISO standards that represent an indispensable benchmark for all modern industrial companies. (e.g., the ISO 9000 series, which defines quality management systems)

The character of continuous improvement was addressed very early by Shewhart, as he emphasized that it's an ever-repeating process, hence represented as a circular flow.

Even today, the Deming Circle remains the most important and widespread foundation for continuous improvement processes and thus also for “Lean Manufacturing,” which can be seen as a generalization and expansion of the Toyota Production System.

Since product development typically aims for improvement or perhaps solving a specific problem, this cycle is fundamentally applicable to product development projects and is consequently reflected in common product development methods (IPMA, PMI, Prince2, Scrum, LeSS, SAFe).

What's crucial is how the individual phases are defined and understood in each specific case. That's why I'll present my interpretation of the four phases in this article.

I'm very eager to exchange thoughts with you about your understanding of this subject in the comments.

What is DCVI?

As you can read in my About page, I've had the opportunity to be involved in many vehicle and powertrain development projects throughout my long career.

During this time, many project management and development methods have emerged, and I've had the chance to apply them and gain experience.

This wasn't just the Deming Circle, but also, for example, the emergence of the Stage-Gate development process, the V-model for developing mechatronic systems, and, in recent years, agile development methods. But also QM methods that are helpful in the development environment, such as the 5 Whys method, the Ishikawa diagram, FMEA, functional safety, and also product testing methods like Design by Experiments, statistical test planning, and much more. I believe I could continue this list for pages.

Looking back at this long history and the experiences gained, I asked myself whether there is an overarching concept that connects all methods and thus forms a foundation for successful product development projects.

The result was the DCVI process, which we now want to look at here.

The 4 steps are:

D — Definition C — Creation V — Validation I — Implementation

And yes, DCVI can also be explained with PDCA!

Just as other approaches can be explained in ways that are helpful for work in product development projects.

However, I've also found that different approaches than those used for continuous improvement are more effective when successfully completing projects or development increments. In some cases, even counterproductive effects can occur.

I'll address these issues in the following, as this is the inherent advantage I see in DCVI as a process method.

DCVI is not a circular process

Did you notice in the title image that PDCA is shown as a loop and DCVI as a linear sequence?

This already marks an important difference in approach.

As the term “continuous” in continuous improvement clearly indicates, it's about a recurring process. Shewhart articulated this explicitly.

This is, of course, also correct and significant in a product environment.

Of course, the product, its competitiveness, and performance must be continuously reviewed.

In addition, markets and company profitability must be continuously reflected upon, and the need for adjustment must be identified.

In fact, this is so essential that, in my opinion, there must be dedicated responsible persons and roles for this.

Be it strategy or product management teams in the classic organization, or business owners and product owners in the agile world.

However, the analysis of what needs to be done and towards what goal the product needs to be developed or further developed should be done before a project is started. It is the trigger for a project!

So, I can assume that the information about what is needed when, and the available resources – meaning time and budget – are already in place.

Unlike continuous improvement, I don't need to worry about the “What” anymore; it's all about “How.”

But that's difficult enough!

To look at it from another perspective.

You could also start a project with the following statement:

“We should do something with the product again, take a look at what makes sense.”

In my experience, this doesn't lead to a good result, and certainly not to an efficient product project.

Too many people have a say, making opinion formation democratic but time-consuming and inefficient.

Here I quote the old saying: “Too many cooks spoil the broth.”

So I can already state an important difference between PDCA and DCVI:

While PDCA aims at continuous improvement and thus has no defined beginning and no predetermined end, DCVI, as it is typical for a project, has a concrete beginning and a concrete end.

DCVI is a stage-gate process

In addition to the defined beginning with a clear objective and the temporally defined end, the end of each phase represents a milestone where a phase is formally completed, the project status is reviewed, and the result is frozen.

This forces us to focus on the respective important activities in each project phase.

And everyone must focus!

I see a major weakness in classic project management in the fact that quality gates are not targeted hard enough.

People let the developers work first. They should lay their egg first, and when they're done, the other functional departments look at the result and form their opinion.

Unfortunately, new requirements often come to the table much too late, which consequently leads to expensive project loops, inefficiencies, duplicate work, and immature and qualitatively deficient products.

A key goal of DCVI is to avoid development loops by having all involved departments work simultaneously on the respective phase and also complete it simultaneously.

Jumping back to the previous phase should only occur in absolute emergencies and should accordingly have severe consequences.

In PDCA, I don't see this consistent separation of the 4 phases; here, fluid transitions are possible, perhaps even desired. Not only should the process be improved, but also the improvement measure itself should be continuously improved during the process.

I don't want that. At the end of the DCVI cycle, the product is finished in exactly the same condition as it was ordered at the beginning of the cycle.

If new goals are identified in the meantime, a new DCVI cycle must be initiated.

This can lead to several DCVI cycles running in parallel.

While the earlier cycle may be in the validation phase, a new cycle is already starting with the definition phase.

It's not envisioned to abort DCVI cycles; once a cycle has started, it's quickly and consistently worked through and completed. This is done knowing that the developed product, after the completion of development, will likely not remain unchanged for long.

This can certainly be viewed controversially and is perhaps a topic for its own article. Write to me in the comments if I should delve deeper into this.

Now let's look at the 4 phases individually:

Plan vs. Define

Unlike the Deming Circle, the beginning of the DCVI process starts with a goal for the project.

Just like with PDCA, it's now about planning the achievement of this target state in detail and discussing and agreeing on it with those involved.

Both concepts provide for the planning of processes and resources.

While PDCA speaks of planning a measure, at the end of the definition phase stands a product concept (architecture) and a comprehensive catalog of requirements.

There is no solution yet!

This is a very important feature of the DCVI!

Before working on finding a solution, it is necessary to decide on an integrated concept with defined system interfaces and detailed requirements for all persons involved and subsystems of the product.

Here DCVI separates much more sharply than PDCA. But this is very useful because experience has shown me that working on the concept and the requirement breakdown is often impermissibly shortened as misunderstood efficiency, which later leads to expensive development loops and delays.

DCVI draws a clear line here.

First, the complete plan with the aspects of deadlines, resources, concept, and requirements is developed, reviewed, and jointly decided. Only then does the solution-finding begin.

To say it very clearly again: These defined plans are binding from now on! From now on, everyone must work within the framework of the goals agreed with them and promised by them.

Do vs. Creation

In the "Do" phase of the PDCA, the improvement measures are tested in a small and risk-minimized environment.

I might also describe it as "Learning by Doing."

Difficulties that arise during the implementation of the measure are identified and solved until the process runs smoothly.

Thus, the "Do" represents a mixture of elements of "Creation" and "Validation."

In the Creation Phase of the DCVI, the aim is to crystallize a solution that represents the best compromise from a large number of possible solution alternatives.

Every technical solution is always a compromise between performance, cost, and quality.

To find these compromises, the detailed specifications from the definition phase are necessary. They represent the optimization space in which to work.

If you will, compared to PDCA, only at the end of the Creation phase are the measures defined in detail, but then definitively.

The boundaries must be sharply drawn.

For the creative phase to run efficiently and quickly, the important specifications and processes must be correct at the end of the definition phase.

Trying out specifications should not be the goal, although it cannot be completely avoided in reality.

I like to compare the end of the creative phase to a test in school.

Now the pen is put aside and the test is submitted. If the teacher finds no errors, that's it. If not, then the tasks with incorrect results must be corrected.

Check vs. Validation

In the Check phase of PDCA, it's about finding out whether the desired magnitude of improvement has really occurred.

If deviations are detected, the causes must be found and eliminated.

Validation in DCVI pursues the same goal. The product is produced in the new target state and must prove that the performance characteristics, costs, and quality requirements specified in the definition phase are statistically reliably achieved in reality.

If significant deviations are detected, the causes must also be found and eliminated here.

I strongly borrow from the V-model of system development. It's formulated more clearly there than in the Deming Circle.

For product projects, validation doesn't take place in real customer use, but in a special test environment. If customer deployments are part of the validation, then the customers are contractually engaged as "validation service providers" and appropriately instructed to carry out the test properly.

Act vs. Implementation

In PDCA, the result of the Check phase leads to the decision whether the measure is rolled out to the entire system or, if the check result is negative, a new optimization loop is started and the previous measure is simply not rolled out.

In DCVI, this second option doesn't exist.

At the end of the validation phase, there is always a product that fulfills the goal set at the beginning of the cycle. The product itself is already finished.

The implementation phase is now about ramping up the production processes and sales of the product to the target speed.

I hope it's understandable why I see DCVI as a clearer control model for product projects and why PDCA offers too much room for misinterpretations that can have fatal effects on the success of product projects.

I'm really interested in your opinion. Please write your thoughts in the comments, or let's exchange ideas on this in the chat.

I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.

If you found this helpful, don’t forget to share it with others who might enjoy it too!

Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe