There's something strange about vehicle development projects: they span years—yet time is always too short.

Whether it was a complete redesign of the entire product portfolio or just a minor facelift, the pattern was always the same.

* It starts off rocky.

* The further the project progresses, the more my daily work transforms into pure chaos: task forces I suddenly find myself in, top management reviews that stress me out week after week, and micromanagement that drives me crazy.

* What was planned as a structured project turns into complete chaos that somehow, miraculously, still gets finished in a halfway decent manner.

Do you recognize this pattern too?

After years of this experience, I decided to get to the bottom of it.

I analyzed why this happens—and developed a solution approach that can break this death spiral.

The Problem Lies in Understanding What Exactly Needs to Be Done

Every project needs its project plan, where activities, milestones, and consolidation points are: coordinated with each other, realistically scheduled, and clearly documented for everyone to understand, so that a fixed completion date planned for the future can be reliably achieved.

For this reason, creating this project plan is one of the first activities that must be carried out by the project team.

But is the entire project team really involved?

No, usually not! ...and with that, we already have the problem on the table.

Such a plan doesn't emerge from a blank sheet of paper.

There's usually a generic planning template as the starting document, which forms the company standard for development projects. (This planning guideline is often called the "development system.")

If you want me to go into detail about the development system, write it in the comments.

It's mandatorily prescribed as a process document in quality systems, regularly audited, and its application is verified.

In this template, the important interdisciplinary dependencies in the project flow are pre-conceived and documented, common project management methods are applied, and experiences from past projects are incorporated.

On this basis, the concrete project plan is now worked out by the project manager and employees who are experts for project plans.

What does "worked out" mean exactly?

Typically, the ideal initial plan is compressed, squeezed, and tasks are parallelized until the desired or management-specified series introduction date appears achievable.

- So now the plan is finished. -

The dates for quality gates are set, deliverables are described, and important milestones are planned.

Now we can get started.

Everyone knows what to do. "We're not doing this for the first time" is the motto.

People know the company standard—this can certainly be assumed.

The fact that the concrete project plan no longer has much in common with the planning template is supposedly no cause for concern. If something is unclear to someone, they can just ask.

(You probably caught the irony right away—but sadly, this is often how things actually play out.)

The first surprise comes at the first quality gate:

Unfortunately, not everything that was planned has been completed.

There are always good reasons:

* "The time was too short to accomplish everything. That was actually always clear, but nobody listened to me."

* "The capacity wasn't sufficient for everything. There were too many other important priorities that prevented me from completing the work."

* "I didn't get the input from my colleague that I needed. It should have been clear to him that I needed it. It was implicitly in the plan. The project manager should have taken care of that."

* "Necessary decisions weren't made or were made too late. Management is never available when needed."

Now it is what it is, and we have to deal with the delays.

"Latecomer dates” are coordinated, and tracking systems are established to monitor their completion. ( In German language “Nachzüglertermine”)

Additionally, the project plan must now be re-planned because time can't be turned back.

The effort for rework and re-planning consumes the resources needed for the next task.

From now on, it only gets worse.

The Root Cause Lies in Poor Coordination and Poorly Detailed Planning

The project plan serves as a guide for the entire project period and provides an understandable overview of the relevant steps and their temporal arrangement.

This is important and, in my view, indispensable.

However, if you expect it to map every detailed coordination between all employees involved in the project, it won't be able to meet this expectation.

Attempting to do so leads to the justified criticism that project plans are bureaucratic, confusing, unrealistic, and detached from reality. This is a criticism that the founding members of agile product development also addressed.

Who can plan years in advance what exactly and in detail must happen on which day or in which week? That's unrealistic, and attempting to do so leads to waste of time because things will turn out differently than planned anyway.

However, this fact must not lead to these detailed plannings not taking place at all.

Continuous Alignment Is Not Optimal

Usually, these discussions and detailed planning take place continuously during project work.

Project team members instinctively recognize the importance of these clarifications.

Therefore, permanent consultations take place between the project management team and the line areas, and employees also coordinate with each other.

The results are found in employees' heads, in meeting minutes, and in various tracking tools.

What's the problem with this?

I've actually found several problems:

* This detailed planning takes place uncoordinated. Therefore, there's no certainty that all necessary planning is covered.

* There’s no shared understanding of the agreements, as they tend to occur bilaterally or within small groups. As a result, affected parties are often neither involved nor adequately informed due to lack of awareness.

* Since work continues in parallel, agreements are often outdated before their implementation can begin.

* When decisions are necessary, they can only be made in relation to the one isolated case currently under discussion. For this reason, resource problems are particularly difficult to quantify, and prioritization occurs on incomplete data. The big picture overview is missing.

The Drum Beat Is the Solution

The solution to the problem consists of conducting detailed planning in an organized, structured, and methodical manner

The Drum Beat replaces simultaneous planning and execution with three sequential, regularly repeating phases carried out by the entire project team simultaneously.

* Planning activities for the upcoming three months.

* Implementing the planned activities.

* Reviewing status and closing activities.

Through the Drum Beat, the project consolidation points represented by quality gates in the classical model are supplemented by more frequent consolidation points.

Due to the short planning period, both high quality and realistic planning can be reliably guaranteed.

How Long Does a Drum Beat Last?

The length of the Drum Beat depends on the complexity of the project organization and the team's ability to plan quickly and precisely.

The ratio of planning time to implementation time must be in a healthy balance.

If the planning phase takes several weeks due to many detailed consultations and an inexperienced team, then the Drum Beat should span 3 months.

If the project environment is more simple and the team is experienced so that planning can occur in a few days, then the Drum Beat can be shortened to 2 months.

Drum Beat Deliverables

A project needs a clear goal.

Every quality gate demands transparency about what must be completed by then. The required status is described in the form of QG deliverables in the development system.

Similarly, every Drum Beat needs a concrete, measurable result—otherwise, targeted planning isn't possible.

These results are the Drum Beat Deliverables.

They are derived from the overarching project plan and reflect the concrete temporal and content-related necessities of the project at the respective Drum Beat point in time.

Unlike quality gate deliverables, they are not generic but tailored to the concrete project and its current status.

I'll address Drum Beat Deliverables in one of my next articles.

Please subscribe to my newsletter so you don't miss it.

To-Do Planning

Once the Drum Beat Deliverables are clear, the team can plan their very concrete activities, coordinate contributions among themselves, and address necessary decision requirements.

While Drum Beat Deliverables must be defined as concrete results, ToDo’s can be planned as activities to be executed.

However, within the framework of collegial coordination, it must be ensured that the affected team members agree on the concrete content of the contributions so that implementation is realistic and delivery will occur reliably.

The duration of a ToDo sprint is one week for a 2-month Drum Beat and two weeks for a 3-month Drum Beat.

Here again, a good ratio between planning time and implementation time must be maintained.

Reviewing Status and Closing Activities

At the end of the Drum Beat, the project team collectively examines what has been achieved.

* Have all Drum Beat Deliverables been completed?

* What does the concrete result look like?

* Can it be frozen as a basis for further work?

The review forms the starting point for planning the following Drum Beat.

And of course, a retrospective belongs here too:

"How did it go, and can we do something better in the next Drum Beat?"

With a well-coordinated team, planning is so precise that planned results are achieved with high reliability.

If compromises are necessary to enable the achievement of results, they are negotiated and decided during Drum Beat planning, and their consequences are considered in further planning.

Spill Overs

Despite strong focus on reliable delivery of agreed work results, it will always happen that something hasn't been completed.

We call this a "Spill Over."

It's important not to simply push these matters forward. They must be re-planned.

The first question is whether this activity, now delayed, is even still meaningful at this point.

In any case, we must prevent the first schedule delay from becoming a chain of schedule delays.

The goal must be that by the end of the next Drum Beat, the delay is caught up and no impact on the overarching project plan occurs.

Why Drum Beat and Not PI?

Isn't the Drum Beat simply a PI as defined in agile project management methods?

The answer is: Yes and No.

Just like a PI, the Drum Beat is short-cycle planning that follows a strictly prescribed schema.

The sequence of planning, implementation, and review/retrospective is the same.

However, at the end of the Drum Beat, there's no ready-to-ship product that generates short-cycle customer feedback and thus provides new insights for further development of the product.

This isn't realizable with a hardware product like a vehicle.

In this regard, the Drum Beat is more comparable to a classical quality gate.

It represents a milestone on the path to the next quality gate, just as the quality gate is a milestone on the path to the project goal.

However, the Drum Beat isn't planned out from the beginning of the project like the quality gate.

I would describe the Drum Beat as a hybrid mixture of PI and quality gate that realizes the advantages of agile approaches under the special restrictions and premises of a hardware development process.

After reading this article, many questions are going through your head?

Then don't hesitate to ask them in the comments—I'll try to answer them to the best of my knowledge.

We can also chat about this topic.

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