The moment an employee is assigned responsibility for a project, they know: Something extraordinary begins—from tomorrow onward, their world will never be the same!

Does the Project Manager Know Their Responsibilities and Tasks?

How does a project manager know what's expected of them?

What determines their success or failure?

And what decides whether they'll be celebrated as a hero or condemned as a failure in the end?

Well, finding answers to these questions isn't simple. In some organizations, project managers have clear guidelines and best practices to follow, while in others, expectations remain frustratingly vague.

Ideally, a Project Management Office exists to define project roles, assign responsibilities, establish rules, and outline procedures.

When top management elevates this framework to a company standard and aligns their evaluation criteria accordingly, project managers can inform themselves and act appropriately.

This brings us to a crucial point:

The responsibilities and tasks of project managers must be specifically defined in every company, as well as the responsibilities and tasks of other project members.

While agile project management methodologies offer clearly defined roles with corresponding tasks and responsibilities, traditional project management approaches (IPMA, PMI, etc.) remain much more open to interpretation.

The framework conditions provided by the Project Management Office aren't always optimal for efficient project management and successful projects. All too often, these guidelines contain gaps or leave too much room for interpretation.

The greatest challenge for project managers arises when management has expectations they're unaware of or objectively cannot fulfill. The situation becomes particularly critical when the project performs poorly and fails to meet its objectives. In such cases, the blame game begins, and all eyes turn critically toward the project manager.

However, assigning responsibilities and tasks properly isn't just about the project manager's fate. It's about the project's destiny and perhaps even the company's future.

When expectations placed on project managers exceed what they can realistically deliver, yet the project's success depends on meeting those expectations, failure becomes inevitable.

I hope this introduction clarifies why properly defining a project manager's responsibilities and tasks is absolutely critical.

Drawing from my experience and observations, I'd like to present some suggestions as to which responsibilities a project manager should take on under all circumstances.

I hope my arguments convince you. You can assess the approaches in your environment that create favorable conditions for the success of projects — and thus of project managers.

These Responsibilities Should Be Assumed by Project Managers:

Responsibility for Project Objectives

At the top of my list comes responsibility for project objectives.

They are, after all, the very reason the project exists.

If objectives aren't met, the project fails to deliver the impact for which it was initiated. Against this background, it's logical that project managers must be responsible for achieving project objectives.

But beware!

Project managers don't have the task of achieving project objectives! That must be done collectively by all project participants.

What exactly does responsibility for project objectives entail?

Let's take a look at the primary project objectives that play a role in every project:

* Performance

* Cost

* Time

This is the magical triangle of project management. The term itself indicates that it represents a compromise.

Time, money, and performance are interdependent. Greater performance typically requires more resources and time, and vice versa. You can also buy time with money by deploying more resources, which naturally must be paid for.

The project manager's responsibility is to ensure that the compromise, established as the project objective, represents a realistic compromise.

To accomplish this, project managers must:

* Be convinced that all three objectives can be achieved simultaneously.

* Have a concept of who can realistically contribute what toward achieving these objectives.

If the assigned goals are not all achievable at the same time, then it becomes the project manager's task to negotiate a new, but then feasible, compromise with the relevant stakeholders and bring it to a decision.

Sounds logical, right?

However, it's anything but trivial and places high demands on project managers.

They need extensive experience to assess what's realistic and what isn't. While they'll gather information from their team, ultimately they remain responsible for judging whom to believe and where more might be possible than team members trust themselves to deliver or are willing to commit to. Similarly, they must recognize when the team might be taking on too much and making unrealistic commitments.

It requires extraordinary courage to tell stakeholders (who are often top managers) that not all wishes can be fulfilled.

Company culture plays a crucial role here. In a trust-based culture, project managers find it easier to propose realistic compromises to stakeholders. In cultures dominated by fear and power, one should consider whether being a project manager in such an organization is even desirable.

Let's take a look at the secondary goals. In addition to the three main objectives present in every project, there are also additional, often project-specific objectives.

Project managers bear responsibility for ensuring all these objectives are clearly defined and communicated to all project participants, from stakeholders to team members.

Responsibility for project objectives consequently includes monitoring the achievement of these objectives throughout the project. For this purpose, project managers use metrics that help them recognize when problems are emerging. When this occurs, it becomes their task to initiate organizational measures to remedy the disruption or solve the problem.

Since primary project objectives have three dimensions, KPIs must naturally monitor all three dimensions. This requires metrics that show the maturity level of performance development, metrics that show budget expenditure, and metrics that measure project progress over time.

Responsibility for the Project Plan

It is the project manager's responsibility to assign the right tasks to all project participants at the right time.

For this, they must manage the project plan.

What does managing the project plan mean?

First, they must develop a complete plan detailing which activities are necessary, which resources are required, and what dependencies exist between activities.

On this basis, they then direct the respective project members.

The project manager is the one person in the project who precisely understands what must happen for project objectives to be achieved.

In reality, the initial plan won't work exactly as envisioned. That's why I say they must manage the plan. This means they must direct the necessary activities to make the plan work. When they recognize that deviations from the plan are necessary or beneficial, they must adapt the plan.

I interpret responsibility in this aspect extremely strictly. The project manager alone decides when and how a plan is adjusted. For this purpose, they naturally gather information and decision recommendations, just as any good leader does when decisions need to be made.

Too often, I experience project team members urging the project manager to change the plan because it doesn't suit them. They want more time, they demand additional prerequisites, and so on. This is toxic.

I want project managers to bear sole responsibility. They dictate how things proceed and bear responsibility for ensuring it works.

Every project team member contributes to making the plan function.

This creates potential for conflict. Therefore, another role is needed to mediate between the project manager and the project team—the Project Management Master role. (Feel free to come up with your own name for it. In the agile context, the Scrum Master is positioned quite similarly.)

I'll describe the responsibilities and tasks of the Project Management Master's in a separate article, so subscribe to the newsletter to avoid missing it.

Responsibility for Risk Management

I consider it self-evident that project managers are also responsible for risk management. This is, after all, a prerequisite for increasing the probability of achieving project objectives.

Since project managers are responsible for achieving project objectives, they should also be the ones who best understand what could go wrong. Having recognized potential risks, they must ensure measures are taken to minimize these risks and make their occurrence as unlikely as possible.

For this purpose, they use classic risk management methods as extensively described in project management frameworks.

To briefly summarize, here are the tasks they must personally complete in risk management:

* Identify project risks.

* Evaluate project risks regarding the severity of impact and the probability of occurrence.

* Develop risk mitigation measures or backup strategies for critical risks.

* Incorporate risk mitigation measures into the project plan.

* Verify implementation of measures.

* Immediately activate backup plans or initiate recovery activities if risks materialize.

Stakeholder Management

The final responsibility involves continuously informing project stakeholders about the project's status and ensuring coherence between stakeholder expectations and anticipated project outcomes.

This can have several dimensions:

* If it becomes necessary or beneficial to change or adjust project objectives, project managers must agree on this with relevant project stakeholders or secure necessary approvals.

* Regarding customers, they must ensure that solutions developed within the project address the problems customers need solved.

* If multiple interdependent projects run simultaneously, they must remain in contact with the project managers of other projects or with program/portfolio managers to ensure these interdependencies don't cause problems. They must consider these dependencies in their risk management.

What Are Project Managers Not Responsible For?

Oh my, that's a long list! For this reason, I won't enumerate everything here.

Subscribe to my newsletter to receive articles about the responsibilities and tasks of other project participants. The matters for which I see other roles bearing responsibility automatically fall outside the project manager's responsibility.

To put it briefly, the project manager's responsibility consists of planning and controlling, while the team and other project roles are responsible for execution and implementation. If problems arise, the project manager must escalate them, but others must take action. If they don't do so, this should not be held against the project manager.

Too often, I have experienced the project manager being held responsible for this. Not infrequently, this comes from those whose responsibility it actually is.

It's important to note that in English, 'control' in project management is often misunderstood when translated to German as 'Kontrolle' (which implies checking or monitoring). What I actually mean is 'steuern' - the active process of steering, guiding, or directing the project toward its objectives.

So, please be attentive and analyze emerging problems carefully. If you are a manager or stakeholder, listen to the project manager about where you need to provide support and don't hold them responsible when the team or organization doesn't deliver what the project manager requested.

Does the Project Manager Work Alone or Have Staff to Help Fulfill Their Responsibilities?

This is a fascinating question that I know has very controversial answers.

My opinion on this topic is absolutely not undisputed, I'm aware of that. Nevertheless, I want to present it here.

I believe project management is a full-time job.

A project is properly scoped when a highly qualified and experienced person can fulfill the aforementioned responsibilities alone and remains fully occupied doing so.

I'm not a fan of scenarios where project managers have a flock of helpers exclusively assisting them without bearing their own personal responsibility.

If project managers aren't fully occupied with the tasks and responsibilities described here, then the project is too small and consequently suffers from inadequate focus.

If project managers can't manage alone, then:

* The project is too large and should be intelligently divided into multiple projects, possibly bundled through a project program.

* They're insufficiently qualified and the wrong person for the job.

* They're doing things that aren't their responsibility, and measures must be taken to ensure the right roles complete their tasks and can fulfill their responsibilities.

Conclusion

Just as primary project objectives have three dimensions, project manager responsibilities also have three dimensions:

* Securing project objectives

* Managing the workload

* Reducing risks and solving problems

This keeps project managers fully occupied, leaving no time or attention for other matters. Hence, these have to be dealt with by other project participants.

I could probably write an entire book about this article's subject. However, I don't plan to do that at the moment.

Let's discuss in the comments or chat about which additional aspects or deep dives particularly interest you and what questions you have. Then we can either exchange ideas directly, or I can write further articles on these topics.

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!

As a teenager, I tinkered with my motorcycle, always trying to improve it. Today, we call this tuning or customizing.

It was my childhood dream to develop vehicles—a dream I almost didn't dare to have. In my twenties, it finally happened. I landed my first job as a design engineer in vehicle development, and shortly afterward, a new vehicle development project began.

Can you imagine how proud and excited I was?

Since then, I've had the privilege of contributing to many vehicle development projects, with increasingly greater responsibilities. I've tried other jobs, but quickly returned to development work.

Product development is addictive, mainly due to the emotions connected with this work:

* The excitement when a new project launches.

* The stress and fear when you think you won't make it, and everything's going wrong.

* The nervousness when driving a prototype vehicle, hoping you'll make it home without breakdowns.

* The pride when the vehicle drives onto the stage at the world's largest trade show for its global debut.

* The joy, when you encounter your vehicle on the highway.

Many of the negative emotions you'd rather avoid can come from the misapplication of waterfall project management methods.

Like any methodology, waterfall project management has advantages and disadvantages. You can mitigate or avoid the disadvantages if you're aware of the pitfalls and adjust your approach accordingly.

I'll discuss several of these pitfalls below and hope this helps you to avoid them, making your projects run more smoothly, whether you're developing vehicles or other exciting products.

Lack of Discipline in Early Quality Gates

A characteristic of waterfall projects is a structured project plan with milestones and quality gates. This plan can span several years from project start to completion for large projects.

The project plan details individual activities, documents dependencies between work steps, and defines the required deliverables for each milestone or quality gate.

Here's where the discipline challenge arises:

I frequently observe that delivering results for early milestones and quality gates isn't taken seriously enough.

"We still have years until the product needs to be finished. We'll somehow make up for this small delay."

If the project is comfortably planned with sufficient time reserves, this might even be true.

However, I've never encountered a project with this luxury. The project schedules I know are always best-case plans from the start, with no provisions for things going wrong.

In this situation, carelessness is extremely dangerous. It leads to cumulative project delays in later phases, creating an unmanageable situation.

The consequences are poor product quality, excessive costs, and late product delivery, which affect the company's profitability and always cause unpleasant feedback.

Solution:

* Treat every milestone and quality gate as if it were the end of the project.

* Immediately initiate special measures when delays appear imminent to recover quickly.

* Prioritize the project from day one. No project should be treated as a second priority just because the delivery date is far away.

Continuous Replanning Distracts from Implementation

This second pitfall is closely related to the first one.

When project delays occur, it's tempting to completely replan the project to supposedly ensure it has a functional plan again.

This is not good!

I strongly advise against this for these reasons:

* Replanning itself consumes resources and time needed for executing the plan. The effort required for replanning only enlarges the problem that has already occurred.

* When it becomes known that replanning is underway, people might halt work until the new plan is ready. Project participants might also take more time before it's clear what the new plan will be.

* Once a project plan is published, many smaller, sometimes personal plans develop based on it. These aren't published because they don't require coordination with others. As long as these plans serve the overarching project plan, they don't necessarily need to be published. However, replanning the overarching project destroys these smaller plans. This means not only does the project management have to do planning work, but many other project members have additional planning work too. The problem typically grows over time because it's impossible to maintain this evolved understanding of a functioning approach congruently.

Instead of creating a new plan, do everything possible to quickly return to the original plan.

Solution:

* Avoid replanning the project like the plague.

* Do everything possible to return to the project plan as originally designed at the start of the project.

* React immediately to threatened project delays and take measures to avoid or quickly recover from them.

* Plan realistically and avoid "tension factors".

Project Goals Changed During the Project

Repeatedly questioning and revising the agreed-upon project goals is a bad practice that destroys project plans.

This is where project stakeholders must step up!

I frequently hear the excuse that:

* the world is so volatile,

* that competitors make surprising moves,

* and that customer priorities suddenly shift.

Trust me—in 90% of cases, it's not the world's fault. It's poor project preparation, characterized by unprofessional market analysis, incompetent product management, and flawed product strategy.

Once this problem has occurred, it's usually irreparable.

In classic project management, this should lead to terminating and restarting the project, which naturally causes corresponding delays in product completion.

The only solution is to work very professionally from the beginning and invest the necessary effort and resources at the right time, meaning very early. The overall efficiency of the enterprise will benefit.

Solution:

* Verify the quality of the project goals immediately at project initiation.

* Agree with stakeholders that goals are final and that significant goal changes will lead to a project restart.

The Project Management Tool is Misused as a Communication Tool

With this pitfall, you might shake your head and think, "This doesn't happen; it doesn't occur in our environment!"

That might be true—perhaps this pitfall truly doesn't exist in your environment. But perhaps you should take a closer look just to be sure.

A characteristic of waterfall project management is planning and documenting all activities in a comprehensive project plan, complete with dependencies.

When I need an activity from another employee, department, etc., I ensure this activity is included in the project plan. To be safe, I add a dependency to my activity, making it clear that I need this!

Properly, there must still be an agreement between the two parties involved. I must ensure the person responsible for the predecessor task understands exactly what I need and why. Are they able to deliver what I require?

This is the communication that must absolutely occur.

The pitfall consists of omitting precisely this communication.

"I've made sure everything is in the project plan; now the others should ensure it happens. From now on, I'm entitled to it."

I don't even want to suggest the malicious thought that the absence of the predecessor's result also provides a good excuse for not delivering myself.

This pitfall doesn't exist in agile project management because the method forces communication. In classic project management, the project team must be very attentive and experienced to avoid this trap.

Solution:

* Organize planning workshops where the project flow is discussed among all participants.

* Ensure planned activities are checked for feasibility by the responsible project members.

* Make each project member responsible for procedurally monitoring the prerequisites for their own work packages and taking action when deviations occur.

Excessive Focus on Hardware

People love to have something tangible to hold and try out.

When developing hardware products, this tempts us to order prototype parts and assemble product prototypes as early as possible.

The problem with this approach is that mistakes here are particularly time-consuming and expensive.

It's pleasant not to think for too long, because thinking is exhausting. Just putting things together—if I'm lucky, it will work on the first attempt, and I'm done. If it doesn't work, then I have a problem I can analyze and solve.

Both approaches avoid the cumbersome process of thinking through all possible risk scenarios, finding risk mitigation options, and preventing potential risks.

It feels pedantic and tiresome. It takes time before you can touch and experience something. Therefore, it requires much discipline and consistency to complete work on the virtual product before hardware procurement begins.

The reward is that by the end of the project time, fewer unsolved problems remain!

Solving problems in hardware development requires lengthy parts procurement and prototype modifications, time that's typically unavailable. This causes stress, project loops, and replanning—all consequences that shouldn't occur.

Not infrequently, the delivery date arrives before we've even reached the peak of error elimination.

Solution:

* Conduct thorough and in-depth product reviews before beginning validation involving hardware.

* Have the team jointly assess whether the development's maturity level is sufficient for hardware procurement.

* Implement careful risk management in the project, methodically identifying all risks, finding measures, and evaluating their effectiveness.

Software Delivered Too Late and Immature

This pitfall occurs with mechatronic products.

To test the mechanical part of the product, prototypes must be built and checked for durability. This requires months, sometimes years.

Software development doesn't have these restrictions. Software doesn't wear out, so validation happens much faster.

This misleads software developers into the false assumption that they have plenty of time until the product needs to be completed.

However, with a mechatronic product, the mechanical hardware cannot be validated without functioning software.

Consequently, the software must function much earlier than might be necessary in pure software development.

The beginning of hardware validation is an important milestone for software development. If this isn't met, it has serious consequences for the entire project.

To complicate matters, the software doesn't need to be completely error-free at this point. It just needs to enable the product's operation.

But which errors can no longer occur and which are still acceptable at this time? This must be evaluated very precisely to focus software development on the important features and functions in a timely manner.

Solution:

* Ensure the software development plan and mechanical development plan are synchronized.

* Define testing-relevant software features immediately at the project's start.

* Place special focus on meeting deadlines for relevant features in software development.

* Ensure these relevant software features are validated on test benches before product prototypes are assembled.

These are the pitfalls I've encountered most frequently during my professional career. There are many more, but I want to prioritize, too.

Write in the comments which pitfalls cause the biggest problems in your environment and how you roll them out of the way.

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!

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!

No manufacturer can succeed alone; suppliers are vital to every successful OEM business, directly contributing to the final product's success.

In the last article, I discussed the various types of products and their development environments. In doing so, I described the series product as being developed even before its eventual customers are identified.

If you’re a supplier or work for one, you might think:

'That doesn’t apply to us—we develop our series products together with the customer!'

But who’s right?

In this article, I’ll dive into this specific question and explore the collaboration between OEM developers and supplier developers.

The goal?

To foster mutual understanding and improve cooperation for better outcomes.

What does the development process of a final product look like?

I will start with a brief overview of the phases in end-product development to provide context for the explanations that follow.

Development follows the principle:

Specify from large to small — Validate from small to large

- a principle that is anchored in the V-model of system development.

It all starts with the customer-intended end product, which is usually understood as a more or less complex holistic system.

The OEM's developers describe and specify the end product very precisely, ensuring that all requirements are clearly defined.

A complex and time-consuming process begins:

Performance requirements and specifications are broken down along a new or existing product architecture into subsystems, assemblies, modules, components, and individual parts.

The objective is to ensure that all elements work together seamlessly to achieve the intended overall system characteristics.

There exists one major challenge in this process:

The performance of individual parts, components, and modules directly affects the allocation of specifications within the system. It would not be practical to impose technically unfeasible requirements.

This decomposition of requirements follows an iterative approach along the left leg of the V-model.

Subsequently, validation takes place step by step along the right leg:

First, each part must demonstrate that it meets its assigned specification.

Next, the interactions between individual elements are tested at each level, gradually progressing from single parts to the entire product.

Finally, at the top right-hand end of the V model, the entire system must demonstrate the defined product characteristics.

The development is only considered complete once all requirements have been fulfilled.

What does the OEM need from the supplier?

In the process of breaking down requirements, it is crucial for the OEM engineer to realistically assess performance and properties at each level.

At various system levels, suppliers now come into play.

As part of the specification process, the OEM must decide which components to source from partners—whether for economic, logistical, or expertise-related reasons.

At this stage, the supplier becomes an active participant in the project.

Even though the OEM is the supplier’s direct customer, the focus is ultimately on the end customer who will purchase the final product. In reality, the end customer doesn’t care who contributes which parts—what matters is the overall result.

It is crucial that all parties involved understand this relationship.

Only if the end customer is satisfied, places an order, and pays for the product can business success be ensured for everyone.

While the supplier provides a defined scope of supply, they are also an integral part of the project team during the development phase.

So the engineer at the OEM needs the same things from the engineer at the supplier as he needs from his colleagues at the OEM:

* Solutions for problems

* Information on the performance and properties of subsystems, assemblies, modules, components, and parts

* Feasibility and risk assessments for new developments

* Costs/prices

* Performance evidence for supply scopes

* Calculation models, prototypes, and production samples

You might be wondering why I didn't list any information about time requirements.

The reason is quite simple: Time cannot be integrated.

If the development of one component or module takes longer, this delay cannot be compensated for by a shorter development time of another component.

Components that are not available within the given time frame are automatically ruled out as viable solutions.

That's why development frontloading at the supplier is a crucial prerequisite for the OEM to bring technologically sophisticated products to market.

On the right-hand side of the V-model, the Original Equipment Manufacturer (OEM) engineer requires proof of performance.

Ideally, every engineer involved in the project should provide this verification for their respective scope of work. This includes engineers at supplier companies, who should demonstrate the performance of their supplied components or systems.

How can a supplier prepare their product?

At this point, I'd like to briefly discuss four key project categories:

* Integration projects

* Platform projects

* Component projects

* Technology projects

Integration Projects

The development process for an end-product following the V-model, as previously described, exemplifies an integration project.

In this context, the primary focus lies on harmonizing interfaces within the overall system.

This critical task is typically the responsibility of the Original Equipment Manufacturer (OEM).

Key aspects of integration projects include:

* Ensuring seamless communication between various subsystems

* Optimizing the performance of the entire system

* Managing complex interdependencies among components

* Coordinating efforts across multiple teams and suppliers

By effectively managing these integration challenges, OEMs can create cohesive, high-performance products that meet or exceed customer expectations while maintaining efficiency in the development process.

Supplier engineers must be prepared to optimize components, manage interfaces, proactively solve problems, and maintain seamless communication with OEMs

Technology Development and Pre-Development Projects

The development of new, innovative, and unfamiliar technologies must occur in advance of integration projects.

This proactive approach is crucial because it generates essential information regarding performance characteristics and properties, which serves as a prerequisite for successful integration.

Suppliers should take the initiative to:

* Independently develop technologies relevant to their scope of delivery

* Ensure these technologies are available at the project's outset

* Conduct technology and pre-development projects to achieve these goals

This strategy offers several benefits:

* Reduces risk in integration projects

* Accelerates the overall development process

* Enhances the supplier's competitive edge

* Enables more accurate cost and timeline estimates

By investing in technology and pre-development projects, suppliers position themselves as valuable partners to Original Equipment Manufacturers (OEMs), ready to contribute cutting-edge solutions to integration projects from day one.

Platform and Component Projects

Transforming pre-developed technologies into viable supply packages typically requires suppliers to undertake platform or component projects.

These projects bridge the gap between innovative concepts and practical, marketable solutions.

It's often not feasible or economically viable to have completed such projects when the OEM starts to integrate.

Significant investments before a supply contract is secured can pose financial risks. However, the more preparatory work is completed, the smoother and faster the integration project progresses.

OEMs prefer suppliers who offer:

* Ready-made modules or components

* Solutions requiring minimal or no adaptation

* Well-prepared scopes that can be easily integrated

Suppliers should adopt a forward-thinking strategy:

* Conduct preparatory work to the economically justifiable extent

* Develop a range of potential scenarios

* Prepare comprehensive preliminary investigations and decisions

By taking this proactive approach, suppliers position themselves as valuable partners, ready to respond swiftly and effectively to OEM needs. This preparation can significantly streamline the integration process, potentially leading to stronger partnerships and more successful projects.

How can effective collaboration be achieved?

Effective cooperation between Original Equipment Manufacturers (OEMs) and suppliers hinges on two fundamental principles: openness and trustworthiness from both parties.

Successful partnerships involve OEMs and suppliers aligning their respective product and technology strategies over the long term.

This foresight enables suppliers to prepare thoroughly and in good time for upcoming integration projects.

This level of openness demands a high degree of mutual trust, as it involves exchanging competitively sensitive information. Both parties must ensure that this data never reaches their respective competitors, as it's highly confidential.

Mutual Responsibilities

* For OEMs: Making timely decisions about goals, priorities, and preferred partners.

* For Suppliers: Allocating resources early and making upfront investments at their own technical and financial risk.

The second statement parallels the series product for the end user, as explained in the previous article.

Just as OEMs pre-finance product development at their own risk, suppliers should initiate preliminary work early, assuming calculated risks.

What challenges and obstacles must be overcome?

Here, I would like to discuss some examples of typical challenges in an OEM supplier relationship

Price vs. proof of maturity

In supplier competition, prices are typically objective and transparent. Since the supplier's price directly impacts the OEM's costs, it is natural for the OEM to prioritize selecting the supplier offering the most competitive price.

However, evaluating the performance and readiness of the supplier's scope of delivery is far more complex.

For instance, if one supplier has already completed preliminary work and can provide tangible evidence of their components’ capabilities, while another cannot, the OEM faces a challenging decision.

Often, the supplier who has invested in advanced development may charge a higher price compared to a competitor without such preparation.

This dynamic can lead to situations where the OEM selects a supplier based solely on a lower price. However, this choice may result in difficulties later in the project, such as delays, integration challenges, or compromised product quality.

The lack of preparedness from the selected supplier can ultimately hinder project progress and impact the overall success of the product.

To avoid such pitfalls, OEMs must carefully weigh both price and maturity during supplier selection, ensuring that short-term cost savings do not compromise long-term project outcomes.

Beyond price: Assessing supplier capability

A critical, often overlooked aspect of supplier selection is evaluating the supplier's ability to participate in a development project professionally, punctually, and with high-quality work. This assessment is crucial for long-term project success.

A contract between OEM and supplier can be compared to saying "I do" at a wedding. Once the "wedding" (contract signing) is over, a "divorce" (contract termination) becomes significantly more complicated and potentially disruptive for both parties.

If the honeymoon period is quickly followed by arguments and dissatisfaction with the partner, this will have a negative impact on the final product and thus on the financial situation of both partners.

So don't be fooled by appearances. You have to look at what's inside.

In-Production Challenges: Cost Reduction vs. Quality Assurance

Once the end product successfully transitions to series production, the real business begins.

This phase introduces a delicate balance between cost optimization and maintaining product integrity.

Suppliers naturally seek to reduce production costs to improve profitability, while OEMs often demand price reductions from suppliers to ensure their own profitability. This situation creates an inherent conflict of interest.

When a supplier considers making changes to reduce costs, a critical decision point arises.

Option 1:

The supplier can take a transparent approach, discussing changes with the OEM for system-wide validation. However, this means the OEM becomes aware of cost reductions, potentially leading to demands for price cuts.

Option 2:

The supplier might implement changes without OEM consultation, potentially retaining cost savings but risking expensive quality issues that could damage reputation and relationships.

While the temptation to implement undisclosed changes may exist, the ethical and practical course of action is clear: transparency and collaboration with the OEM are essential.

This approach ensures product quality and system integrity, maintains trust in the supplier-OEM relationship, mitigates risks of costly quality issues, and aligns with long-term business sustainability.

Although it may be challenging to resist short-term financial gains, the long-term benefits of maintaining transparency and quality far outweigh the risks of unilateral, undisclosed changes.

In the end, open communication and collaborative problem-solving between suppliers and OEMs are crucial for navigating these in-production challenges successfully.

The evolution of OEM-Supplier relationships in a changing global landscape

The increasing complexity of products and the intensification of market competition have made the inefficiencies of the traditional OEM-supplier relationship less and less sustainable.

A re-evaluation of established practices and an exploration of new paradigms are required to address this shift.

Looking at the Chinese market, the degree of vertical integration at OEMs is much higher than in the West.

However, it's important to recognize that the current Western model didn't emerge by chance. Despite the disadvantages discussed earlier, it has persisted for decades due to numerous significant advantages.

This situation prompts several critical questions about the future of manufacturing and supply chain management:

* Will we witness a return to higher levels of vertical integration in the future?

* Will the current trend of specialization and division of labor continue?

* Can we develop innovative solutions that combine the advantages of both models while mitigating their drawbacks?

These questions are not merely academic; they have profound implications for the future of global manufacturing, supply chain resilience, and competitive strategies in the automotive and other high-tech industries.

I invite you to share your thoughts and perspectives on these crucial issues.

How do you envision the future of OEM-supplier relationships evolving in response to these global trends and challenges?

Your insights could provide valuable perspectives on navigating this complex and changing landscape.

Let's discuss it in the chat! I'm curious to see what you think.

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!

Product development — sounds self-explanatory, doesn't it?

But what exactly is a 'product'?

I would now like to get to the bottom of this fundamental question and take a closer look at the special characteristics of products.

I've worked on vehicle development my entire professional life, so I'm very good at how a vehicle product development process works and the environment in which it takes place.

But there are other products, some of which are fundamentally different in nature and are therefore consequently developed with different approaches in a different environment. This became clear to me during an exchange of experiences with colleagues from companies in other industries.

As always, one can learn from another. That's why I want to share my insights and thoughts in this article and encourage you to reflect on them.

I hope you'll find it inspiring and have fun classifying your products.

Have you ever thought about what a product is?

How it is defined?

Since I will be discussing the characteristics of the product development process and product development projects again and again in the following articles, we should first agree on our understanding of the term “product”.

What is a Product?

In the literature, the product is often seen in connection with production and the company's goal. As an example, I refer here to the definition from the Gabler Wirtschaftslexikon:

Result of the production and objective of an undertaking or also means of satisfying needs.

(Source: https://wirtschaftslexikon.gabler.de/definition/produkt-42902/version-266242 Revision of product from 19.02.2018 - 14:37)

However, I believe it is more appropriate to define the product not from the company's perspective but from the user's point of view.

With this in mind, I have developed the following definition:

A product is an item or a device that fulfills a desire or solves a problem.

In my opinion, a product must always serve a purpose, without a purpose it is useless and without use it is worthless.

The intensity of the desire or the severity of the problem that the product addresses directly influences the customer’s valuation of the product.

Or, as Martin Daum used to say:

A great product is characterized by the fact that the customer happily separates himself from his money.

Martin Daum, former CEO of Daimler Truck AG

Thus, the product serves as the foundation for any company's financial success.

Finally, you've got a connection to the business and, when appropriate, to the product's manufacturing.

Product or Service?

Some distinguish between products and services, suggesting an inherent difference between tangible hardware products and intangible services.

This can be explained if you define the product as the result of production.

After all, a service is performed rather than produced, meaning it does not undergo a traditional production process.

In my opinion, however, this distinction does not make sense.

A product must be understood and implemented as a holistic solution. It is a complete package that brings value and satisfaction to the customer, whether it is tangible, intangible, or both.

If you notice this separation in your business, ensure that the hardware and service departments don’t operate in silos at the customer’s expense.

I will go into this later in the article.

Now that I've defined the term "product," let's look at different types of products.

Single Item

A single product is characterized by the fact that only a single copy of it is developed, manufactured, and delivered to a customer.

This type of product can come in a wide variety of forms.

* As a building,

* as a special machine,

* as a production plant,

* etc.

As a rule, these products are based on modular elements or sometimes even series products, which are then heavily modified.

Think, for example, of an armored vehicle. Here, a series vehicle (car, van, or truck) is redeveloped into a bullet-proof special vehicle equipped with special equipment.

A key feature of single products is that a development project is not started until an interested customer has been found. So sales are at the very beginning here.

If a customer shows interest, the offer phase begins.

The company collaborates with the customer to develop the product requirements.

In this process, project approval takes place both when the customer places the order and when the company formally accepts it.

Challenges for the developer

The challenge for the developer in the case of a single product is validating the product before delivery.

Due to the product's complexity and cost, all forms of destructive testing are prohibited. As a result, testing and performance measurement must be conducted using theoretical validation methods and model-based validations.

Risk management plays a crucial role and must be applied consistently as a method.

Impact on the organization

For companies that produce single products, project management of development projects is at the core of their business.

This seems to result in top managers having gained extensive project management experience during their professional development or having managed large projects themselves.

Consequently, project management is strongly developed here and is highly prioritized in day-to-day business.

Series Product

In a serial product, there is a strong temporal separation between the development of the product and its sales/production.

A typical example that everyone is likely familiar with is vehicles.

The decision to develop a product is made by management.

Sales begin after the product has been developed and validated. It is then manufactured and delivered in large quantities in a repeatable production process.

The individual units may well be one-offs, assembled by combining pre-developed modules. The main difference to the individual product is the decoupling of product development and customer order.

Challenges for the developer

Understanding the customer requirements that need to be met is a challenge for the serial product developer.

There are many potential customers with very different wants and needs. However, these customers are not known at the time of development and therefore cannot be consulted. This complicates the specification, the definition of product characteristics, and the selection of validation methods.

Through detailed market analysis and a product architecture based on that analysis, a product portfolio has to be found that will meet all major customer requirements in the future.

A second challenge for developers is balancing the dual workload of initial development and ongoing series support.

Since a new product is being developed while quality issues in the current product need to be resolved, urgent customer requirements integrated, and costs optimized, developers are essentially juggling two tasks at once. This strains resources, makes it difficult to focus, and adds volatility to the task portfolio.

Impact on the organization

In companies that develop, manufacture, and sell series products, revenue is primarily generated through production and sales.

As a result, top management naturally focuses its attention on these areas.

However, the methods and processes in product development and day-to-day operations differ significantly.

While product development follows a project-based, long-term approach, daily operations rely on short-term, standardized, and highly synchronized processes.

Balancing these two worlds is a challenge. It is crucial to ensure that the urgency of daily business does not hinder or negatively impact long-term product development.

Mass Product

A mass product is designed once and then manufactured and sold almost unchanged over a long period of time.

Beverage cans, Euro pallets, or bricks are to serve as examples.

Since there is minimal development involved, I will mention this type of product here for the sake of completeness but will not elaborate further.

Software Product

Software products are characterized by the fact that there is no production or manufacturing.

Although it only exists in conjunction with hardware (a computer or control unit), it is not necessarily tied to it in its development.

Once developed, the product can be delivered in unlimited quantities and without delay.

As software is information processing, there are no physical durability problems. This significantly shortens the product development time, as the time-consuming proof of durability is not necessary.

Challenges for the developer

Typically, physical product variants are expensive because the manufacturing tool, logistics, and complexity of production set a natural financial limit on the number of economical product variants.

In the case of software, these costs are not to be found at all or to a much lesser extent.

This leads to an endless hunger for variants, functions, and features.

Complexity in development is the limit, but this limit is very difficult to identify.

This complexity in development, combined with the high speed due to the absence of hardware procurement times, creates significant pressure on function validation. A large number of functions with a high degree of combinatory variation must be tested in a very short time.

Impact on the organization

The focus of the business here is on the two core processes of product development and sales.

Product development therefore plays a key role in the economic performance of the company. In conjunction with the short cycle, it is at the heart of day-to-day business.

Mechatronic Product

Today, hardly any physical product can exist without software.

Mechatronik Products combines physical products and software.

With the help of software, product functionality is significantly enhanced, and costs are reduced when physical product systems are replaced by software.

On the hardware side, mechatronic products can include both individual products and series products. The combination with a mass product is rather rare.

While historically this type of product was characterized by a high level of integration of hardware and software, the current trend is towards "software-defined products".

These are products in which hardware and software are largely decoupled, and thus different development cycles are possible.

The software can be further developed on a stand-alone basis, independent of the hardware.

Challenges for the developer

The major challenge for developers lies in combining the extremely different speeds of hardware and software development.

The hardware can only be operated and therefore validated in combination with the software. Therefore, the software must be validated before the hardware can be validated. This means that the total development time is longer than developing the software and hardware independently.

This is of course absolutely undesirable, which is why we have to try to move both timelines into one another. Managing this is a major challenge.

Taking a closer look at this challenge is probably worth several articles.

Impact on the organization

The company must function as both a software company and a hardware company simultaneously.

This presents an organizational challenge.

Hardware-oriented and software-oriented companies operate with fundamentally different structures and processes, yet here, they must be integrated into a single cohesive organization.

If the physical part of the product is a series product, then there are actually 3 different processes that need to be integrated.

One can imagine that due to this fact, it is extremely difficult to find a suitable organization, a consistent control system, and an integrated process model.

Service

In connection with software, services are increasingly becoming the focus of the customer's attention.

Software is no longer just sold to the customer, but the software is used by the company itself and the solution is sold to the customer.

If only pure software is involved, this is referred to as Software as a Service (SaaS).

I think everyone is familiar with examples of software products that are hosted "in the cloud" and used by customers without owning them, instead paying a fee for the results.

Physical and mechatronic products offer the opportunity to bundle additional services with the product, which are offered to the customer in exchange for regular payments.

One example is the service contract, which includes the maintenance and repair of vehicles or equipment.

If data from the operation of the product is included in the service, a very high customer benefit can be represented, which of course should ideally be converted into a profitable business.

If the mechatronic product itself is integrated into the service, we refer to it as "Product as a Service."

In this model, the customer no longer buys the product but only the service it provides.

Challenges for the developer

In this constellation, which is very lucrative due to its potentially high profitability, the service must be developed at the same time as the hardware and software.

However, the development of services follows its own processes.

The challenge for the developer is therefore to integrate all aspects, ideally so that the maximum customer benefit is created. This has to be higher than in the classic model, where the customer is responsible for the operation himself.

In the development of both the physical product and the software, the needs of the service must be considered to ensure that the service operates with maximum efficiency.

Impact on the organization

In this business model, the organization must be a master in all three business disciplines.

* Development, production of hardware

* Software development

* Development and distribution of a service

Obviously, selecting the optimal organizational structure, implementing the necessary processes, and managing such a large organization involves a high level of complexity.

Sharpen your view – focus on your product

I hope this overview gives you enough food for thought to re-evaluate your own product and critically reflect on the challenges associated with it. I am looking forward to an inspiring exchange with you.

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

Let's talk about your product and your experiences with challenges for developers and the organization in the chat.

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

A project has a beginning and an end.

This statement is an attribute of projects included in the widely accepted project definition.

But when does a project really start?

... and what are the requirements for a successful project start?

This is exactly what I want to discuss in this article today.

If you are clear about this, you can start projects in a way that ensures a good prerequisite for a successful project progression.

Be curious, some of my statements are once again controversial, others are self-evident and hopefully many will be helpful.

When does a project start?

I often encounter the view that a project starts when it is approved by the board, a committee, or someone with the authority to make decisions.

I disagree with this, and I will explain my reasons.

The approval of a project is always associated with significant consequences for the company.

* Funding is released,

* Resources are allocated,

* the company's profitability and thus its balance sheet are affected,

* and customer and market-relevant product decisions are taken with the project approval.

The consequences of a project decision for the company are correspondingly serious. Therefore, a project must be prepared ultra-thoroughly!

However, precisely this preparation is already part of the project because it requires a project-based way of working, a project-based organizational and communication structure, and released resources, i.e. employees.

For this reason, a project must start with an official "project start" that is well before the project decision date.

For me, starting a project means that a group of employees is commissioned to:

* Organize a project,

* Gather or develop the information necessary for making a decision about the project.

* Present it to the decision-making body for implementation decision.

If this is completed, the project decision can then be made on this basis.

The project approval itself is the decision to implement the project in accordance with the defined premises and objectives, and to allocate the necessary financial means and resources.

I will discuss the steps from project start to project approval and beyond in different articles. As I mentioned earlier, today is about the project's beginning.

The beginning of a project is not an unforeseen circumstance.

There must be a reason to start a project!

This reason usually arises from a business necessity, which can have different origins.

Many organizations have business units tasked with identifying and assessing business needs and gathering information to ensure project success.

In product projects, it is usually the product management or product strategy team that takes the lead.

So let's take a look now at what information is urgently needed for a successful project start.

What information must be available at the start of the project?

1. Defining the problem that the project intends to solve.

The fundamental question is: Why start a project in the first place?

Clearly stating and justifying the issue to be solved is crucial at this stage.

The project team should be provided with comprehensive supporting material to ensure they fully understand and assess the issue.

Keep the priorities in focus!

Clearly and precisely distinguishing which problems urgently and inevitably need to be solved and which smaller problems can be addressed simultaneously is crucial.

The first category must not change on the way to project approval and later during project implementation.

The second category will be further refined and prioritized in collaboration with the team and the organization until the project approval.

When money and resources are scarce or when goals contradict each other, such problems need to be set aside. On the other hand, if resources allow, relevant additional content can be identified and integrated into the project if feasible and beneficial.

Here are a few more tips for formulating a strong project rationale:

* Describe the actual problem, not the causes of a problem.

* Stay solution-neutral.

* Verify the real existence and the description of the issue with the person who really experiences this difficulty himself. Don't trust hearsay and postmen.

* Avoid wish lists of items that do not solve an urgent problem. Measures will be created later based on the problems identified for resolution.

2. Establish the Deadline

The second crucial piece of information concerns the deadline for actually resolving the issue.

Too often I hear: As soon as possible!

Upon closer examination, I often find that the problem has been plaguing the organization for years, but is not taken seriously until it becomes urgent.

This is very bad, because it usually leads to missing the reasonable start date, and then the crisis is already there before the project can even be decided, because there is no time left for professional work.

To avoid this, use the following procedure:

* Pick up the issues as soon as they arise.

* Specify the latest time by which the issue must be resolved.

* Write a corresponding project into a project planning list.

* Based on the expected implementation time, set a reasonable project start date that allows enough time for a meaningful project process.

In any case, there should be a forward-looking plan that lists all current and hypothetical projects with their start and end dates. This list can and should be periodically reviewed and adjusted to reflect reality.

This ensures that you don't miss a project start and that you know how much time is available to complete the project.

Commonly observed errors:

* The start of the project is postponed, although the time is ripe, because there is no money or resources available at the moment, but the implementation date is maintained.

* The urgency is exaggerated because someone wants the project at all costs.

Be aware that delaying the start of the project will either require a corresponding delay in the end of the project, or will need to be compensated for by adjusting the project content.

3. Setting the Financial Boundaries.

Budget

At the beginning of the project, it must be clear how much funding is available.

I emphasize this point strongly. The financial framework should be clearly and specifically defined.

This information comes from the company’s overall business plan and is not related to the actual project at this stage.

Knowing the available funding allows the project to be managed as it progresses towards approval, so that the content of the project does not exceed the funding available. This results in speed and efficiency by avoiding planning loops.

The following errors are commonly seen at this point:

Error 1: A budget is set that is less than the available amount.

This is usually based on faith: If I tell them how much money is actually available, they will spend it all!

This approach is dangerous because it increases the risk that valuable project components won't be implemented or that essential quality assurance steps will be skipped. Either can reduce profitability more than the saved budget could ever compensate.

The project must be planned in a way that ensures minimal resource consumption while maximizing cost-effectiveness. It should be a given that the allocated financial framework is only fully utilized in absolute emergencies. If the project team cannot be trusted with this, it may be time to look for different people.

Error 2: No budget is communicated

The reasoning behind this approach is often:

"Let’s have the team estimate how much money they need, then we’ll see if we have that amount. If not, we’ll take the planned scope and cut the proposed budget."

This creates a highly toxic situation.

It can lead to everyone requesting as much money as they can reasonably justify, anticipating that cuts will be made anyway—so they inflate their estimates to ensure the necessary minimum remains.

Setting a clear maximum budget from the start prevents the development of concepts that are doomed to fail due to insufficient funding.

Important: This has nothing to do with the business case, which only comes into play later in the project approval process.

Product Cost

Define the product cost trend.

At the start of the project, there is no need for concrete product cost targets.

It should be clear whether:

* A reduction in product costs compared to the status quo is necessary.

* Maintaining the same product costs is acceptable.

* There is a real possibility of accepting an increase in product costs to implement the necessary solution.

An increase in product costs can be justified if it is offset by an above-average pricing capacity due to new customer value, or if other costs, such as quality costs, are significantly reduced.

In fact, this insight is automatically brought to the table when the business case is calculated on the way to project approval.

However, in my experience, this often comes too late. If the product cost trend is identified early in the solution design phase, it can help prevent mistakes.

The business case can’t be fully evaluated until the concept is ready for review. However, by that point, a considerable amount of time and effort will have already gone into developing the concept. If the cost trend doesn't align, the project will face expensive and time-consuming rework.

4. Evaluating Technology Readiness

Very often it is already clear that the problem cannot be solved with the known solutions. Something completely new is needed, something we have no experience with in our day-to-day business.

New technologies need to be understood well enough so that they do not lead to unplanned project loops.

First of all, such new solutions must be available in the first place.

Never start a project assuming that the brilliant engineers will come up with a solution technology if they just think about it for a moment.

There are departments whose reason for existence is to have such solutions ready at the start of a project.

If this is not the case, then the company has an organizational problem. I will discuss this in more detail in a separate article.

Second, the potential solution technologies must be evaluated to determine whether they can be made commercially viable in the time frame available.

A technology that is not feasible within the available time and budget need not even be selected as the basis for a concept study.

To evaluate a technology for project readiness, you can use classic project risk management.

5. Identify the Major Project Risks

In addition to technological risks, all other fundamental risks must also be identified.

The real project risk management begins after the project starts.

But before you start, you need to determine whether there are risks that could jeopardize the project as a whole.

If such serious risks exist, they must be resolved before the project starts, otherwise the project will be stopped later, and money and resources will be lost.

Are you wondering what such serious risks can be?

Here are a few examples:

* To produce the new product, a new factory must be built because none of the existing factories are suitable. But there is not enough time or money for a new factory.

* There are currently no suppliers available in the market for critical components or systems.

* The company lacks essential skills that are crucial for the success of the project.

Although these examples are hypothetical, I have encountered such risks in projects. These problems are not merely hypothetical; they truly exist!

6. Gather the Essential Resources to Power Your Project

The next step is to identify the team needed for the project, from start to approval.

* Resources must be defined,

* effort must be estimated,

* and activities must be planned.

The project can start when the supervisors of the required employees have commissioned or released them.

It would be beneficial to hold a formal project kick-off meeting.

Get together all the people who are affected in any way,

* the future project members,

* their superiors,

* the management of the affected organizational units

* and the stakeholders of the project.

Let’s all come together to collectively decide on providing the necessary resources.

7. Announce the Project Start to the Entire Organization

Now we have almost everything we need to start a successful project. There is one last requirement that needs to be met.

Communicate the project start to all affected employees.

The project team is usually much smaller in the period from project initiation to project approval than the project team that implements the project after approval.

This small team will depend on the input of many people in the organisation. Therefore, everyone in the organisation needs to be informed that this project has started.

It helps to keep everyone informed about what has been done so far, so that support can be targeted and effective.

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

If you have any questions, need my help or want my advice, you can contact me in the chat.

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

In my previous article, I explained how to successfully manage projects and emphasized the significant influence that company culture has on a project's success. I promised to discuss how a necessary cultural change can be achieved in a future article.

I would now like to fulfill that promise.

What is corporate culture?

For me, the term “corporate culture” encompasses the values, beliefs, and convictions that are shared by the majority of a company's workforce. Based on these, leaders and employees assess what is “acceptable” and what is not — how things are done or not done, what behavior is encouraged, and what behavior is discouraged.

Corporate culture determines how people within an organization collaborate and, as a result, how efficient and successful a company is.

However, culture is not easily shaped or changed. It emerges from a company’s traditions, national cultures, and employees’ personal value systems. It is also influenced by the priorities and values that the company's management reinforces or penalizes through its leadership practices.

A deliberate change in corporate culture requires several prerequisites, which I will discuss here. Furthermore, specific tools and approaches are needed to transform a desired culture into a lived culture.

There's a specific reason why I included the phrase “From Resistance to Habit” in the subheading. The beginning of a cultural change is always met with resistance. People don’t want to change their culture—they like it the way it is. They would have left anyway if not.

If the cultural change is successful, the new culture becomes the new habit. People have embraced the new way and wish to maintain it. Once the resistance has disappeared and the change has become second nature, the cultural transformation is complete.

Well—until the next cultural change becomes necessary.

Conveying the urgency for change

In every change process, there must be a willingness to change, otherwise the transformation will not succeed.

If people don't want to change, they can't be helped.

That’s what makes it so difficult and emotionally draining. At times, I struggle with frustration and hopelessness. However, I’ve always managed to hold on to hope and stay motivated through persistence and a strong will to implement change. As a change agent, I know that only if I exude confidence in the process can I inspire others to embrace change. It also helps to have trusted individuals to talk to about it confidentially.

I mostly work with engineers, and I often find myself having to explain and justify the need for change in an objective and factual manner. This makes sense, especially among highly rational individuals, as the facts need to be laid out clearly for them. Most of the time, it's not that complicated. People are intelligent and can recognize the shortcomings of the current situation and understand why change offers hope for improvement. We usually reach agreement on that quickly.

It is much more difficult for me to reach an agreement on the target state with the people. The existing culture regularly acts as a barrier. They want to change as little as possible, with only the minimum amount of change being acceptable for consensus. The target state that the minimal change is meant to achieve is typically also viewed controversially.

An intensive debate is therefore necessary to align on the scope and goal of the required change.

Never skip this step—it takes bitter revenge if you do.

The time required for the intellectual acceptance of the planned cultural change always takes longer than I anticipate. That’s why I have to start implementing it before full acceptance is achieved. But I persist and don’t give up until the goal is reached, even though it’s exhausting and tedious.

In addition to intellectual acceptance, however, I must also create a prerequisite that is much harder to achieve. I call it 'emotional acceptance.' It’s the realization that everyone is personally affected and must question and change their own values, standards, and approach.

It’s much easier to accept that others need to change than it is to accept that each individual must change themselves.

What follows from this?

* Unlike in a project, I can't wait for the completion of the first phase—the intellectual and emotional acceptance of the cultural change. I begin working on creating a sense of urgency and a clear target vision, but I start implementing it in practice relatively quickly. The more tangible the new culture becomes, the easier it is to gain acceptance.

* I cannot vote on the necessity and direction of change in a grassroots democratic way. As a change agent, I have to set the direction! I deliberately say the direction, not the target state. In the course of the transformation process, I remain flexible and constantly adapt the goal to the realities and feasibility.

Methods for Successfully Implementing Cultural Change,

In the cover picture you can see that I use 4 methods to bring about a culture change. These methods differ in difficulty and effectiveness. Let's start with the method that is the easiest to implement.

Procedural support

Procedural support involves providing instructions on work processes, handing out checklists, defining responsibilities, and establishing committee or meeting structures that support the new culture.

This forms the didactic framework for the teaching of the new culture.

I want to explain this point using the example of agile product development, because I believe that makes it easier to understand than an abstract explanation.

Agile development embodies a desired culture, I won’t elaborate on in this article — I’ll cover it in a separate one. Here, however, I will highlight methods that reinforce certain cultural aspects.

Ensuring accountability for core values

The roles of product owners, Scrum masters, release train engineers, and others assign clear responsibilities to individuals and teams, reinforcing a value stream-oriented approach. Each role has distinct responsibilities and is accountable for delivering value within its scope. In this way, these roles and responsibilities actively shape the value stream-oriented culture that forms the cornerstone of agile development.

Implementing accountability for delivery

Discipline and synchronized working methods are enforced through predefined time frames and meetings (artifacts). The structure is so tight that prioritization and coordination become inevitable. This instills efficiency and effectiveness, which are key cultural aspects of agile development.

Providing Structure Through Checklists

Feature Definition, Definition of Ready, Definition of Done, etc., are essentially checklists designed to ensure that critical work steps are completed and not overlooked.

I hope that these examples will make the way in which procedural assistance is used easy to understand.

I hope these examples help clarify how I use procedural assistance.

Of course, such assistance is not limited to an agile context; similar approaches can also be found in Lean, quality management methods, and more.

The use of procedural assistance is a proven method that has been used many times over. It is effective when these tools are recognized as such, and when I am clear about which tool is useful for which purpose.

I have also developed my own tools, which have proven to be very effective.

If you have any questions about this, or if you'd like to apply procedural assistance in a different context and need my help, feel free to reach out and we can discuss it in the chat.

Asking the right questions

I wrote at the beginning that culture consists of values, beliefs, and behaviors.

This is exactly where the questions come in.

I usually work on two levels with questions that encourage reflection on the cultural aspect of actions.

Value-Based Questions

The value system that defines the new culture should be consistently present, everywhere and at all times.

It is advantageous if not all values are new. Some existing values may be good and worth preserving.

This value architecture should be visually sophisticated and omnipresent. It should be displayed on the wall in every meeting room, placed on tables as handouts, used as a screensaver on computers, and featured on stickers for briefcases, among other things.

Now I can pose the question at every opportunity.

* Does this correspond to our values?

* Do we really want to do it that way?

The benefit of this approach is that it does not dictate a solution, but rather encourages reflection. As the solution is pursued, acceptance of the change grows, as does confidence, because the result seems achievable.

Procedural Questions

The second level at which I ask questions is procedural assistance, including the processes, responsibilities, and workflows described above.

The questions here are highly diverse, requiring me to utilize all my experience and expertise to formulate the appropriate question at the right moment.

* What's the problem?

* What is the root cause of the problem?

* Is that really the most important priority?

* Does it make sense to do it this way?

* Is this plan realistic?

As already mentioned, the questions are extremely diverse at this level, but they all have one thing in common:

Questions encourage individuals to engage in critical thinking and arrive at solutions self-sufficiently.

Since procedural support didactically leads to a new and desired culture, the interpretation and cognitive processing anchor the new culture in the minds.

New thought structures emerge and solidify in people's minds over time, eventually becoming habits. There comes a moment when individuals begin to ask themselves these questions, and that is what I aim to achieve.

Of course, it is not solely the responsibility of one individual to ask these questions; all managers must participate, and colleagues should also engage in asking each other these questions.

Practice, Practice, Practice

This brings us to the next element and takes the step towards greater effectiveness.

The old saying: "Practice makes perfect." also applies to the transformation process.

I ensure that the elements discussed are continuously reinforced. I begin with simple tasks and gradually increase the complexity, in accordance with the capabilities of the individuals within the organization.

Even in a marathon, one does not run 42 kilometers in the first training session.

In this context, I require what seems like boundless patience and perseverance. Often, I am tired of hearing it myself, and I feel exhausted, but I understand the necessity of persisting. Training demands numerous repetitions and a high degree of discipline in execution to develop the desired skills.

Sometimes I think: they'll never get it right if the practice just doesn't seem to work.

I convince, I motivate, I force, I use all the means at my disposal to move people to use the procedures, workflows, checklists, committees, meetings, values, tools over and over again.

This also serves the goal of forming a habit. If I no longer have to intervene and it has become automatic, then the transformation has succeeded.

Leading by Example

The final element is the most challenging, yet it is also the most effective.

The exemplification of the new culture!

It is entirely unacceptable for me, as a change agent, not to implement the new culture within my own environment.

That can be a bit bumpy, people know that I'm not perfect either. This even makes one likeable and believable and encourages others to help shape it. However, preaching one thing and doing another is not acceptable.

I implement the new culture at every possible opportunity. I utilize the procedural tools whenever I can, ask myself the same questions I pose to my colleagues, and continuously practice, practice, and practice.

And, of course, all managers must be on board with it!

You can trust me, employees consistently observe their boss's actions and follow suit.

When people sense that the boss thinks, 'Culture is something for those down there; it's none of my business, I have other priorities,' it becomes fatal.

Without the involvement of managers and everyone, from the team leader to the board of directors, sustainable corporate culture change cannot be achieved.

In my daily practice, this means that I must work just as diligently with the top managers to implement the new culture as I do with the employees in the organization.

This is not easy, as even bosses are human—and they are allowed to be. They can make mistakes, ask questions, and show emotions. However, employees will understand and accept this.

There is one thing that managers must never do: stand on the sidelines during a cultural change, remaining uninvolved or, worse, not showing up at all.

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

If you have any questions, need my help or want my advice on changing corporate culture in your environment, you can contact me in chat.

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

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!