For the most impatient among you, here’s the answer right away:

In the commercial vehicle industry, I consider it fast to bring a new vehicle to market in 4 years.

With the classic approach used in the past, new vehicle development took 6 to 8 years.

In the article “Getting the timing right”, I explain that in the commercial vehicle industry, it’s possible to estimate market demand over a 3 to 4-year period with reasonable accuracy.

In many cases, external influences limit the available time to just 4 to 5 years. So it has to be faster anyway, and then it’s good if there’s a plan for how to make that possible.

In this article, I will explain what project approach can achieve a short development time while still producing a proper product.

If you work in a different industry where these timeframes are different, you may still find food for thought that can help in your environment to reduce project duration to a necessary level.

I’d like to ask you to write in the comments whether you were able to find such parallels. Fair warning: this works better if you’ve actually read the article first.

Why Do Classic Waterfall Projects Take So Long?

Let’s first understand why classic product development projects take so long.

Based on that, we can consider where we want to start making changes.

Classic Project Philosophy

Classic project management places the highest value on reducing financial project risk.

It must be absolutely certain that large amounts are only invested and contracts are only signed when the content work is finished and the result is confirmed through complete validation.

* New technologies are only developed when it’s certain they’re really needed in the market.

* Suppliers are only selected and purchase prices negotiated when all technical specifications are known and their correctness is proven.

* Costs for production tools and factory investments are only spent when the product has been successfully validated.

* Customers and markets are only informed after project completion, so they don’t delay their purchase decision to wait for the new product.

The cost of this certainty is having to accept a long development timeline before product availability.

Well, and since everything is so certain, the investments can be high. If the business case shows a good payback, then this money is supposedly safely invested. - Or so the theory goes. -

What Are the Problems?

Let me say it right at the start: You can develop very good products with this classic approach! This has been proven in many successful projects in the past.

However, all of life is a compromise, and so is the classic approach. Often this compromise is simply not the best compromise.

Before I move on to a different approach, I want to address the problems and challenges that come with this classic approach.

Not All Assumptions Are Safe

To gain certainty, decisions need a secure data basis.

As just described, in classic vehicle development projects, this certainty is created by carefully and laboriously securing all decision premises before a decision is made.

Unfortunately, it’s impossible to do this with all premises. Some premises inevitably arise for which assumptions must be made that cannot be validated.

These premises now introduce risk into the project that it’s not prepared for and can’t handle well, because absolute risk avoidance is also a project premise.

When these risks then actually occur, they throw the project off track.

Decisions are reversed, setbacks in project flow cause time delays and excessive costs.

Changes in the Environment Create Instability

This problem is amplified by the fact that, due to the long project duration, supposedly secure premises become outdated and generate volatility that leads to the same consequences.

Sequential Work Is Always Connected with Loops

Ironically, the effort to boost efficiency by having departments wait for validated data leads to considerable rework.

* First the developers develop.

* Then the purchasers negotiate with suppliers.

* Production planners plan production next.

* At the very end, the after-sales experts figure out how the product can be repaired.

* The controllers always carefully ensure that money is only spent when everything is clear.

When specialist functions start later, they inevitably discover issues with the supposedly validated data only at a later stage.

The premises originally considered secure turn out to be wrong in the course of work, and the correction causes setbacks in project progress.

Previously completed work based on the original assumptions must now be repeated.

This causes time delays and significant inefficiencies.

The Required Time Is Not Available

The worst problem is that there’s often simply not enough time for such an approach.

Then the 6 to 8 year project plan is simply compressed like an accordion.

Now it’s over with the secure premises!

The lack of time leads to poor results that are inadequately checked.

Occurring risks are no longer a regrettable exception but a certain reality.

An organization geared toward certainty is thrown into chaos and is methodologically unable to deal with the chaos.

This is the point where task forces, freestyle, and excessive resource and time expenditure become the project management method.

Project goals are now secondary; now it’s only about being able to deliver at all.

Alternative Approach - The Super Sprint

Project Philosophy

An alternative to address these problems is to focus on speed instead of financial certainty.

Although it may not seem so at first glance, it doesn’t mean that more money is spent.

It only means that the supposed certainty is only proven late in the course of the project.

* New technologies are prepared at a time when no concrete market need is yet recognizable.

* Project goals are set conservatively and in close alignment with customers, without the expectation that the product must be offered unchanged for a long time. Quick availability and subsequent short-term further development are project premises.

* All specialist areas work simultaneously and complete their stages at the same time. (You can read about the individual phases in DCVI in a separate article.)

* Short-cycle planning and implementation phases enable situation-appropriate prioritization and proactive response.

Solution to the Problems

Predictive Technology Validation

Technology development takes time, there’s no way around it.

To understand technologies sufficiently well when they really need to be applied on a large scale, you can’t wait until the last moment.

What seems like the most cost-effective approach – delaying investment until you’re absolutely sure – actually proves the most expensive.

The better approach is to engage with the technology immediately and learn for little money and on a small scale.

I’ll describe exactly how to do this in a separate article.

This phase can be completed in a few months; for large, very innovative technologies, it can take one to two years including customer feedback.

There are several important premises to maintain:

* Everyone must participate, not just product engineering! Purchasing, production planning, after sales, even controlling must use this opportunity to acquire the necessary competence to assess and apply the new technology.

* End customers must be involved and have the opportunity to develop qualified feedback. They must be part of the activity.

* Over-development must not occur in this phase. When the technology is sufficiently well understood, pause until a concrete application project is started.

When the time comes that the technology is needed in the market, the product can be developed quickly and without loops based on the identified market need and good knowledge of the technology’s potential.

If the technology doesn’t meet expectations, it was better to invest little money in this realization than to bring the technology to production for expensive money because there’s no way back.

The DCVI Project - The Super Sprint

When the time comes to start the product development project, the DCVI approach is applied.

I know, I know. The agilists will criticize me. You can’t stretch a sprint over 4 years; then it’s not a sprint but something else.

Fine by me, let me call it a “super sprint” then.

Nevertheless, the approach used in a 1-week sprint also makes sense over a relatively long period.

The approach consists of 4 phases that all involved employees complete together.

* Definition - Everyone aligns specifications with each other. I really mean “everyone”! This is an exciting phase because nobody yet knows exactly how they will solve their problems. Nevertheless, it’s important that all concepts, strategies, and premises are integrated and coordinated with each other. This is the heyday of systems engineering. At the end of this phase, everyone looks each other deep in the eyes and knows what each individual’s result must be for the product to work in the end.

* Creation - Now everyone develops the concrete solutions. Intensive teamwork is required here as well. At the end of this phase, the product and all its accompanying processes are theoretically finished. Again, everyone looks each other in the eyes and says with deep conviction: “I’m sure this will work!” But everyone also knows that no one can be completely sure because there’s no proof yet. The certainty is based purely on the professional competence of the involved employees.

* Validation - The product is built and tested together with all accompanying processes. From now on, only what doesn’t work is fixed, and this must happen very quickly. At the end of this phase stands the question: “Are we really finished?”

* Implementation - Now only the process capability of the large-series process remains to be installed.

There’s naturally a lot to tell about each phase, so I’ll write separate articles about each.

The Magic Word Is: Simultaneous

For the product to be developed in half the time, no one can wait for anyone else! All specialist functions work simultaneously and continuously align their work progress with each other.

At the end of each of the 4 phases stands a milestone with a detailed review and the freezing of the work result achieved so far.

For this highly integrative working method to function, organizational prerequisites and procedures must be implemented.

A very important procedure is the Drum Beat and the project roles (project manager, project management master, product architect and functional unit representative) associated with it.

At the end of the project, or as I call it, the super sprint, stands a deliverable product.

Simultaneously, however, the next super sprint is already running, further developing the product and quickly implementing learned insights.

How Long Do the Individual Phases Last?

The secret is to take the time at the beginning to think carefully and work thoroughly in order to be fast at the end.

* Definition - 1 year

* Creation - 1 year

* Validation - 1.5 years

* Implementation - 0.5 years

We exclude technology preparation from the project timeline so that it doesn’t influence the period between project decision and series readiness.

So, the product needs 4 years from project start to series maturity.

After completion of the creative phase, the focus shifts from design to validation.

At this point, the next project already starts with its definition phase.

The customer thus receives an improved product every two years. They don’t even notice the four-year project duration.

Software Is Faster

Everything written so far considers the temporal restrictions that hardware places on the development projects of a commercial vehicle.

Software development offers the possibility of being brought to market faster. Therefore, shorter software cycles are overlaid on the hardware cycle of 2 years.

Now’s the right time to jump into the comments – I’d love to hear about similar experiences or parallels you’ve seen.

We can also chat about this topic:

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!

I’d be very grateful if you shared my newsletter with your friends and colleagues.

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