Business Practices for Engineers

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 …

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

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 …

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

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 majo…

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

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 decisi…

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

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…

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

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 i…

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

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 goo…

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

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 ph…

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