Have you ever wondered if there is a secret formula behind successful and effective projects?

Yes, there is—and in this article, I will explain it to you.

It is the sequence of:

* Definition

* Creation

* Validation

* Implementation

If you pay attention to it, it is actually simple and logical and should be self-evident.

It is the basis of every project management method I know, from Classic Waterfall to Agile and SAFe. It is the basis of Lean and Continuous Improvement. It is found in quality management methods and systems engineering, and we even use it in leisure activities, mostly implicitly rather than explicitly.

But why do so many projects still go wrong, are late, go over budget and deliver poorly performing products?

My hypothesis is that it is because this simple principle is not followed consistently.

What's so difficult about that?

That's exactly what I asked myself two years ago when I took on the task of making Development's working processes fit for the future.

Why is the organization chronically overloaded, and why do the work results often not meet the requirements and expectations?

My analysis revealed that one of the main causes of the problems was the inconsistent application of the DCVI principle. I also came to realize that changing this is far from easy.

Here is a selection of the statements I am confronted with:

* I do not yet know exactly what we need. I don't have time to think about it now, we have to start developing so that we can make the deadline. (Neglected Definition)

* Planning is a waste of time, I already know what I have to do. This is not my first time doing this! (Neglected Definition)

* Planning and specifying is unnecessary bureaucracy and only encourages micromanagement by managers. (Neglected Definition)

* You can't do it with thought and calculation, we have to build a prototype to experiment with it. (Neglected Creation)

* I don't have time to test the final configuration. (Neglected Validation)

* We no longer have the money to procure and test the final release status. (Neglected Validation)

* We can use special processes in production during the first production period. They shouldn't make such a fuss in the factory, they'll be fine. (Neglected Implementation)

* I can still have the error-free software flashed at the customer's company. The error doesn't occur that often. (Neglected Implementation)

Does any of this sound familiar? Do you feel the same horror and anger as I do when I hear that?

Right, it's all about culture and attitude, and that's what makes it so difficult.

Soon I'll be writing about how to change it. Subscribe so you don't miss out.

Let's now discuss the individual phases:

DCVI

Definition

The definition phase involves precisely defining the project or undertaking.

Regardless of the time period in focus, be it days or weeks for a sprint, months for a product increment or years for a large project, the definition phase must always be taken seriously.

The first step is always to define the goal.

What outcome should be achieved by the end of the activity?

Even in large, long-term projects, it’s crucial to carefully consider what truly should be accomplished with all the money and resources invested.

Precisely distinguish and decide whether “nice and beneficial” goals can realistically be committed to within the available timeframes, resources, and budgets or if “necessary and important” goals are the only feasible options.

All too frequently, I've witnessed projects begin with a specific objective, only to have it change as obstacles appear and something completely different comes about.The actual need is not being met, but the outcome is novel and different from the status quo. A significant amount of money has been invested with little to no return.

The goal can vary in specificity, but it must be clearly defined, documented, and effectively communicated throughout the entire project duration to ensure traceability.

The same applies to the second step, the plan.

There must be a plan!

I always say, “As soon as the plan is finished, you might as well throw it away—because things will turn out differently anyway.”

And that’s true—but it’s not a bad thing.

The team's thorough consideration and comprehension of the relationships, dependencies, and procedures is what matters utmost.

The real value isn’t in the plan itself, but in the understanding that comes from planning. Still, it’s essential to document it properly.

The final step is the definition of boundary conditions and system interfaces.

System interfaces must be considered, and boundary conditions must be clearly defined.

Again, understanding is the key outcome. Everyone needs to know what they need to consider so that their colleagues can work effectively, and the whole system functions as a cohesive whole.

It's vital that everyone is fully involved — even those departments whose main involvement comes later in the project.

Production and after-sales also need to identify and communicate at the start of the project what needs to be planned and specified concerning their areas of responsibility throughout the project.

The attitude of:

“I'll let the engineers develop it first, and when the product is ready, I'll just look at it and reject what I don't like”

is not acceptable.

Creation

In the creative phase, solutions are explored to achieve the goals.

There are established processes that allow for systematic and focused work, but it's also acceptable to explore different approaches and then select the one that offers the best compromise.

Given the high volatility in this phase and the frequent changes in interface requirements based on solution maturity and selection, close collaboration is essential. During this phase, it is highly beneficial for all involved parties to work together, with ideally dedicated resources focused solely on the project at hand.

All solutions must be developed and completed during the definition phase.

However, I often find that developers are left to develop first, and other departments only start thinking about their solutions later.

This approach is wrong!

Everyone has to be creative and work out their solutions at the same time and also be ready at the same time.

At the end of the creative phase, the product is defined, the production processes are designed, the suppliers are known and involved, the after-sales concepts are in place, etc.

Now the creativity is over.

I always say:

It's like school. At the end of the exam, pen, and paper are collected. Then the teacher marks the mistakes and if the performance is poor, the mistakes have to be corrected by the student.

In our case, reality is the teacher.

That leads us to the next phase, validation.

Validation

The validation phase is about finding out if everything works as intended.

This involves testing the product, production, etc.

Changes are only allowed if errors are identified that need to be corrected.

A major challenge in this phase is maintaining the necessary determination and persistence to stay on track.

„I’ve come up with a better solution,” “I found a cheaper supplier,” and similar statements are no longer acceptable.

This is a significant challenge, as it's hard to resist when there’s an opportunity to save money. However, what is often overlooked is the impact of the substantial quality costs that can arise from these late changes, as it becomes impossible to properly validate them at that stage.

Implementation

In this final phase, absolute consistency is the top priority. This is the time of the absolute change stop.

Now the processes are ramped up and accelerated to the planned speed.

In sprints and PI’s, the result is finalized, firmly anchored in the systems, agreed and communicated within the organization.

The achieved result forms the foundation for the next iteration of the project and, at the end of the project, for customer satisfaction and thus the success of the company. Therefore, this phase must be completed with the utmost discipline and carefulness.

At the end of the implementation phase, there must be no way back and no open issues remaining.

Tips for practical implementation

Planning

Use the four phases as headings in all your planning, under which you assign the specific deliverables, to-dos, or tasks.

This makes it clear and transparent in which phase you are currently in, allowing you to align the planning purposefully for each phase.

Make sure that at the end of a phase, it is truly completed, and no significant backlog carries over into the next phase.

List of required participants

Create a detailed checklist of all relevant stakeholders, participants, and departments involved, including specific names and departmental identifiers where possible.

Review and update this list regularly to ensure comprehensive coverage of all business and project aspects, avoid gaps, and ensure completeness.

Checklist

Create a planning template in which you compile the most important, recurring deliverables, to-dos, or tasks.

Review

Conduct a detailed review at the end of each phase, where the results are thoroughly discussed with the team and management.

Decide that the results are as expected and will therefore be finalized and frozen. Communicate clearly that no further input will be considered in any of these areas.

I will further detail each phase in the upcoming articles and dive deeper into implementation and change management. So subscribe if you're interested to make sure you don't miss anything!

If you have any questions, need my help or want my advice on setting up your very own lists, you can contact me in chat.

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