Business Practices for Engineers

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 t…

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

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 Confiden…

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

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 …

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

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 …

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

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 he…

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

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 regul…

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

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 att…

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

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 extrem…

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

* 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 employees 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.

A deliberate change in the organizational structure is needed to adapt it to the new challenges. And that requires a concept.

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. A people manager, as it is sometimes found in an agile context.

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, 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.

I recommend the following approach:

Project Organization Steers — Functional Organization Delivers

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

This leadership principle is also based on competence:

The project organization…

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

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…

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