Back When a Truck Was Just a Truck

In the first half of the last century, trucks were beautifully simple. We divided them into three categories:

* Light trucks

* Medium-duty trucks

* Heavy-duty trucks

They were universal tools. You hauled grain, coal briquettes, beer, milk, furniture, machinery—anything that needed to get from Point A to Point B found its ride on the flatbed of the same truck.

For manufacturers, the product was crystal clear.

One truck type = one bill of materials.

You knew the permissible gross weight, you knew the road conditions, and because inspections weren’t as strict back then, you built things a bit more robust just to be safe.

Life was simple.

Then Came Customer Focus

It didn’t take long for the variety of truck configurations to increase.

The original standard truck became increasingly adapted to specific use cases, body types, and customer preferences.

At first, manufacturers simply created more types. Alongside the flatbed truck, you now had semi-trailers, dump trucks, multiple wheelbase options, and various axle configurations to choose from.

Each of these types had its own bill of materials that guided production.

Sales Codes Made Diversity Even Greater

But then came the flood of additional customer requests, managed through sales codes. Customers could now select equipment details to customize their chosen base model.

Different engine ratings, transmissions, tank sizes, power take-offs, weight variants, and much, much more became available.

The truck the customer ordered was configured by the salesperson together with the customer, tailored to their specific needs.

The bill of materials that guided production was no longer predetermined by engineering.

It was now calculated algorithmically using sales codes and plus/minus bills of materials.

Each sales code had its own bill of materials with plus and minus positions.

These bills of materials modified the base vehicle bill of materials. Part numbers marked with minus were removed from the base bill of materials; part numbers marked with plus were added.

A particular challenge was that there wasn’t just one sales code per vehicle order—there could be several. So you also had to list as minus all the parts that might have just been added as plus by another code.

This way, a mainframe computer could calculate from the base bill of materials (the bill of materials for the base vehicle) to the correct bill of materials for the customer’s vehicle using Boolean algebra.

I can hardly believe it myself, but I personally wrote plus/minus bills of materials.

Not on a computer. No, with pencil on printed forms. Entering them into the mainframe was a job for specialists!

You can surely imagine that this work was extremely time-consuming and error-prone. The most-used work tool was the eraser.

Every designer had to know their scope across all vehicle variants in detail and explicitly document all possible combinations.

Inevitably, the time came when this system could no longer be maintained and was replaced by an innovation in product documentation.

This innovation was the component bill of materials.

NED – The New Engineering Documentation

With the new product documentation, base bills of materials and sales code bills of materials disappeared and were replaced by component bills of materials.

A component bill of materials contains a small number of part numbers that are always—without exception—installed together.

Each of these component bills of materials comes with a long instruction sheet of Boolean algebra, called encoding.

It describes exactly in which sales code combinations the specific component bill of materials is applied or not applied.

The original vehicle type is now just a container holding all component bills of materials that might be needed in any possible combination of sales codes.

When a customer orders a vehicle, a computer program (the variant configuration system) calculates the specific vehicle bill of materials for the customer order based on the codes selected by the salesperson together with the customer.

You can surely imagine that writing Boolean algebra for component bills of materials is not trivial. It’s probably one of the most demanding tasks a designer faces in their daily work.

But there’s one huge positive effect: Everything that fits together doesn’t need to be described!

This means that when writing Boolean algebra, the designer can and must focus on what doesn’t fit together or doesn’t work and must be redirected through encoding to a buildable and functional configuration.

In this way, a virtually infinite number of possible vehicle configurations becomes possible without having to explicitly develop and document each one beforehand.

The Modular Product Platform

The next simplification step was to standardize interfaces throughout the vehicle.

It’s logical: the more things that don’t fit together, the more must be regulated through encoding.

The next level of simplification therefore consists of designing the vehicles architecture technically so that through cleverly standardized technical interfaces, as many things as possible fit together.

Then they no longer need to be encoded in complicated ways but can be controlled with simpler code rules.

Modular concepts were developed and brought into production for all construction scopes.

Whether a combination is needed or not, it simply fits and therefore doesn’t need elaborate control.

The result:

* Fewer parts (component bills of materials)

* More possible vehicle variants

Everything Perfect?

So we’ve almost arrived in a perfect world, haven’t we?

Just add a bit of AI and machine learning to automate the remaining Boolean algebra writing, and we have everything we’ve always wanted.

The manufacturer has relatively few parts in inventory, and the customer gets any variant they want.

So everything’s perfect?

Of course, in reality, this isn’t as trivial as I’m presenting it here in simplified form.

But the basic logic is correct.

I’ll take the opportunity in many future articles to go into detail about the opportunities and challenges of this variant control.

Since it’s an extremely large topic, it would help me greatly if you’d ask questions in the comments about what interests you most urgently. Then I can address those aspects first.

Please subscribe to my newsletter so you don’t miss any of the articles.

How Variant Control Impacts Development Scope Management

Why did I give this whole long preamble when today I’m actually concerned with how development scopes can be controlled?

Well, it’s quite simple:

I assume that someone unfamiliar with our business in detail imagines development the way it really once was, when a truck was truly one truck.

If the truck needed to be renewed or improved, you simply took that specific truck and redeveloped or modified it.

In the current situation, that’s no longer possible, because that one truck no longer exists!

Even today, not everyone has grasped that the product of every vehicle development is no longer a truck but a truck modular platform!

And this has drastic consequences, because unfortunately this platform is incredibly large and must therefore be simultaneously modified in many places for different reasons.

These reasons include:

* New vehicle applications need to be incorporated, requiring new vehicle variants

* Legal requirements must be met, requiring either the entire platform to be modified at certain points or specific scopes to be modified for certain markets only

* Technological advancement occurs in technical systems

* Quality problems, supplier issues, or other unwanted disruptions must be eliminated

The necessities to modify the product platform are extremely diverse and require varying amounts of time.

But at all times, it must be ensured that the complete product platform functions and is customer-ready!

Because otherwise, not a single truck can be configured.

The Solution: A Four-Stage Project Architecture

To master this complicated situation, the famous elephant must be sliced.

A Key Central Element: The Project

The project bundles development scopes on the product platform that can be handled by a project organization with minimal interfaces and that follow a common timeline.

Minimal interfaces in this context means that project contents are assembled to bundle substantively related matters, thereby keeping the number of involved people and organizational units to a minimum.

For this, it must first be clear what exactly is needed. I’ve written extensively about this in my article “Getting the Timing Right: Planning Product Development Projects the Right Way.”

Typically, the need for changes to the product platform is so great that multiple projects must be organized. Otherwise the scope of work for the each project management team would become unmanageable large.

For This Whole Construct to Actually Work, Project Timelines Must Be Stable and Known for the Entire Project Duration

Classic project management is required here.

The Project Program

So that, what we’ve just separated still fits together, the newly defined projects must be combined into project programs.

All projects that have their Start of Production (SOP) in a common time period are now bundled into a program and synchronized using multi-project management methods.

This requires a small but excellent program management team that knows all affected projects with their mutual dependencies and orchestrates a structured process that maintains synchronicity.

An important detail is that the program management team coordinate the start of projects. This ensures that project timelines are sensibly synchronized from the beginning.

Since we’re developing a hardware product, prototypes must be built for testing, and these must be complete, functioning trucks.

Therefore, projects within programs must be scheduled so that there are points in time when all projects have the appropriate technical maturity to start vehicle validation.

Since we need a market cycle that’s shorter than the duration of a project program, we need multiple staggered programs.

The Drum Beat

If you’ve been faithfully following my newsletter, you already know the Drum Beat.

It ensures that the milestones and quality gates of the projects that are indispensable for a functioning program are actually achieved with the essential work statuses.

This premise is extremely important because schedule delays in one project affect the entire platform and can therefore cause all other projects in the program to run into difficulties.

That’s why schedule discipline is absolutely critical!

The ToDo Sprint

The lowest level in the program architecture is the ToDo Sprint.

Since in a matrix organization with a functional organizational structure, work from all projects and programs is processed in the same organizational units, the ToDo Sprint controls task completion.

Let me point out here that this organizational form also has something to do with the product platform landscape explained at the beginning.

As I explained, the highly variant product platform requires employees who have a complete overview of all relevant content in the segment of the product platform they’re responsible for. This knowledge is indispensable for encoding component bills of materials.

But now it’s a prerequisite that all changes to these scopes must also be made by the same team!

This isn’t just about packaging space issues but also about knowledge of customer requirements in the corresponding segments of the platform and their functional implementation, which is also reflected in the encoding.

Even if systems engineering promises to get all this under better control, it won’t work in the coming decades without highly qualified employees. Believe me.

So we organizationally bundle tasks from all projects in such a way that teams have clear priorities and the understanding of the modular product plattform will sustain.

Conclusion

Today in this article, I ventured an experiment:

I wanted to condense a highly specialized situation so that the essential logic of how product structure and project structures are connected fits into a short newsletter article.

I’m aware that you surely have many, many question marks after reading this.

So don’t hesitate to ask me questions.

This way I can target the many other aspects there are to discuss about this very large topic area.

I’d also be very interested to know if you have such constellations in your environment.

What questions do you have about modular product platforms and multi-stage project management? Share in the comments below, and I’ll address them in future articles.

We can also chat about it.

I’ll dive deeper into the details in the coming articles. Please subscribe to the newsletter so you don’t miss them.

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

If my newsletter resonates with you, please consider sharing it with others.

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