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!

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