There are moments in work life that you never forget.

I experienced one of these moments when we introduced our first Drum Beat in a pilot project.

The project team sat together in a meeting, planning the Drum Beat deliverables.

Everything should have been sorted out. Now we just needed to wait for everything to be implemented, and then we could celebrate our first successful Drum Beat.

The review day arrived, and the project team gathered to check off the Drum Beat results.

That's when a project management team member, who had taken responsibility for a Drum Beat deliverable, said:

"I didn't communicate the Drum Beat Deliverable to the project team because it's nonsense anyway. I had them work on the things that are really important."

I was shattered. My world collapsed.

But looking closer, I realized we had made serious mistakes in our Drum Beat planning.

Just quickly sitting together and writing something down isn't a sustainable planning process and doesn't create commitment.

Since I believe you must learn from your mistakes, we developed a concept for how Drum Beat planning must be organized to be complete, realistic, and reliable.

In this article, I'll introduce you to this concept, hoping you can avoid the negative experiences I had.

It’s a five-step process.

Drum Beat Planning isn’t something you can do in a single day.

It’s a process that takes several days.

The exact duration depends on:

* the complexity of the project,

* the size of the project team,

* and the experience of the project management team.

You should plan for at least one week. In many cases, more time is needed. However, it should not take longer than four weeks.

In the following sections, I will explain each stage so that you gain a solid understanding of the entire process.

Review

Unless it's the first Drum Beat in a project, every planning phase starts with assessing the current status.

For inexperienced teams, this is already the first emotional moment:

"Leave me alone. I still have time until the Drum Beat ends."

"I don't have time to explain in detail where I stand. I need to hurry to get finished."

Sound familiar? Does this happen with your teams, or does it only happen in my environment?

Write me your experience in the comments.

In my case, training helped.

The entire Drum Beat Process must be taught to all team members so that they understand the context of this exercise.

Then you have to take the teams by the hand and just do it. After a few repetitions, the value of the approach becomes clear, and resistance fades.

It is a fact that the project management team needs to get an overview of where the project stands before starting a new planning round.

It doesn't matter whether the work is already finished or not.

Shortly before the Drum Beat ends, you can already estimate pretty well where things are heading.

Will people manage to complete the Drum Beat Deliverables, or are shortcomings and spillovers already showing?

The review happens in well-organized meetings where service providers and service recipients jointly assess the situation, and the project management team gets a complete overview of all DBDs.

Based on this, the actual planning can begin.

Planning as Individual Work

In the next step, I usually encounter the next big challenge.

Everyone constantly complains about sitting in too many meetings.

But as soon as the planning phase starts, the project leader calls the first meetings to plan together.

I haven't figured out why this happens:

* Do people believe they'll achieve better results together?

* Do they want to save the time of individual work?

* Do they think the results of quiet work are flawed?

What's your opinion? Do you observe the same tendency? Do you have a theory about why this happens?

In my experience, planning in quiet isolation is a very important stage because it fosters a deep understanding of processes and priorities.

I like to say jokingly: "When the project management team finishes the plan, they can immediately throw it away."

Planning is valuable not because it's written down, but because the process of planning creates an understanding of how to achieve goals and what's most important.

That's why the project leader and every member of the project management team must take time to become clear about what exactly needs to be done in the next stage.

For this work step, project management team members need the following information:

* The review results:

* Are there catch up items?

* Are there any problems that need to be solved?

* Have priorities changed over the last period?

* The project description with the project goals.

* The project plan with its Quality Gate Dates and Deliverables.

* A planning template listing the Drum Beat Deliverables typically relevant in this project phase.

Ideally, this information should be provided in the form of a central planning document.

As an additional information source, it's possible to ask individual project team members for advice.

I also recommend peer coaching - getting opinions from employees from other projects.

However, everyone should do this individually according to their own needs, rather than in large meetings.

The result of this planning step is a DBD backlog with all DBDs that each project management team member has planned.

The DBD templates, as I presented in my last article, should be filled out in a first draft.

This planning phase should be very short. The goal isn't to make perfect planning - it's about each individual developing a basic understanding of the further process.

Prioritization

While creating the Drum Beat backlog, it it is advisable to prioritize the Drum Beat Deliverables.

Since prioritising is always a matter of judgement, I suggest the following procedure:

* The newly found deliverable is first written at the bottom of the backlog.

* Then you evaluate whether the deliverable above is more important than the newly entered one.

* If the answer is “No”, the more important deliverable moves up one position and the process repeats.

* If the answer is "Yes," the order remains, and prioritizing the new DBD is complete.

Swarm Intelligence Comes into Play

In the next step, the backlog developed through individual work is now jointly integrated and prioritized.

Planning meetings are organised, during which the leadership team creates a common Drum Beat Deliverable backlog based on their individual functional experience and perspective.

The DBDs are sharpened, priorities are agreed on.

Now attention is also paid to available resources:

* Can the team handle all of this?

* Which compromises make sense and which don't?

* What are the effects of the compromises?

* What influence do these effects have on the Drum Beat planning of the current and future Drum Beats?

This stage of Drum Beat planning can't be completed in one day. To ensure everything is evaluated and nothing is forgotten, several days of planning are necessary here. Consultation with the project team is now more intensive.

At the end of this phase stands the prioritized backlog of Drum Beat Deliverables for the new Drum Beat with formulated Drum Beat Deliverables and assigned responsibilities.

I just wrote "consultation of the project team." But these words contain emotional volatility once again.

Direction versus Grassroots Democracy

Yes, there's the management philosophy that the team should find its own way and management should stay completely out of it.

My experience with this approach isn't good.

If you ask a team of 1,000 people for their opinion, you will get 1,000 answers. These 1,000 people will always agree that there is insufficient time and too few resources to successfully complete the project.

Then 1,000 pairs of eyes look at you questioningly and signal: Project leader, now tell us how you want to solve this Gordian knot.

I know what I'm saying now is controversial. If you disagree, please write it in the comments. I'm curious about alternative suggestions.

I expect the project management team (6 to 10 people) to find the right Drum Beat Deliverables and formulate them accurately. If they can't do this, they're the wrong people.

I expect the project team to find a way to complete the necessary Drum Beat Deliverables with available resources in the available time.

Since my second expectation also needs a plan, the next phase of Drum Beat planning must follow.

The Project Team Plans Its Activities

After the Drum Beat Deliverable backlog for the following Drum Beat is ready, the complete project team must be involved in planning the activities required to achieve the DBDs.

Since we're now dealing with not just a handful of people, but many hundreds or even several thousand, many planning workshops now take place in parallel.

Each work team now plans its concrete approach to completing the Drum Beat Deliverables.

The focus is now on coordinating all sub-steps with each other:

* Who needs what, when, from whom?

* What exactly is needed?

* What exactly will be done when by whom?

* Are the prerequisites available?

* If prerequisites aren't given, who can create the prerequisites?

* Which matter must be decided by whom during the Drum Beat so work can proceed without delay?

The process is organized and moderated by the project team member responsible for the respective Drum Beat Deliverable.

The line supervisors of the functional departments must be involved in this planning phase.

It's important that they know what their people have planned for the Drum Beat, what capacities are needed, and what contribution they must make.

Here again lies an emotional challenge.

The highly decorated department heads must accept that it's not in their power to question the Drum Beat Deliverables specified by the project management team. On the contrary, they're co-responsible for achieving the DBDs and thus factually accountable to the project management team.

I experience that this isn't easy for some - not to say many - top managers to accept.

Of course, the project management team is allowed to adjust its DBD backlog or individual DBDs if it realizes during planning that this makes sense. However, the decision to do this lies solely with the project management team.

Putting the Finishing Touch - in the PED

The PED (Planning Event for the Drum Beat) represents the conclusion of planning.

In the Planning Event, the result of the planning activities is formally completed and made binding.

Since very, very large project teams are involved in vehicle development projects, it's usually not possible to gather everyone in one place.

That's why it's important to very consciously select and invite participants.

The criterion is the question of which people must make the most important contribution for the next Drum Beat.

These can be project team members but also line supervisors.

The project management team is naturally always there.

The PED has a standardized process:

* The project leader communicates the overarching goal of the Drum Beat.

* Each Drum Beat responsible person briefly presents their Drum Beat Deliverable and asks if there are still open points that urgently need clarification. These points are recorded and scheduled for breakout sessions.

* In breakout sessions, the affected team members clarify the open points.

* The Drum Beat planning is formally concluded.

Now It Begins

If planning is conducted according to this process, it should no longer happen that project members question the plan, as happened to me in my first Drum Beat.

Nevertheless, not all questions are clarified and all problems solved with the PED.

For this reason, the ToDo’s written down in Drum Beat planning represent only a starting point.

From now on, all work teams look at their ToDo’s every two weeks and make the planning more concrete.

There are regular short planning meetings for this during the curse of the Drum Beat.

How working with ToDo’s in the functional departments works in detail will be examined more closely in my next article.

Do you have questions about this? 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.

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

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

For many years, I had a metric on my shopfloor board that was probably very unusual. At least I don't know any other manager who worked with this KPI.

It was the "task completion speed" – the duration until completion of tasks that my management team had put on their task list.

The primary goal wasn't to work faster. It was explicitly allowed to optimize this metric by simply taking on easier and shorter-term tasks if it contributed to finishing faster.

I must admit that this metric was the most difficult one on the entire shopfloor board. It lay like a rock on the ocean floor.

Task completion duration took forever and was more influenced by tasks becoming obsolete over time than by them being completed.

The target value remained unreachably distant, and we continued discussing progress weekly without tasks being finished.

Anyone who knows me knows that once I'm convinced of something, I have a long breath to pursue it.

This is also true for my conviction that it's helpful to focus on the short-cycle finalization of intermediate results. Therefore, I set myself the task of making this a core value of the organization.

The Drum Beat, which I introduced in the last article, aims in this direction.

It's about cleverly planning short-term milestone goals and supporting implementation through processes.

I learned something important:

It works better when intermediate goals are not set by the person affected themselves, but when they emerge in the context of joint planning.

Logically, I also set intermediate goals for myself when introducing the Drum Beat – I'll tell you more about that in one of the next articles.

In this article, I want to go into more detail about the Drum Beat Deliverable, which I will abbreviate as DBD going forward, and explain how it should be designed so that it fulfills the purpose of realizing the right short-term results.

Requirements for Drum Beat Deliverables

Let's first look at what requirements such a Drum Beat Deliverable must fulfill so that it can deliver its added value.

As Godehard Gerling (Managing Director of go3consulting) correctly formulated, a milestone goal should be selected according to two criteria.

“Plan the things that:

* Currently contribute the greatest added value to achieving the project goals.

* Will hurt us the most tomorrow if we don't take care of them right now.

The Drum Beat Deliverable must primarily ensure effectiveness. It's about doing exactly the important things at the right point in time.

For this, service providers must coordinate very precisely with service recipients about what exactly is needed.

In the planning process, the DBD should facilitate necessary coordination by providing guidance that systematically addresses all relevant questions with the team.

Throughout implementation, the DBD must help to recognize target deviations early and to find corrective actions.

For this, there must be a responsible person who coordinates necessary activities and escalates if necessary.

From these requirements, information is derived that must be documented in the Drum Beat Deliverable.

What Information Must Be Contained in a DBD?

For the Drum Beat Deliverable to be implemented safely and efficiently, it must include critical information and convey it clearly to everyone involved.

This information includes:

* Result to be achieved

* Acceptance criteria for validating the completion

* Necessary prerequisites for processing

* Information about stakeholders who will continue working with this result or who need it

* Risks that could stand in the way

* The project member who takes responsibility for implementing the Drum Beat Deliverable

* The project members involved in implementation

This information is written down in a form.

The process of filling out the form ensures that all necessary discussions take place in a structured and methodical manner.

Here's what a Drum Beat Deliverable form can look like:

I will now explain each individual point in detail.

Title

The title of the Drum Beat Deliverable must be formulated as a measurable result.

This is not easy and requires careful consideration. But it's the most important step of all.

The title must clearly state what exactly should be finished at the end of the Drum Beat, and for this, you must first be clear about what is necessary and what is possible.

The search for the right title for the DBD is the actual core of Drum Beat planning.

As a rule, all DBDs of a Drum Beat are listed in a list.

In the overview of the list, usually only the title of the Drum Beat Deliverable and its responsible person are visible.

Therefore, it's important that the title is self-explanatory.

I frequently observe that when breaking down longer-term Quality Gate Deliverables, there's a tendency to split them into smaller packages and call these Drum Beat Deliverables. (I call this the longitudinal splitting of Quality Gate Deliverables)

Take as an example the splitting of the Quality Gate Deliverable "Maturity Level B Release".

Longitudinal splitting would look like this:

* Maturity Level B Release Cab

* Maturity Level B Release Chassis

* etc.

But that's not what we want.

The idea is to divide the lengthy timeframe into bite-sized intervals, essentially creating a temporal cross-section (transversal splitting) of the Quality Gate Deliverable.

The search for these intermediate results is, especially for inexperienced project teams, a challenge.

Here's the example for the correct splitting of "Maturity Level B Release":

Drum Beat 1 – Development suppliers are selected and operational

Drum Beat 2 – First system design is completed

Drum Beat 3 – Basic function development is completed

Etc.

Now you can of course also split longitudinally in addition, and that's sometimes even practical. This way, very extensive DBDs can be reduced and responsibilities can be better assigned.

For example, you can write these DBDs for chassis and cab:

Drum Beat 1 – Development suppliers for chassis components are selected and operational

Drum Beat 1 – Development suppliers for cab components are selected and operational

Drum Beat 2 – First system design for chassis is completed

Drum Beat 2 – First system design for cab is completed

Drum Beat 3 – Basic function development for chassis is completed

Drum Beat 3 – Basic function development for cab is completed

It can go even smaller by referencing each individual sub-system. However, there's a danger that too many DBDs emerge that can no longer be overseen in terms of quantity.

Therefore, it must be evaluated with a sense of proportion how many DBDs represent the best compromise between quantity and size.

I would say that up to 20 DBDs per Drum Beat are well manageable. With more DBDs, it becomes more difficult and only works with an experienced and well-coordinated project team.

In any case, it must be ensured that not too many DBDs are assigned to each responsible person simultaneously.

If the organization is obviously overwhelmed with the number of necessary DBDs, then the project content must be reduced by stretching the project timeline.

Here, it's better to have part of the product portfolio finished quickly and deliver the rest gradually, than to have everything at once but at a later point in time.

The opinion that you can increase the quantity of achieved results by putting pressure on the project team is a widespread but fatal misjudgment.

The Responsible

This brings us to the Drum Beat Deliverable responsible person.

The Drum Beat Deliverable responsible person ensures that all involved team members work together and processing runs smoothly.

They must ensure that all necessary ToDos are planned, executed, and completed.

If problems occur, they organize support, bring teams together to identify solutions, and make decisions to re-establish flow.

As a rule, Drum Beat Deliverable responsible persons are members of the project management team.

It's also possible to select project team members, but then careful attention must be paid that taking on coordination doesn't prevent them from completing their own work.

Confidence Level

The Confidence Level shows the probability of success for completion.

If it's "High" or "Reasonable", then the project management team can trust that the project team will complete the DBD self-managed and reliably.

If it's "Moderate" or "Low", then the project management team must become active and analyze and eliminate the reasons for the low probability of success. It's a call for help from the project team.

The Confidence Level can change over the course of the Drum Beat.

If a DBD starts with "Moderate" or "Low", then measures must be implemented short-term that raise the Confidence Level to "High" or "Reasonable".

Likewise, it can happen that during processing the team's confidence becomes lower and the project management team must intervene.

Drum Beat

At this point, it's entered in which Drum Beat the Drum Beat Deliverable should be processed.

There's the possibility to also enter Drum Beat Deliverables in the Drum Beat Backlog that should be processed in a later Drum Beat.

For completed DBDs, it's documented here in which of the past Drum Beats the DBD was completed.

Recipient

This field specifies the employee or team that requires the Drum Beat Deliverable.

This information is important because it enables exchange with the right people to ensure that exactly the right and goal-oriented work is being done and no misinterpretations can lead to inefficiency and delay.

Even in internal work, it's very important to always keep the "customer" in view and be in exchange with them to ensure that the developed solution really addresses their need.

The question about the recipient also prevents activities from being completed because "that's how it's always been done". If no recipient with need can be found, then the effort is pointless and must be avoided.

QG Deliverable

The QG Deliverable informs which Quality Gate Deliverable the Drum Beat Deliverable contributes to.

Status

There are the following statuses the DBD can be in:

* Backlog

* In Planning

* In Progress

* Done

* Blocked

* Spill Over

Most are self-explanatory.

Backlog DBDs are parked for future Drum Beats.

"Blocked" is an alarm signal because it signals that processing of the DBD is halted because there's a serious problem that cannot be solved by the team itself.

"Spill Over" means that this DBD could not be completed in its Drum Beat and therefore had to be rescheduled.

Description / Intent

This space is for relevant information that is too detailed for the headline. It's important to document the reasons and dependencies that led to this DBD.

At this point, it's better to write more rather than too little. The more information from the planning phase is documented here, the more goal-oriented work can be.

Definition of Done

The Definition of Done outlines what exactly needs to be accomplished and identifies who is qualified to assess completion of the Drum Beat Deliverable.

The form in which this confirmation takes place should also be established.

* These can be reviews in which the result is evaluated.

* It can also be confirmation from the recipient or from selected experts.

* Likewise, defining an objective target value is a good Definition of Done when it's possible. For example, 100% of all planned bills of materials are released.

Definition of Ready

The Definition of Ready identifies what must be in place before processing the DBD is possible.

When all prerequisites are in place, processing of the DBD can begin, though attention must be paid throughout to ensure no decisions undermine these initial conditions.

Incomplete prerequisites affect the Confidence Level. The team must decide whether to proceed with processing anyway and if missing prerequisites can be resolved short-term.

If that's not the case, then the scope of the DBD must be adjusted. Maybe it's possible with less after all.

Under no circumstances may processing start according to the principle "hope for a miracle".

If prerequisites are not available, a decision must already be made in Drum Beat planning about how to deal with the then inevitably occurring problem.

Risks / Impediments

Potential processing risks and hurdles are examined in the Risks / Impediments section. The project's standard risk management practices are applied here with specific focus on the Drum Beat Deliverable scope.

If significant risks are recognized, they are included in project risk management and processed there.

If they are small risks, they are written down here so that attention can be paid during the course of Drum Beat Deliverable processing in case it develops worse than expected.

Participants

This section lists the key teams or team members who must contribute to the deliverable.

An Example

So much for theory.

Here's an example of how such a Drum Beat Deliverable can look like.

Do you have questions about this? 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.

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

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

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.

I can still remember it like it was yesterday.

In 2010, we launched the Mercedes Benz Atego Hybrid.

The vehicle was a full-fledged Mercedes with mass production quality. It offered 20% fuel savings in distribution traffic – a value that customers would kiss our feet for.

I was proud as a peacock: The world had never seen a truck like this. No competitor anywhere had anything like it in their lineup.

And then? Nothing. Nobody was interested in the truck.

I don't know how many were sold, but it was negligible. The project was a complete economic failure.

Why?

That's what I want to write about in this article, and of course about what I learned from it.

“I Can Develop It” Projects

Developers are creative people, and they want to develop something new – it's in their nature.

However, it's a fact that this requires an organization, money, and resources.

If a company's processes are organized so that these requirements are only available when a product development project is approved, then this inevitably leads to initiating a full product project for every new technology idea.

Employees find a way to make this happen – believe me.

As I mentioned, developers are creative people, and they also find creative ways to get the project they want.

Alliances are formed, data is gathered, presentations are made, business cases are crafted. In the end, everything looks logical and sensible.

It's not even a lie, really.

The problem is that these products have an extremely high probability of arriving at the market either too early or too late.

For this reason, it doesn't really matter how long the project takes.

Typically, “I Can Develop It” projects have a long project timeline. The technology itself must first be developed before the development of the end product – which is essentially an integration – can take place.

In these cases, the approach proposed by the VDA (German Association of the Automotive Industry) makes sense, which I briefly presented in the last newsletter article.

Not every project set up this way must lead to economic disaster, as it was the case with the Atego Hybrid.

It's not uncommon for these products to find sales.

If the developers' forecast was accurate and the markets develop as expected, it can work.

But one problem is unavoidable.

Due to the long project timeline and the unclear market developments at the start of the project, it's impossible to identify the right specifications at project launch – specifications that might perfectly meet customer needs.

This leads to these specifications being constantly adjusted during the project, which creates additional development loops that either increase project costs and resource requirements or keep pushing the deadline further back.

To make the issue even bigger, competitors who started development later may have the better product on the market.

The predicted profitability cannot be achieved, and the reason often cited is that the market environment has become so volatile. What bad luck!

It's not recognized that the way the product development project was planned is the actual cause of the problem.

“I Need This Urgently” Projects

The opposite of “I Can Develop It” projects are “I Need This Urgently” projects.

Here, the product development project is only initiated when competitors have brought new products or new product features to market that generate high customer interest. This causes customers to no longer want your own product because the competition has better offerings.

The product development time can't be fast enough.

Developers are blamed for always taking too long. With every day that the new product isn't available on the market, the company loses valuable business.

People say:

“In this volatile world, you can only survive if you develop agile, because that's supposedly the only way to deal with volatility, and competitors probably do it that way, otherwise they couldn't be so fast.”

Since it's urgent and must be done quickly, there's no time for technology development and customer use case analysis. It's best to copy the competitor's solutions and not waste time thinking.

Planning these product development projects causes the greatest economic damage.

It doesn't arise from unrealized payback, as with “I Can Develop It” projects, but from declining sales of the existing product, which can be existential.

The Smart Way to Plan Product Projects

With the types of product development project planning just discussed, the problem is that the question is asked:

“What project do we want to start now?”

But the right questions should be:

When is the market ready for the next product update?

What features and requirements are needed then?

When do we know enough to start a product development project?

To find helpful and correct answers and have such a project available on time, several steps are necessary, which I'll now explain:

Recognizing the Right Project Start Time

Unlike the two project approaches presented at the beginning, proper planning doesn't move forward from today, but begins in the future—planning backwards.

However, the problem with the future is that nobody knows it.

That's why we prefer to plan from the present—because it's the point in time we know.

The future can at best be predicted, forecasted, estimated.

And this becomes more accurate the shorter the time period.

The time between the decision for a product project and the time of its market launch must be so short that a reliable forecast of future market demand is possible.

By the way, that's also the time frame that truly matters—not the moment a developer comes up with a technology, nor the moment someone starts thinking about a project, but the point at which project goals can be defined with sufficient certainty.

I see two factors that play an essential role:

* Customers must be able to name their product preferences for the planned point in time when the new product becomes available.

* The time span is so short that competitors also cannot bring a suitable product to market faster.

This time period is certainly different depending on the industry.

In the commercial vehicle sector, I currently consider a period of 3 to 4 years optimal.

Even though pure software features can certainly be brought to market faster, it's still possible to estimate them with good forecast accuracy over a period of 3 to 4 years.

I wouldn't recommend a shorter development time than 2 years for quality assurance reasons. I'll go into this in more detail in another article.

Let's stick with product development projects that also include significant improvements in mechanics and mechatronics.

Then 3 to 4 years of project time is a major challenge.

If it's possible to forecast 3 to 4 years ahead, I wouldn't call that a volatile situation—yet even then, certain precautions are needed to ensure successful product development.

Pre-developing Technologies

How such a project can be structured in practice is something I’ll cover in more detail in an upcoming article.

Let me start by highlighting one essential point:

Technology development must be decoupled from product development.

There needs to be a process that allows technology to be developed in an “I Can Develop It” mode—without having to deliver a market-ready, mass-production product.

This process can fully embrace an agile development approach—while always keeping the question of value creation at its core.

The value in focus is not the revenue or profit, but:

What exactly must be clarified to prepare the technology for safe and efficient integration into a short, customer-focused product development project?

Exploring Future Customer Expectations

The next point aims to help customers improve the prediction quality of their future requirements.

Giving customers early access to prototypes and testing them together in real-life conditions helps sharpen their future requirements.

This form of co-creation was absolutely unthinkable in the past.

New products and especially their prototypes were kept strictly secret.

I predict that in the future it will be common to involve customers very early in the preparation of project decisions.

It’s possible that this is the very lever the European industry needs to stay ahead of Chinese rivals—if it’s recognized and used in time.

This form of collaboration has traditionally been far more established in the U.S. than in Europe.

Planning Incremental Product Improvements

Let's assume I'm right about the 3 to 4 year forecast period.

Then it's not to be expected that no new requirements or market needs will become apparent in the next 3 to 4 years that call for a product update.

Quite the opposite:

After only a year or two, evolving customer needs may already call for the next product initiative—long before the current product is launched.

In the past, this often led to shifting the goals of ongoing product development projects midstream.

The result:

Instability, delayed market launches—and ultimately, no suitable product available when it was actually needed.

That’s exactly what should be avoided.

The right approach is to complete the current product project as planned—while already launching the next project with the necessary time offset, so that the next product improvement is ready precisely when the market is ready for it.

If done right, this will lead to multiple product development projects running in parallel—something that would have been unthinkable in our industry just a few years ago.

Skipping product stages just to save budget—simply because the next step seems obvious—is not financially sound. It ignores the damage caused by the disruptions and delays that typically follow such shortcuts.

At the same time, efficiency still matters. That’s why project targets must be defined with great care—always keeping in mind that the product’s lifespan may be shorter than one would hope.

I think this article contains many thought-provoking ideas that justify deeper consideration.

So please subscribe to my newsletter so you don't miss these articles.

Got questions or feedback? I'd love to hear from you in the comments.

We can also chat about it.

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.

A -- B -- C -- D -- this is how the German Association of the Automotive Industry (VDA) designates the sample phases in product development.

The VDA defines these phases in its recommendation for maturity level assurance of new supplier parts in the product development process, to regulate cooperation between suppliers and vehicle manufacturers.

(Reference: Verband der Automobilindustrie e. V. (VDA), Quality Management Center (QMC): Reifegradabsicherung für Neuteile -- Methoden, Messkriterien, Dokumentationen. 3rd revised edition, June 2022. Berlin: Verband der Automobilindustrie e. V. ISSN 0943-9412.)

The VDA has good reasons to think carefully about cooperation between vehicle manufacturers and their suppliers.

To have safe, reliable, and fully functional vehicles in the showroom and ready for customer delivery by the set market launch date, standardized procedures and unified communication terms are not just helpful but necessary.

A vehicle isn't just any product where you can accept if something isn't quite perfect. Faulty vehicles pose a safety hazard to people and can cause potentially disastrous economic damage.

I know what I'm talking about.

During my time as development manager, I had to deal with recall actions and safety-relevant product defects -- a dubious pleasure one would gladly do without. Nevertheless, this experience proves valuable in emergencies, as you then know how to act quickly and professionally to get such problems under control.

Controlling product development through maturity levels and structuring development projects into sample phases aims to avoid quality problems in customer use and recalls.

However, the price for this careful, classical approach is a development time of ten years or more.

Despite all necessary care, such long development times are no longer sustainable today. Market demand and competitive pressure require significantly shorter timeframes to bring new, innovative vehicles to market.

I have intensively studied how to accelerate vehicle development without compromising quality in recent years.

This has resulted in a framework I call "NewPDP" -- New Product Development Process.

I will write about these approaches in upcoming articles. I hope they will be helpful not only for vehicle developers and developers at automotive suppliers, but also useful in other industries.

So please subscribe to my newsletter so you don't miss any article.

In this article, I'll start with an overview of the project phases and lay the foundation for understanding the processes that build on them.

Sample Phases in a Development Project

The term "sample phase" comes from a time when product development was heavily influenced by working with hardware.

It wasn't that long ago when computers were fed with punch cards and many problems couldn't be solved theoretically.

Even today, we can't completely avoid empirical work. This is evident from the fact that the VDA itself published a revised edition of its recommendation in 2022.

The basic approach to product development is as follows:

* Define requirements

* Find solution (design)

* Document solution

* Manufacture parts

* Build a prototype

* Test prototype

* Identify errors

* Analyze error causes

* Correct the errors

In the classical approach, this sequence is run through multiple times -- called "development loops."

With each loop, the product works better and becomes more "mature."

Since parts are manufactured, prototypes assembled, and tested in each loop, there are as many hardware development stages as development loops -- the classic "samples" that get their letter designation according to project phase.

However, these loops are the cause of long development times.

If we want to accelerate development, we need a different logic.

However, multiple phases where the product matures still make sense.

In my interpretation, the classical sequence isn't run through completely multiple times in succession, but only once. Selected problem areas are worked on and completed sequentially to keep complexity manageable during troubleshooting.

Manufacturing parts in a high-volume production process requires very high investments and costs. This makes it necessary for the product to already have high maturity at the time of investment, otherwise high change costs can occur.

As a consequence, this means development must predominantly occur without the presence of final parts.

As described initially, the VDA focuses on components and delivery scopes developed by suppliers and made available to vehicle manufacturers. However, the sample phase logic has found its way into the basic project structure of vehicle development projects through this approach.

I will explain my interpretation of the individual sample phases here, which follows the basic logic presented by the VDA in some aspects, but has a much stronger focus on accelerated development of the end product.

A-Sample Phase: Concept Development

In the A-sample phase, architectures and concepts are developed. The focus is on the fundamental design of the product.

Requirements for the newly developed product are converted into concepts, and these concepts are validated.

Typically, no hardware is used in this phase; instead, work takes place in virtual space.

To start the A-sample phase, the following information must be available:

* Project goals (costs, time, and performance requirements)

* The predecessor product and its performance characteristics

* Pre-developed new, innovative technologies

* Technical specifications of key components (space requirements, calculation models, performance characteristics, integration requirements, etc.)

As a result of the A-sample phase, the following outcomes are available:

* The dimensional concept is established

* Product modularity, and variance are worked out

* Installation spaces, part and component positions are defined

* System requirements are broken down and system interfaces defined

* Development goals for components and parts are established

* Software and mechatronics architecture are fixed

* Communication protocols, features, and functions are defined and assigned

At the end of the A-sample phase, it must be ensured that the product concept, as defined, can fundamentally function and contains no unsolvable tasks.

This also includes ensuring that the conceptually established technologies are well enough understood that they can be brought to series readiness.

To clarify this aspect, it may occasionally make sense to test such technology in hardware. Normally, however, this should already have been done earlier as part of a pre-development project.

The actual A-sample is a virtual prototype consisting of:

* Carryover parts and components from the predecessor product

* Space envelope models of parts and components to be developed

* Concept models of parts and components

Concept validation occurs on these virtual prototypes using CAD and CAE.

In the A-sample phase, Systems Engineering is a focus, so that in addition to space envelope models, System Engineering Models are also created and used.

Should it be necessary to manufacture and measure or test hardware for concept validation, this is done manually with minimal use of tools and fixtures. However, the functionality of prototype parts must enable assessment of concept suitability.

At the end of the A-sample phase, the development goal is clear and feasibility is validated.

B-Sample Phase: Function Development

In the B-sample phase, systems and components are developed. The focus is on the functionality and performance of the product.

Now it gets concrete.

Based on the A-sample phase results, the completely functional product is now created, which theoretically achieves all project goals.

Unlike the VDA proposal, I don't have "the" B-sample.

Here we have a special feature in my approach that differs significantly from the VDA approach.

The B-sample phase begins with the A-sample, which continuously evolves during the B-sample phase and is documented as the C-sample at the end of the B-sample phase.

It's somewhat odd that a change in process logic occurs here. The result of the A-sample phase is the A-sample. However, the result of the B-sample phase is not the B-sample, but the release of the C-sample.

You can think of it this way: the large development loops from the VDA approach take place as micro-loops within the B-sample phase.

This phase is characterized by iterative development steps that lead to the final product design.

Because relatively little time is usually available, as many scopes as possible must be developed using theoretical approaches and calculation tools.

Where working with hardware prototypes is unavoidable, these are manufactured very pragmatically oriented to concrete development needs, with minimal time and cost expenditure.

The B-sample is a virtual prototype that continuously evolves throughout the entire B-sample phase.

For development tasks requiring hardware prototypes, "mules" are used. These are physical vehicles equipped only sectionally with hardware B-sample parts. The scope of B-sample parts is tailored to the concrete development task.

At the conclusion of the B-sample phase, all product, system, and part specifications are established and there are no more open questions or problems.

The end of the B-sample phase is also an important milestone for suppliers, because now the requirements and execution details of their delivery scopes are completely described.

To explain it clearly, I like to use the comparison with a school exam:

At the end of the B-sample phase, paper and pencil are collected, the exam is over.

The teacher's correction of the work is now comparable to the C-sample phase.

Software represents a special case.

Since software doesn't require high investments in production equipment, software functions can also be developed later. However, this only applies to functions that have no influence on product hardware validation.

C-Sample Phase: Reliability Verification

In the C-sample phase, the reliability and durability of the new product are validated. The focus is on searching for development-induced quality defects.

In this phase, proof is now provided that reality really matches theory and no errors or misjudgments have occurred.

For this, complete, representative, physical prototypes are needed.

For this reason, the beginning of the C-sample phase involves manufacturing product prototypes that exhibit all project change scopes in their interaction and full functionality.

The danger is still great that problems will be recognized in this phase. Therefore, the change effort for necessary design modifications must be kept minimal. However, the prototypes must represent the state of the later series product as well as possible.

Two different methods are typically used for part manufacturing:

* Relatively cost-effective prototype production methods are applied. The compromise lies in the possible production quantity. With these methods, usually only a small quantity can be manufactured.

* Preliminary stages of later series production equipment, combined with higher manual manufacturing effort, are used to manufacture the prototypes.

The number of C-samples depends on the requirements for statistical validation of change scopes. This is a big topic that I will address in separate articles.

I must say it feels very unusual when the entire project team should pause until prototype parts are manufactured and prototypes assembled.

This somehow feels inefficient. But it's not!

Validation is only meaningful and informative when what is validated is also manufactured exactly that way. Design changes are prohibited until concrete errors are recognized and analyzed. These may be corrected through changes.

Software is again an exception here. During the time hardware is procured and C-samples manufactured, additional software functions may be developed.

Once C-samples are available in hardware, product validation in theory and practice begins.

The C-sample phase ends with the decision to make investments in series tools and series manufacturing equipment. This is formally expressed through D-sample release.

Now it must be clear that nothing more can go wrong and the product functions as required.

D-Sample Phase: Series Capability Verification

In the D-sample phase, the series suitability of the product is validated. The focus is on series production-induced quality defects.

Similar to the C-sample phase, the D-sample phase also starts with creating D-samples.

D-samples are characterized by corresponding to the series manufacturing state because they were manufactured in the series manufacturing process.

Why is this needed at all?

Hardware has the characteristic that manufacturing methods can have a significant influence on part properties.

The size and type of influence strongly depends on the manufacturing method and chosen prototype method.

If this interests you, write it in the comments, then I'll write more about this topic.

The D-samples themselves emerge so late that testing can usually only take place alongside series production.

It's quite reasonable to consider this, as it offers the advantage that possible problems are found before they occur at the customer, and thus prophylactic error correction possibilities still exist.

Another special characteristic of hardware is that the error occurrence probability follows a bathtub curve. Errors don't all appear immediately. Particularly impairments in operational strength only appear after some time in use. So there's still time to fix the error before it occurs.

I can also go into more detail on this topic if it interests you. So write it in the comments.

For parts and components, an A/B test is performed on test stands, checking whether the D-sample part exhibits the same properties as the C-sample part, which was tested in the overall system.

At the end of the D-sample phase stands series release, often also a Chief Engineer release, which approves the product for sale and customer use.

Sample Phases Overview

Let's return to the development sequence presented at the beginning.

Unlike the classical approach, in the NewPDP approach the sample phases don't designate development loops where the development sequence is completely run through.

They bracket segments of the development sequence and define which aspects of product development are focused on in the respective phase.

With that, I'll conclude today's overview of the development phases of vehicle development.

I will certainly go into more detail on each phase in separate articles and also present the concept of maturity levels.

Maturity levels are very closely connected to sample phases.

I'm aware that this subject matter is very specialized, so I'm very interested to know whether this information is helpful to you.

Please give me feedback on this!

Please also write in the comments which aspects I should go into more detail on in upcoming articles.

We can also chat about it.

Don't forget to subscribe to my newsletter so you don't miss any of the upcoming articles.

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.

Plans are only perfect until they meet reality. No plan survives contact with the real world.

Experienced project teams understand this reality and prepare for deviations in advance, enabling quick course corrections through targeted countermeasures.

The method for doing this is risk management, and it's actually not that difficult.

Nevertheless, I regularly observe how projects get into trouble because risk management is inadequate, as it costs time and is exhausting.

As Chief of Overall Vehicle Development, I made it a priority to regularly review project risk portfolios, always ensuring that all project managers were present to share their assessments with me and their colleagues.

This demonstrates just how critical I believe risk management is.

I gained valuable experience during this time, which I'd like to share with you here.

The Difference Between Risk and Problem

A problem is an unwanted deviation of the current actual state from the necessary target state that prevents the project from achieving its goals.

Every problem requires a solution.

Basically, there are two alternatives for how problems can be solved:

* The goals will be adjusted so that they are achievable again based on the current actual state.

* A new plan will be developed based on the current actual state that leads back to the agreed-upon goals. This usually requires additional activities and resources, which may impact project costs and timeline. This alternative typically requires buffers to be built into the project goals to absorb these additional efforts.

A problem is therefore characterized by the fact that it has occurred and the project team must deal with the consequences, and that the consequences are always unpleasant.

A risk is a potential problem that could occur in the future.

Here too, there are two alternatives for dealing with risks:

* Monitor the risk to see if it occurs and becomes a problem, while preparing a plan for how the problem would then be solved. This reduces the time delay caused by the problem, as the problem analysis time is brought forward and takes place in parallel to the project timeline. A risk buffer is established on the budget side to ensure that funding for the solution is available if the problem potentially occurs.

* Measures are identified and implemented to minimize the probability of the risk materializing.

With so many alternatives available, we need to examine how risk management works in detail to ensure we always choose the right approach.

Identifying Risks

Risk management always starts with identifying the risks.

Since risks represent potential problems, they must be formulated as problem.

This brings me to the first challenge that must be mastered.

A typical error is describing risks not as problems, but rather recording potential causes or corrective measures as risks.

What do I mean by this? Let me illustrate this with an example:

"I don't have enough time to develop the bracket." - This is not a problem description, but a possible cause of a problem.

"I need more time to develop the bracket." - This is not a problem description, but a possible countermeasure.

"The bracket breaks before it has reached the required service life." - This is a problem description.

It is extremely important to describe the problem correctly because confusing the problem, cause, and measure makes evaluation more difficult and restricts the solution space.

Please make sure that the risk is always described as a problem!

But how do you find the potential problems?

The answer may surprise you now:

By actively searching for the risks!

This is where the project management team, especially the project manager, comes into play.

The project manager must strive to identify all risks in their project, requiring the entire team to systematically search for potential risks.

This includes:

* Analysis of lessons learned from past projects

* Interviews with subject matter experts

* Risk workshops in which the project team reflects on the project plan and examines it for risks

* The use of quality management methods (e.g., FMEA)

* And of course, the experience and expertise of the project team itself

Do you have other alternatives for how risks can be found? Then please write them in the comments!

Evaluating Risks

Once risks are identified, they must be evaluated to determine appropriate response strategies.

The evaluation takes place in a portfolio with two dimensions.

One dimension is the Probability of Occurrence.

Is it likely that the risk will become a problem, or is it rather unlikely?

To classify this, experience is often used.

Risks that have frequently actually become a problem in the past naturally have a higher probability of occurring in the current project than risks that have never occurred in the past.

Especially with technical matters, the probability of occurrence is often objectively assessable.

For example, if the stresses in a component are close to the load capacity of the material, the probability of occurrence of a fracture is significantly greater than if there is a large distance between load and load capacity.

The second dimension is the Severity of Impact.

How bad is the damage caused by the occurrence of the risk?

Is there danger to personal safety or great economic damage? Or are the effects marginal and do not cause great damage?

In this context, it is also important to find out which risks may not be risks at all.

It may be that the plan does not really proceed as intended, but this does not result in consequences for the project goals. In this case, it is then a potential plan deviation but not a risk, and this can be acceptable.

I recommend using Low, Medium, and High categories. More granular risk classifications exist, but they tend to complicate the process without offering substantial benefits.

Each identified risk is entered into one or, for the sake of clarity, into several risk portfolio representations.

A risk's position in the portfolio indicates the appropriate response strategy.

* If the probability of occurrence and the impact are low, then this risk is usually monitored further without initiating concrete activities.

* If the probability of occurrence is low but the severity of the impact is high, or if the probability of occurrence is high but the impact is low, a mitigation plan is usually created for how the problem can be solved if it does occur, or what target deviation can be accepted.

* However, safety risks represent an exceptional case. Safety risks must be excluded from the outset, even if the probability of occurrence is low.

* If, on the other hand, the probability of occurrence and the severity of impact are high, measures are defined and immediately initiated to reduce the probability of occurrence and/or the severity of impact.

Defining Mitigation Measures

Once the risks are identified and evaluated, adequate risk mitigation measures must be determined.

To find targeted measures, it is necessary to first become clear about the potential problem causes.

Anyone who defines measures without identifying the root cause is shooting in the dark and cannot be sure that the measures will actually solve or prevent the problem.

I know it's not written like this in most textbooks, but the master teacher “Practice” has painfully taught me this lesson.

The search for potential root causes and the development of targeted countermeasures must be conducted with great methodical care. It helps if the Project Management Master is trained in this methodology and keeps a watchful eye on the process.

If the risk is to be mitigated, the measures must be immediately incorporated into the planning.

If they are only intended for emergency situations where the risk materializes, they remain in the risk management list.

Let's follow this through with an example.

We see here the risk that the tank mount of our new truck might not meet the test requirements.

Experience tells us that the tank mount of our new truck will probably not survive the tests.

The probability of occurrence is high because tank mounts have regularly failed to pass tests on the first attempt in previous projects.

The severity of impact is medium because the tank has multiple mounts, and there is a high probability that the workshop will detect any damage during routine inspections before the tank detaches from the vehicle. However, extended workshop visits are both inconvenient and expensive for customers, especially when trucks are kept off the road longer than necessary.

We have evaluated the risk and put the Risk Number in the corresponding field of the risk portfolio.

The field is red, suggesting, we should do something immediately.

But what do we do about it now?

To find effective countermeasures, we must investigate what the possible root causes of failing the test could be.

With some effort and research, we found out that there were two causes in the past.

* During the manufacturing process, the material properties deteriorate, weakening the part so that it fails to achieve the predicted durability.

* To minimize vehicle weight and material costs, this part is designed to operate right at the edge of its stress limits. In the past, however, the tolerances in the load capacity of the material have been so large that the durability requirement was not always reliably met.

Having identified the possible root causes of failure, we can now define appropriate countermeasures.

Let's assume there is no other way to determine if the part is weakened during production than to manufacture the parts and perform the test. Then the only remaining measure is to schedule the test so that, in case of failure, there is still time for another optimization loop before the entire project timeline is jeopardized. The part must therefore be prioritized in the development sequence and processed first.

Given the tight stress margins, using thicker material from the start makes sense. The added weight and cost of slightly thicker sheet metal are minimal compared to potential project delays and field repair costs. We'll therefore reduce the probability of occurrence of this failure mode by increasing material thickness.

We have now identified two possible causes for one risk and defined a countermeasure for each cause that should be implemented immediately. This allows us to reassess the risk and reclassify it in the risk portfolio.

The risk moved from the red box to a yellow box.

This is because we only addressed the probability, not the severity of impact. If the risk still occurs despite our measures, the consequences would be just as severe.

If we feel comfortable about this status, we would put the risk now on monitoring.

If not, we would need to identify additional measures to reduce impact severity, such as changing the design so that it can be repaired in no time and at no cost.

I hope these explanations have motivated you to put risk management high on your agenda as an important aspect of project management.

If you are a project manager or team member, please integrate risk management and risk workshops into your project planning. Take time to actively identify risks, evaluate them thoroughly, define effective measures, and ensure their implementation.

If you are a project sponsor, ensure you receive regular updates on high-risk issues and share accountability with the team for addressing them.

Eliminating all risks is impossible—we must be realistic about this.

Residual risks will always remain, requiring shared ownership between the project team and the company’s management.

Being assured that careful risk management has been applied makes this shared responsibility easier to bear.

What does risk management look like in your organization? I'd be fascinated to learn from your experience—please share in the comments, or let's have a chat about it.

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!

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

In this article, I would like to introduce the last important role in the project management team and explain why it makes sense to invest the necessary capacity in this role.

The Project Organization

Whenever a new large project starts, the same question always arises:

Can we set up a project house for the project where all the people working on this project sit together in one large area, communicate directly with each other every day, and work exclusively on this one project?

And every time we come to the same conclusion:

It would be good and make sense, but somehow it's not possible.

* We don't have space where several hundred people can fit.

* Many activities can only be carried out in a specific place that is not in the project house, for example, testing and validation.

* Most people must also work on other projects simultaneously.

* We have competencies at international locations, and it would be too costly to relocate all the people to one location.

* People have strong communication needs in their functional area with colleagues who are not on the project.

* And last but not least, the disciplinary supervisors also like to have their people with them to stay informed about what's happening in their area of responsibility within the project.

So it always comes down to a compromise. At best, only part of the team is permanently present in the project house.

Now the question arises: how can the project structure be designed so that integrated collaboration is definitely achieved, even if not everyone is always together in one place and can permanently exchange ideas with each other?

But let's assume we would really manage to gather several hundred people in a project house. Would they really organize themselves completely on their own without organizational support?

I believe even then it would require a project structure that focuses exactly on this and explicitly ensures that everyone understands exactly what needs to be done, actually does it, and that the work results of individual employees are available on time, integrated, and of the required quality.

What does the solution look like then?

In an automotive company, we usually find a functional organization where employees of the functional areas are locally concentrated.

The functional areas have an organizational model and a communication model that help the managers of the functional areas lead their employees both professionally and disciplinary.

I think it's organized similarly in many other industrial sectors.

The structures in the functional areas can and should be used for project work.

The role that has the task of organizing project work in the functional areas and ensuring cross-functional coordination is the Functional Unit Representative.

The Functional Unit Representative (FUR)

The Functional Unit Representatives are employees dedicated to the project who control and coordinate all project-specific functional area activities.

I deliberately speak in the plural because logically, there should be at least as many Functional Unit Representatives as there are relevant functional areas involved in the project.

Each Functional Unit Representative is part of the project management team and is both professionally and organizationally capable of representing the employees of their functional area in the project management team.

At the same time, they are the representative of the project management team in the functional area, steering the project's interests into the functional area and ensuring processing.

With this task assignment, the question automatically arises whether the Functional Unit Representative is actually just a mail carrier between the functional area and the project. Are they the paralyzing layer that isolates the working workforce from the project manager?

No, absolutely not!

They are project leaders in the functional area, factually leading a project house within the functional area.

They are close confidants and right-hand people of the functional area leadership and enable them to fulfill their leadership responsibility.

While the project manager themselves is a generalist across all functional areas and has the competence to plan, control, and make decisions across all functional areas. The Functional Unit Representative is a specialist who knows their area of responsibility excellently. He is a competent contact person for the employees in this area.

They represent the functional area and bring professionally qualified input into the project management work at the project level.

What distinguishes them from a mail carrier is that they make decisions and give instructions to employees.

And that's exactly the Achilles' heel that this role has in real project work.

The employees and managers of the functional area must accept that the Functional Unit Representative is the central contact person who controls the activities. They may not be bypassed when it's inconvenient, and one can't handle their tasks.

At the same time, however, the Functional Unit Representative must not shy away from responsibility just because they don't know everything.

The Functional Unit Representative must have the unrestricted trust of the project management team, the functional area employees, and the functional area managers.

For this reason, an extensive network and a solid amount of experience in the represented function are necessary for this task.

According to the principle already presented in other articles:

The project controls, the line function delivers

The Functional Unit Representative has the control task within the functional area.

They ensure that quality gates, project milestones, project increments, and sprints are broken down, planned, and communicated to functional area employees according to the necessities of the project.

They support internal functional area and cross-functional coordination, prioritize deliverables and activities, and coordinate the consequences of this prioritization in the project management team with other Functional Unit Representatives, the project manager, the project management master, and the project architect.

The Functional Area

In a company where projects are processed in a matrix organization setup, each functional area must therefore have a sufficiently large number of employees who can perform these tasks.

And since they don't grow on trees, it's the task of functional units management to systematically train these employees and maintain them in the functional area's capacity planning.

Furthermore, it's necessary to give functional area representatives the necessary attention in the functional area.

They have the competence to schedule project meetings in the functional area where attendance is mandatory. Even if employees are not dedicatedly released for the respective project, participation in their project meetings is not a wish-for-whatever event.

You might think: Why does he write this? It's absolutely logical and self-evident! You don't have to tell anyone that.

If it really is self-evident in your organization, then I can only congratulate you on the company. In my experience, it's usually not self-evident at all and requires an explicitly expressed and sustained commitment from functional unit managers to ensure this.

Furthermore, functional unit managers must take the time to listen to the Functional Unit Representative and contribute their share to fulfilling project results and project goals.

The Project Structure

The project structure now looks as follows:

We see here a matrix organization. The Functional Unit Representative is the only role involved in all dimensions.

They are thus factually the pivot point of the matrix organization in the product project.

I cannot emphasize enough how important this role, often somewhat undervalued, is in a large project.

Therefore, I would also like to express my thanks to all Functional Unit Representatives at this point and hope that as many people as possible read this article and treat the Functional Unit Representative with appropriate attention and appreciation.

So, please share this article in your organization and encourage people to take the time to read it.

To make it a bit more complicated at the end, I don't want to hide from you that Functional Unit Representatives can even exist at multiple levels.

This was the case in the projects where I was active, where the project was organized into functional area-oriented subprojects.

This then means that there are subproject managers for development, purchasing, production, etc. These then have Functional Unit Representatives in their subproject management team who control further functional structures within the respective functional area.

I definitely don't want to claim that this organizational form is the best way to organize a large project with several hundred to several thousand project participants. Nevertheless, it should be recognized that in this structure, the subproject managers take on the role of a Functional Unit Representative.

I need to mention this because there's also the possibility of dividing a project into subprojects that develop separate product segments and where the subprojects don't follow functional logic. In that case, the subproject managers are not Functional Unit Representatives and have another role.

That's it for today. Please write your opinion about the role of the Functional Unit Representative in the comments. Does it exist in your organization? Do you have experience with this role?

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!

The project manager is responsible for achieving project goals—that much is undisputed. But does this responsibility also extend to ensuring that:

* A high-quality product is developed?

* All technical teams collaborate closely?

* Necessary technical compromises are balanced and decided in alignment with brand promises?

* Product quality remains high, and competitiveness is maintained?

* Product design is executed efficiently and strategically for the future?

* The right technologies—mature yet innovative—are applied and their benefits fully realized?

* Components and systems are arranged for cost-effectiveness and optimal manufacturing?

These questions come up repeatedly in my discussions with project managers, project stakeholders, and team members in automotive development projects.

The situation becomes particularly controversial in our setup, where we have not only the actual project manager but also a manager for the product development sub-project. All within a matrix organization where the actual development work is performed in line departments with their own area responsibilities.

There's rarely a consensus on how these responsibilities should be allocated. That's why I want to describe both the collaboration and division of labor among the three roles that, in my experience, must be present in every project.

The Project Manager (Development Project Manager)

There are tree main types of project managers I encounter:

The Professional Project Managers have completed project management training and excel at project management.

When it comes to product responsibility, they say:

“I simply can't do that—I don't have the necessary qualifications. For this aspect, I need professional developers on my project team.”

The Hardcore Developers (like I was and still am) who are assigned project management roles.

When it comes to product responsibility, they say:

“Of course, I'll take responsibility. Why should I let others do something I can do well myself? I can handle that bit of project management on the side.”

There's also a third category: the Wannabe Developers who pursue project management roles because they want to have a say in how the product should look.

These individuals tend to interfere in development matters but aren't taken seriously by development teams.

You can probably guess where my recommendation is heading.

Project managers, or development project managers when they exist separately, are responsible for ensuring that all development activities are planned and executed on schedule. They're also responsible for facilitating product decisions when these are relevant to achieving project goals and exceed the product architect's scope of competence.

The technical responsibility for product design lies with the other two institutions I'll discuss in detail.

Let me briefly explain why the second and third scenarios aren't advisable.

Even project managers with strong technical product competence must give project management top priority.

If they do this properly, they simply don't have time to take on technical product responsibility—someone else must handle that.

However, technically competent project managers do have a significant advantage: they can recognize decision requirements from a distance and assess product maturity in relation to the required project progress based on their own expertise, planning necessary interventions in time.

For them, the challenge is “merely” shedding their old developer role and focusing on their new role as project manager.

The situation is more difficult for wannabe developers. In my experience, these cases require very resilient Project Management Masters who can provide necessary guidance when the project manager inappropriately interferes in development work.

Chief Engineer

The Chief Engineer is the supreme technical authority in the company and is legally personally responsible for product safety.

The Chief Engineer bears responsibility for:

* Ensuring development work is conducted according to current technical standards with appropriate diligence

* Ensuring the development organization is professionally and capacity-wise equipped for the project challenges

* Ensuring all necessary professional and legal processes are defined, documented, and trained

* Ensuring these processes are applied in every project

The Chief Engineer isn't a project team member but rather a project sponsor, even though they must play an active role in the project.

To fulfill this weighty responsibility, the Chief Engineer (who often carries the CTO title today) must regularly receive reports on product maturity progress in ongoing projects. When necessary, they must make timely and competent product decisions and formally issue Chief Engineer approval at project completion.

This Chief Engineer's approval signals that product maturity is sufficient for customer delivery, confirming that it poses no danger to people and the environment and doesn't compromise the company's financial stability.

The Chief Engineer is, therefore, a high-ranking executive and typically a member of the company's management board.

This presents the greatest challenge I frequently observe in practice:

Chief Engineers have so much on their plates with all the projects and other management responsibilities that they don't invest the necessary time and care to truly fulfill their role and responsibility in each individual product development project.

Yes, things often work out anyway. But I advise every Chief Engineer to take the time to carefully prepare for project milestones and quality gates, focusing on necessary adjustments in the development organization.

It's better to tell the CEO you can't attend a management meeting because you need to focus on an important project than to leave the project management team alone when they urgently need the Chief Engineer's help and support.

You might sense where this is going.

Behaving this way isn't necessarily easy, which tempts some Chief Engineers to delegate their responsibility to the project managers, allowing them to focus more on their boss and be available to them.

People, grow up! You're top managers—don't forget that. You can't always take the path of least resistance.

Product Architect

The Product Architect is comparable to an orchestra conductor, whose task is to create a harmonious musical piece from many individual voices.

The Product Architect integrates all technical disciplines into a unified product.

They bear responsibility for:

* Ensuring the product has inherent logic and structure.

* Defining product requirements and breaking down the contributions of individual components and systems to their fulfillment.

* Developing and establishing the architecture of the overall system and subsystems, ensuring implementation during product development.

* Coordinating and validating technical interfaces at the boundaries of functionally organized development areas.

* Ensuring modularity and platform rules are considered in product design.

* Harmonizing specified product properties and customer requirements, considering them in technical solution definitions.

There can be differing opinions on whether Product Architects should be organized as dedicated project resources or as cross-project line functions.

In my opinion, this strongly depends on the product type.

When developing a singular product, the Product Architect should be a dedicated resource for that specific project.

However, multiple product projects often work on a modular product platform, developing specific platform segments. In these cases, it's better to organize Product Architects as line functions that maintain an overview across all projects and hold the platform together.

Typically, one person isn't sufficient—specialized teams are necessary to provide the required capacity for each project.

When discussing the Product Architect's role, I must necessarily address Systems Engineering. The Systems Engineering methodology provides the toolkit that enables Product Architects to fulfill their tasks.

I consider it extremely important to extract Systems Engineering from the mechatronics corner.

Regardless of the product type, the product that customers buy and use is the system relevant to them. Therefore, Product Architects must start there and perform product synthesis at this level.

The responsibilities of Development Project Managers and Product Architects overlap in that both manage the project’s development team—Development Project Managers regarding development workflow, and Product Architects regarding technical product synthesis.

This naturally leads to the assumption that one person could handle both roles, reducing stakeholder contact points (especially for Chief Engineers) and saving personnel costs.

Don't do it! This leads to a lack of focus, and at least one aspect—workflow or content, probably both—will suffer.

The Project Leadership Trinity

In previous articles, I discussed Project Managers and Project Management Masters. In this article, I've added Chief Engineers and Product Architects.

You might now wonder how large a project team should be, according to my opinion.

With the Project Manager, Project Management Master, and Product Architect, I've described the three essential roles that should exist in every major project.

When dealing with matrix organizations as described in the last article, another role comes into play, which I'll describe in the next article.

So, stay tuned and subscribe to my newsletter so you don't miss that article.

That’s it for today. In further articles, I will go into detail about the roles and organizational structures required to do product development successfully.

If you have questions or recommendations, please write in the comments, or let’s chat.

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

* Is your organization still small enough that everyone knows each other?

* Is your product still so simple that every team member understands it inside and out?

Then, teamwork is easy to organize.

You come together, discuss what needs to be done, and do it.

However, successful companies grow, and inevitably, a point comes where the group becomes too large and the product too complicated for this simple approach.

Now you must change how you collaborate because the simple way is no longer viable.

Today, I will discuss an approach that is very widespread but also highly controversial.

It is the Matrix Organization.

On the one hand, it has been used in many large and successful organizations for a long time.

On the other hand, people often complain that this organization creates unclear responsibilities, excessive communication channels, and high inefficiencies.

So let's look at what advantages a matrix organization offers and how to avoid the disadvantages.

Which problem needs to be solved?

Developing a product requires many different skills. These skills are brought to the team by appropriately qualified employees.

* There's an expert for purchasing services,

* an expert in selling the product,

* and the developer who knows how to design a product that fulfills the required functions and works reliably,

* and so on... – You understand the concept.

In a product development project, all these people with their individual skills must work together to create a common result in the form of a new or further developed product.

This creates the need to organize the collaboration of these groups of people, to establish individual responsibilities, and to coordinate the distribution of tasks.

The form in which this is organized is called "Process Organization" because the purpose of this organizational form is to control the workflow.

The Project Organization, with its roles and rules, which I describe in many articles in my newsletter, is a form of Process Organization.

This is how it usually starts:

There's someone who has a product vision, and the first thing he does is look for allies with the most urgent skills to make the product happen. That's what we call a startup.

This organization grows over time with success and reaches a size where expertise is no longer represented by just one or a few employees. Suddenly, many employees are working in the same field of competence.

Now we suddenly have the problem of coordinating people with the same skills.

Groups need to agree on the application and development of their common skills. Competence-specific strategies must be developed and operationally implemented with careful planning and execution to ensure effectiveness.

Things often go wrong at that point because there is a lack of expertise in what the right target organization should look like.

Here are some examples of competence-related strategies that require careful consideration, as they affect the future of the entire company, not just a single project.

* A purchasing strategy describes which suppliers to work with and how to negotiate favorable prices.

* A product strategy describes how the product should evolve to meet customer requirements and market conditions over the long term.

* A development strategy describes which technologies are suitable for future products and therefore need to be understood and prepared.

* An after-sales strategy outlines the processes that support the customer during product use and help maintain their loyalty to the company.

* etc.

For this to be successful, responsibilities need a clear definition, and tasks must be appropriately distributed.

One of how this can be done is through a Functional Organization.

In Functional Organizations, responsibilities are mapped to organizational units. You can learn more about the Functional Organization in my blog article on my website.

The Matrix Organization

We have two different aspects that need to be organized simultaneously.

* Regulating responsibilities and tasks regarding the process of product development. —> Project Organization

* Regulating responsibilities and tasks regarding the development and application of expertise. —> Functional Organization

Both affect the same employees!

So there are two dimensions that the employee must satisfy.

The mathematically educated reader will easily understand that a two-dimensional problem can be represented as a matrix.

Hence the term "Matrix Organization."

Properties of a Matrix Organization

Unlike in a one-dimensional line organization, in a matrix organization, the employee has two management relationships.

He receives tasks and goals from both the project manager and the functional manager, and must be accountable to both.

The two dimensions of a matrix have equal priority for the employee. This means he must satisfy both aspects simultaneously.

To make it clear and explicit:

In a Matrix Organization, the managers each focus on one dimension, while the employee, as an integrator, must account for both dimensions with a common solution.

So far, so good. This is still relatively simple.

But there's still one question to answer:

Who takes care of personnel management in a matrix organization?

So, who is responsible for supporting the employees when help is needed, evaluating their performance, making decisions about their development and compensation, and resolving conflicts between employees, etc.?

Ideally, one could use another management level for this third dimension in the matrix organization.

Typically, this is not done because there is reluctance to invest in so many managers. As a result, one of the two existing management dimensions is assigned personnel management in a dual role.

This makes sense in theory and is feasible, but in practice causes a serious methodological problem.

The manager who has been given personnel management competence automatically gains more weight than the manager who doesn't have it.

The equal status of project and functional organization is no longer maintained when personnel management is assigned to one of the two dimensions, although this should be a fundamental principle.

Matrix Organization with Increased Complexity

In the matrix organization described so far, employees are clearly assigned to one specific functional area and one specific project.

This is only feasible if there are enough employees with each skill set to support all projects, and if the workload in each functional area and project is sufficient to occupy a full-time employee.

In today's times of ever-increasing specialization, this is often not the case, which means that employees are involved in several projects simultaneously.

As a consequence, an employee no longer has just two management relationships, one of which has an unjustified primacy, but rather a multitude of management relationships.

At this point, it should be clear that the matrix organization, particularly its more complex form, is often perceived as complicated and difficult to manage for a good reason.

Therefore, it is essential to establish rules that simplify the complexity and bring it back to a manageable level.

Managing a Matrix Organization

Clear Assignment of Responsibility

The responsibility assignment mentioned above is not clear enough to offer adequate guidance to employees and managers within the organization.

It is important to define responsibilities more precisely and transparently, particularly since the project manager rarely holds personnel management responsibility for the employees.

Therefore, the assignment of responsibility needs to be clarified.

Project Organization Steers — Functional Organization Delivers

This simple and easily understandable management principle highlights the core reason for the existence of the matrix organization.

The project organization is a process organization, so it makes sense to hold the managers within the project organization accountable for ensuring smooth operations.

The functional organization is responsible for the expertise, which is essential for producing high-quality work. Therefore, it should also be accountable for applying these skills and delivering the results.

However, this division of responsibility removes an important aspect of the project manager's role. After all, project managers are responsible for achieving the project goals.

This is the point that causes the most confusion in practice. Many project participants and stakeholders fail to realize that in a matrix organization, the project manager's holistic responsibility no longer exists.

So, who ensures that both dimensions truly fulfill their responsibilities?

The answer is simple:

The manager to whom both the project manager and the functional managers report is responsible.

If there is no special regulation in a company, then it is necessarily the CEO.

But of course, he can delegate this responsibility, which he will usually do.

But please don't delegate this responsibility to the Project Manager! Instead, identify a senior manager with the necessary skills to understand both dimensions of the matrix.

If the company culture supports Matrix Organization Thinking, it will not be a full-time job.

Clear Escalation Rules

Clearly defined escalation rules help operationally reinforce this shared responsibility.

Escalation rules are scenario descriptions that guide employees on which problems should follow which escalation path.

Give examples for:

* Which issues should be addressed with my functionally responsible superior?

* Which issues should be directed to the project manager?

Temporary Focus

To reduce the many reporting relationships in the complex matrix organization model, I recommend dividing the employees involved in the project into three categories.

* Employees who are dedicated to a specific project and work solely on it from start to finish.

* Employees who are assigned to a specific project for a set period, which may range from a few days to weeks or months. The key is that, at any given time, their work focuses exclusively on one project, even if the project changes in short cycles.

* Employees who contribute only a small portion of their time to a project and are available on call as needed.

By introducing time as a dimension, the number of management relationships at any given moment can be reduced, making performance management easier. However, this approach requires precise control over project processes.

Lean Project Organization

To avoid compensating for poor performance in functional areas by duplicating skills in the project organization, the project organization must be very lean.

Employees in the project organization should focus exclusively on project management tasks, while those responsible for delivering results should remain in the functional organization.

It's not uncommon for me to observe the attitude:

“Before explaining to the functional department what they should do, I might as well handle it myself quickly.”

This is tempting, of course, especially for tasks that require rather general or perhaps minor skills.

I advise against this approach, as it undermines the overall control model, creating room for misunderstandings and misinterpretations of responsibilities. This can lead to unfinished project tasks elsewhere, with potentially significant consequences for project success.

That’s it for today — the basics and key rules for working with and within a Matrix Organization.

Of course, there are still many specific and more detailed responsibilities that should be derived from this foundational control logic.

In further articles, I will go into detail about the roles and organizational structures required for this.

So, please subscribe to my newsletter to ensure you don’t miss these articles.

If you have questions or recommendations, please write in the comments, or let’s chat.

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

In classic project management, the Project Manager is a superhero.

He is the general responsible person, responsible for everything that happens in the project, including delegating responsibilities and tasks to a team, which he usually cannot choose himself, and ensuring that everything gets done.

This sounds logical and is convenient and clear for everyone.

The project stakeholder has the same contact person for every concern, and if something doesn't work, the same person is always to blame.

For the project manager himself, it also feels good.

He has unlimited power in the project, can instruct and delegate, and doesn't have to report to anyone except the stakeholders. The feeling: "It's my project!" feels quite good.

I've been in both roles, stakeholder and project manager, so I know what I'm talking about.

It's from this experience that I have learned that this concept is the reason for the failure of many projects.

The project manager is a jack-of-all-trades; he has to do everything and therefore has no time to do any of it right. He rushes from problem to problem and is so busy dealing with problems that he doesn't have time to make sure that new problems don't arise.

He delegates because of time constraints, and because of all the hectic activity, he doesn't even know what he's really delegating.

* Time to prioritize?

* Time to take care of the team?

* Time to properly understand the product?

Everything is compromised and insufficient.

The team totally gets what the project manager is going through, and they're making the most of it.

“Project manager — handle this, handle that.”

Shortly after the project starts, the project manager has a whole troop of monkeys sitting on his shoulder.

All experienced leaders know it's unwise to let employees put monkeys on your shoulder — meaning you take over tasks that they should be handling themselves.

For years, I didn’t really have a solution.

Then I came across the roles in agile project management.

That’s when it clicked — there are a lot of smart things going on there. And honestly, some of it would work great in classic projects too.

One of the smartest ideas is to divide the project manager's responsibilities among several people.

Instead of one person juggling everything, you've got a few people, each focusing on a specific part of the project - and giving it their full attention. That way, they can really dig in, build up expertise, and bring serious skills to the table.

Another major advantage is that it allows for dialogue and resolves conflicts of interest that the project manager would otherwise have to deal with on his own.

You're wondering what conflicts of interest a project manager has?

Please have some patience, I will explain it in the following.

What Does a Project Management Master Do?

The Project Management Master is the mediator between the project manager and the project team. He has the responsibility to ensure that the project "runs smoothly."

* He is a proven specialist in project management methods and supports the project team in their professional application.

* He asks intelligent questions to uncover misunderstandings and conflicts of interest and moderates their resolution.

* He supports the project manager in planning by organizing the planning process and ensuring that the plan is properly documented and communicated.

* He defines and organizes project KPIs and keeps them up to date so that the project manager can make decisions based on correct data.

Why Project Manager and Project Management Master?

Conflict of Interest Between Project Goal Achievement and Resource Availability.

Let's start right away with the first conflict of interest, which is the compromise between realistic planning and ambitious delivery of project content.

In the last article, I described that the Project Manager is responsible for planning all necessary project activities and assigning them to the right project members.

Regardless of whether it's an agile or a classical project, the division of labor is the same.

The Project Manager needs to know what is needed, and the project team needs to know how it can be done. This is exactly where the conflict of interest lies.

* On the one hand, the Project Manager is responsible for ensuring that the project goals are achieved.

* On the other hand, he must also manage the available resources.

This means he has to negotiate with the team about what is possible and what is not.

At the end of the planning phase, the team must be motivated to deliver the agreed result under all circumstances. For this, they must have understood the purpose and context.

If it turns out that the project goal cannot be realized in the agreed form, then he must negotiate a new compromise with the stakeholders.

You can imagine that the project manager often comes into a conflict of interest with his two responsibilities here.

* Does he demand too much from the team just to avoid negotiation with the stakeholders?

* Or does he report project goals as unachievable because the team is not trying hard enough to achieve the goals?

It's always unfavorable when a participant with his own interests tries to negotiate a fair compromise.

In these situations, the Project Management Master is the neutral third party who has the opportunity to speak with both sides and help find a good compromise that is acceptable to both sides.

Division of Labor in Planning

Once the Project Manager has defined and communicated the goals for the next stage, it is necessary for everyone, yes, really everyone involved in the project, to become clear about their contribution to achieving these stage goals.

This requires a very well-structured planning process with a large number of planning discussions.

Each employee must:

* understand the goal,

* plan their activities,

* arrange necessary inputs with colleagues,

* include inputs for others in their plan, and also

* keep an eye on their resources, and

* be careful not to promise too much.

In the inevitable case that not all activities are possible simultaneously, prioritization must take place.

To make the right choice, it's important to consider the different options and find the best middle ground.

That's a lot of work that needs to be done in a short time.

The focus of activities in the project should be on implementation, not on planning. Therefore, planning must be focused, short, and well-coordinated.

Organizing and administering this is an effort that the project manager himself cannot manage because he has to define the project goals in terms of content at the same time.

This is where the positive effect of the division of labor between the Project Manager and the Project Management Master comes into play.

The Project Management Master concentrates 100% on the process of defining the plan for the next project increment, the next milestone, or the next quality gate.

The Project Management Master puts his focus on the planning process and ensures that all tasks are identified, all agreements are made, and all activities and plans are properly documented and communicated.

Division of Labor in Risk Management

Risk management is a core pillar in project management.

As I have already written in the article about the responsibilities and tasks of the Project Manager, it is the responsibility of the Project Manager to know and manage all project risks.

In my observation, the assessment of project risks is a very complex process that requires high methodological precision.

Often, risks, root causes, and risk impact are mixed up, although for a clean assessment and risk avoidance, it is essential to perform these steps precisely, one after the other.

First, the actual risk must be identified, then the possible root causes that could lead to this risk must be determined comprehensively and systematically. Only then does it make sense to define measures to avoid the risk, implement them, and check their effectiveness.

The Project Management Master has the training and time to help the team work methodically and cleanly.

The Project Manager doesn't have to be at every risk workshop. It's enough if he handles the analyzed data and makes the right decisions.

Also in this context, the Project Management Master helps the project team to work independently and responsibly, thereby relieving the Project Manager.

Tracking of Planned Activities

I hate tracking!

By "tracking," one generally understands the monitoring of whether everything that was agreed upon is also completed on time.

If you see that a result is not there when it should be, and you realize that something went wrong earlier, it's too late to fix.

The time has passed and cannot be brought back. Now, an irrecoverable project delay has occurred.

This is exactly what needs to be prevented.

So, a way must be found to identify approaching delays so early that there is still reaction time to complete the result on schedule.

How can this be achieved?

One way is to regularly ask the project team members how things are going.

Are you progressing well with your planned activities?

If someone is already stressed, they might not ask for help in time. In this situation, it's a good idea to ask.

Another way is to assess the status of planned activities in the project planning tool.

The Project Management Master invests the time to continuously look at and evaluate the status of activities in the project planning tool.

He is also continuously in conversation with the project members.

If he recognizes approaching delays and delivery problems, he immediately helps the team find countermeasures. In doing so, he can assess whether the Project Manager or even the stakeholders need to be involved.

There is no more unpleasant situation for a line manager than being approached by other people and not knowing that his employees are struggling with a serious problem.

In my projects, I have introduced a "red telephone - mail" This is an email to the project manager and the relevant project stakeholders, which contains the following text:

"There is a problem with issue xxx in project xy. We have recognized the problem and are working on a solution. We will contact you if we need support."

These emails usually can come from the project management master.

The Project Management Master is Not an Assistant

The Project Management Master is not disciplinarily subordinate to the project manager but represents an equal and independent project role.

It is common in classic projects to employ one or more project management supporters (PMS).

These people either report to the Project Manager or are hired from outside the company to work on the project for a limited time.

I do not want to deny that such a resource can take over part of the tasks of a Project Management Master. I also recognize that PMS employees can be proven project management experts.

Nevertheless, the disciplinary dependency stands in the way of the possibility of making a valid balance of interests between the project manager and his team.

To put it briefly, a Project Management Support is better than nothing, but it does not replace a full-fledged and independent Project Management Master.

The concept of a Project Management Master is not widespread in classic product projects.

Do you have experience with the role of the project management master in classically organized projects?

Would you like to try it out and realize the positive effect on your projects?

Then let's talk about it. Write to me in the comments or 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!