Business Practices for Engineers

I just can’t stand them anymore.Those consultants and smart advisors who go from company to company telling everyone—whether they want to hear it or not—how brilliantly Chinese firms are making Western companies look old and foolish.But you know what?These consultants are right about one thing:Competition has gotten tougher, there’s no denying that.If we want to survive in this new world and thrive long-term, a whole lot needs to change in our companies.But the solution doesn't lie in copying Chinese companies—it lies in being better.I won’t address all the aspects that play a role on the path to long-term competitiveness in this article. I’ll only select one aspect, but one I consider absolutely crucial.And honestly, it’s long overdue that we tackle this.We need to transform the potential of our employees and leaders into outstanding products with high efficiency and without wasting time.Today, let’s talk about how we can make this happen!Efficiency as a Critical Competitive FactorIn my last article, I wrote about why individuals can achieve little alone but accomplish much through collaboration, and why building personal relationships and networks is essential to this.I described how people with many strong relationships are more successful than lone wolves.But what if we didn’t leave it up to individuals to build and maintain their relationships?What would happen if we implemented a way of working in the company that methodically and systematically promotes the formation of strong relationships between people?Exactly — we would activate the potential of our entire workforce as an integrated collective, and the company’s performance and thus competitiveness would increase!Costs decrease, products improve, customers become more satisfied.One effective way to do this is to make the Drum Beat, which I introduced as a project management method in previous newsletter articles, the general working rhythm throughout the entire company.Experience shows that cost reduction programs only produce short-term results. The Drum Beat, however, when practiced continuously as a work mode, ensures lasting efficiency that increases steadily with growing experience and ever-strengthening relationships.What I'm explaining using the Drum Beat as an example naturally works with all similar methods, such as product increments in agile project management. I think you'll recognize the parallels and be able to transfer this to your process if you're using something similar instead of the Drum Beat.If you have questions, don’t hesitate to contact me.So let’s look at the details of what matters.Shared Goals Are the Key to Company Success, but Also to Individual Success.If the potential of every employee and every leader is to be efficiently deployed to increase efficiency for the entire company, then it’s an important prerequisite that the goals and results of all process participants are aligned.From the company’s perspective, it’s simply not enough for employees to individually achieve their personal goals. It’s necessary for these individual goals to work together toward a common company goal.This doesn’t happen by chance but must be ensured through a well-structured process.The Drum Beat planning process offers an excellent opportunity for this.In the project, the project manager develops short-term Drum Beat Deliverables with their project management team. These are goals aligned with achieving project objectives and give the entire project team orientation and priorities.They are also a recognized measure of each project team member’s success, giving everyone clarity about what’s worth putting effort into.The Drum Beat Deliverables serve to clearly align and prioritize important value-adding activities, as well as to share acceptable risks. This ensures that valuable resources and funds are truly invested in the right priorities.Clarity regarding the results to be achieved helps both individual employees and the entire company.In many companies, projects are the essential part of business operations that determine success. Nevertheless, there are many reasons to use the Drum Beat method outside of projects as well, in the ongoing daily business of all indirect administrative areas.In addition to project goals, this also addresses company goals that aren’t directly influenced by projects.I’m excluding manufacturing areas here because they usually have other objectively measurable goals that enable elegant efficiency measurement. We can talk about that if there’s interest.Clear Agreements Strengthen RelationshipsOnce the deliverables and thus the priorities are clear to everyone, it’s about all employees making their individual agreements to be ready to work and deliver.This is nothing less than well-organized relationship building. People talk to each other about who needs what from whom and document it properly so it won’t be forgotten.In this phase of Drum Beat planning, the foundation for trust and good relationships is laid here. Exactly as I described it in detail in my last article.Communication is intensive, support needs and necessary contributions become concrete and completely transparent to those affected.Remember? In my last article, I challenged you to make a personal plan for how you can intensify your relationship maintenance.The Drum Beat Planning ensures that an organizational framework is provided in which everyone simultaneously works on their support needs and commitments to others, making exactly this plan.This increases the intensity and quality of this aspect of relationship maintenance, creating a strong relationship network throughout the entire organization while also helping each individual.Through the shared rhythm and beat, an intensity is possible that couldn’t be achieved through singular individual actions.Now We Really Do ItOnce the planning event has taken place, it’s time to deliver on the promises.Here again, everyone is working together with the same priorities.The Drum Beat ensures that the probability of actually achieving the goals is very high.I think an achievement rate of over 80% should definitely be reached. If it’s lower, the goal ambition must be reduced so that the organization’s performance level and ambition level align.The increasing efficiency over time will ensure that ambition can also rise. So don’t plan for 100%, but aim for a range between 80 and 90%, so there’s a corridor for efficiency growth.It’s clear that this promotes the trust aspect. Achieving jointly agreed deliverables provides confidence that it will work again next time.This increases people's trust in each other. As a result, people become more ambitious and learn how much more can be accomplished.Celebrate Achieved Results and Be GratefulAt the end of every Drum Beat, we review what was achieved together.This makes it clear to everyone what worked and what perhaps didn’t.This shared pause and appreciation of what was achieved is a crucial point that helps solidify relationships between people.It’s not necessarily common to take this time and talk together about what was achieved. The Drum Beat offers a unique opportunity to show gratitude for a colleague’s support.Don’t take this lightly. Here in Germany, especially in Swabia, they say: not scolded is praised enough. It’s meant to suggest that celebrating gratitude is seen as a waste of time.But the exact opposite is true!Strong relationships and trust—indispensable for efficient collaboration—only form when people receive feedback that their efforts are seen and there's willingness to show appreciation in the future.Here again, the Drum Beat offers the opportunity to handle this important aspect of relationship maintenance simultaneously and in a well-organized manner.How Can We Be Even More SuccessfulI think you’ll agree with me that it’s not satisfying to remain at a once-achieved performance level.There are many scientific studies proving that ambition isn’t coincidental but belongs to human nature for many reasons.But we also know that the field in which each individual person displays their ambition doesn’t always lie in business.However, when a group of people work together trustfully and then consult together about how to improve as a team, ambition becomes contagious.Here too, the Drum Beat offers an organizational framework with its retrospective that makes a level achievable that’s greater than the sum of individual persons.Personal Success and Company Success Go Hand in HandI wanted to make clear in this article that personal success and company success are symbiotic.If the majority of employees in a company are successful, then the company is usually successful too.But the reverse is also true: if the majority of employees aren’t successful in their work, then the company has a results problem and is very likely not competitive in the long term.I always start from the employee perspective, because the notion that employees automatically become successful just by working for a successful company is an unrealistic fantasy with no basis in reality.That’s why I believe the right and important path is to start with organizing employee collaboration to lift the company’s overall performance to a level that wouldn’t be achievable through individual successful employees or leaders alone.Now it’s true that there are other important factors to address as well — more on that in future articles.But let’s start with employees and their collaboration. I hope I’ve convinced you that significant improvement potential can be realized this way.However, it still needs to be operationally implemented in daily business processes, and I haven’t described all the details here in the article.So if you’ve decided to implement this proposal, contact me and I’ll discuss the operational design in your specific environment together with you.You're free to choose the method that works best for you.I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.If you found this helpful, don’t forget to share it with others who might enjoy it too!I’d be very grateful if you shared my newsletter with your friends and colleagues. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

It’s always about personal advantage!What’s your reaction to this statement?“Of course it’s about me! That’s always been my motto.”Or“Absolutely not, that’s antisocial! The common good must stand above the individual’s self-interest.”Let’s unpack this together. I hope we can agree on a common perspective.But if you have a different opinion, don’t hesitate to share it with me. You can use the comments or send me a personal message. I’m very curious!It’s About Creating ValueWhen I talk about the business environment, we often immediately think of numbers like revenue, profit margins, or ROI.But actually, the purpose of every business activity is to create value for which someone voluntarily gives up something that belongs to them.Yes, this business value can often indeed be measured in money.However, it becomes more difficult when it’s not about companies, but about people.In human interaction and collaboration, compensation often doesn’t occur through direct exchange, but happens with a big unknown time delay.I help someone else today and get something back sometime, possibly.Another special feature is that this compensation often doesn’t consist of money, but of other, non-material values such as social status, services and competencies that I don’t have myself, or simply by having something taken off my plate that I don’t like doing.And this is where community comes into play, because the community can also give something to the individual that represents value to them.It’s not just about the relationship from person to person, but also about the relationship from the individual to the community.Take a moment and think about what other forms this compensation could take, so that it’s “worth it” for you to do something for someone else now.Precisely because this connection between creating value for others and receiving value for oneself can be so diverse and non-concrete, people must enter into relationships with each other. Relationships are necessary for the system of human society to function.If you have a good relationship with another person, you will receive something from them without having to give something back immediately. You will also give something without immediately expecting something in return.But the reverse is also true. If you believe that the other person won’t do anything for you, then you won’t do anything for them either.That’s called a bad relationship, and it develops in the same way as a good relationship, namely by gaining experience with the other person.So let’s next look at how a good relationship comes about.TrustTrust is the conviction that you will receive from someone what you expect from them.Every person has expectations of the other person with whom they interact.When these expectations are met to a high degree, trust grows.I collect positive experiences with the person and therefore assume for the future that my expectations will continue to be met.If this is mutual, then a good relationship develops between us.If my expectations are regularly not met, then exactly this experience forms. The advance trust that may have been present initially dwindles.No relationship develops, instead we distance ourselves.While trust is lost very quickly, building trust is much more effort-intensive.It’s not enough to want to meet the other’s expectations, it must actually happen. That’s why let’s now look at what’s necessary for this.CommunicationVery intensive and honest communication is the first and one of the most important building blocks for building trust, for two reasons:* If you don’t talk to the other person, you won’t learn their expectations and therefore you most likely won’t meet them. Believe me, random hits or intuition aren’t enough! You must communicate very intensively and broadly so that you even learn what moves the other person, what help they currently need, what problems burden them, and what support they’re willing to accept.* If you communicate frequently and extensively, your counterpart gets the feeling that you’re interested in them and their problem and want to help them. Even if the expected help perhaps doesn’t come or doesn’t work as expected, the experience remains that you wanted to help them, and that’s already half the battle.Yes, there’s a right measure for communication. Too little communication is harmful, too much communication is annoying. But communicate more rather than less!ProximityProximity to each other is closely related to communication.It’s much more credible when you look directly into each other’s eyes during communication, directly perceive body language and emotions.Believe me, it’s no coincidence that executive assistants climb the career ladder much more successfully than other employees.You can assume that they’re capable and probably smart too, otherwise they wouldn’t have been selected for the job. But there are many more competent and smart employees in the company.The difference certainly also lies in the fact that they have proximity to the boss, which enables them to build great trust. Believe me, no one promotes someone they’re not sure is worth the trust!Now not everyone will always have the opportunity to establish this proximity. That shouldn’t stop you from communicating and building trust. Where it’s not so easy, you just have to make more effort.And don’t limit this just to bosses for the sake of your career, because if you don’t have the trust of your colleagues and they don’t help you, then the boss won’t either.AuthenticityAuthenticity is the next important building block for gaining trust.Be as you are!You instinctively sense whether someone is playing a role, and when you have this feeling, it’s not trust-building. You then involuntarily ask yourself: “Why are they doing that? Do they have something to hide?”This suspicion is fatal and destroys trust.Authenticity is the basis for predictability, and this in turn pays very strongly into trust.Be as you are, then the other person knows what to expect from you. They can then adjust their expectations to reality and also understand why something might run differently than they expected.This also includes openly admitting mistakes and dealing honestly with yourself and the situation.EmpathyWhile authenticity was about you, empathy is about the other person.You must take the time and make the effort to put yourself in the other person’s shoes.It’s not enough to ask the other person about their expectations and then meet them.You must find out what really moves the other person, what they expect from you in their inner self, and what is how important to them.It helps to have known each other for a long time. Over time, it becomes easier to grasp the other’s thoughts, recognize their feelings, and identify their expectations.ReliabilityMeeting expectations also means being reliable.Actually, this is the simplest discipline in building trust, but it’s still so difficult:Keep what you promise!Do what you say!With expectations that you create yourself, there’s no “I couldn’t have known that!”Yes, it’s as trivial as it sounds: Those who are unreliable lose trust. You can’t build a good relationship with unreliable people.Here too, of course, there’s no 100%. Something can slip through. When that happens, authenticity and honesty can often still save the situation.However, if it becomes the rule to not keep your promises, then trust is gone, and so is the relationship.ReciprocityAfter talking so much about trust as the basis of a relationship, I want to come back to reciprocity.Reciprocity is the principle of exchanging values.I give you something, I get something from you.This principle forms the foundation for a good relationship and for success in a business context.Trust is the belief or certainty that this principle works between us.But it’s not enough that we both have trust, we must also actively apply it.An important basic rule is that reciprocity consists of advances.Everyone must do the right thing for the other person at the time when they need it. But at that time, they don’t know whether they will really get the return service sometime and whether the measure will be balanced.A situation can certainly arise where one person always gives more than the other in the long run. Perhaps because the other can’t give more, or because I myself don’t need more.In the end, it’s not the balance sheet that’s decisive, but that the principle works at the right time for everyone.So don’t hesitate, when the other person needs support, give it to them.Now comes the big but:There are situations where the other person isn’t willing to do their part of reciprocity. If you recognize this, you must act, otherwise you’re the fool and will be exploited.Address it, and if it doesn’t change, then draw the consequences. There are relationships that can’t be patched up and must then be consistently ended.Willingness to CompromiseAn important aspect of reciprocity is the willingness to compromise.There will always be situations where your own interests are in opposition to the interests of the other person. Here it’s necessary to find a compromise that both can accept.This requires willingness to compromise on both sides. If one party continuously insists on their advantages, then it’s difficult to build and maintain a good relationship.So be willing to back down sometimes, trust that the other person has the same attitude.Network MaintenanceIn a business environment, an extensive network of relationships is necessary to be successful yourself and to be part of a successful environment.That’s why you must develop and maintain a multitude of relationships. This costs effort and time, but it’s still advisable and even necessary.Another element of a good relationship is that you also share your network, which you’ve built with great effort, with others.Reciprocity isn’t just about doing what’s necessary yourself, but also about using your own relationships and the associated trust to help the other person.ProfessionalismWith that, I come to the last point for today, professionalism.To be useful to others, you must also be really good at something yourself.This requires professionalism.Professionalism means qualifying yourself in a field, developing skills and abilities, and being able to produce high-quality results.The profession is where you can create relevant value for others.You need something that’s your brand. Something that everyone knows you’re particularly good at and that it’s worth building a relationship with you for.Partnerships Are Based on Functioning RelationshipsIn the last article, I addressed partnerships and claimed that it makes more sense to build equal partnerships for mutual benefit, rather than practicing collaboration according to the power principle based on unequally distributed power positions.I claimed that partnerships only work when the people involved build good relationships with each other.In this article, I’ve now addressed exactly these relationships.Please write to me about what experiences you’ve had in this topic area and which aspects I may not have covered sufficiently.We can also 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!I’d be very grateful if you shared my newsletter with your friends and colleagues. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

I think very few people believed we could actually pull it off!It’s been 25 years now. We were a small team with a big mission:“Build a company, develop a portfolio of heavy commercial vehicle axles, and supply the American subsidiary’s serial production with high quality and deliver reliability in 3 years.”When we tackled this impossible mission, one thing was clear: We could only do it together with strong, competent partners. Alone? No chance!The path we chose was unusual back then and still isn’t standard practice today.But before I reveal the secret, I want to describe the standard approach I typically observe—one that has nothing to do with true partnership. That way, you can judge whether this is also common in your environment.Everyone Thinks: The Most for Me!In a way, it’s even logical and understandable. When it comes to business, everyone wants to maximize their profit by using all the levers they have.If you do this consistently, you can observe the following approach:* I need something for my project that my organization doesn’t have. So I have to buy it. This could be parts or services. What it is doesn’t really matter—in any case, I have a problem on the table.* To solve this problem, I search for potential suppliers who have what I need. With some luck, I find multiple offers.* In this situation, I can now use the competition between potential suppliers to negotiate the best price for myself. The more time I have, the more I can put pressure on suppliers. I hold the stronger position and can use my decision-making power to my advantage.* I delay signing the supply contract as long as possible, specify the product very precisely, and negotiate hard on every small, individual cost item in detail.* During this phase, suppliers undercut each other, each trying to offer the best price to win the contract.* Meanwhile, development is already running at full speed. The developers have to work with all suppliers simultaneously, which means extra work and unclear relationships.* Suppliers do only as much as necessary to barely stay in the race. They don’t want to invest too much because they know only one will get the contract.* Once the supply contract is signed, the supplier holds the stronger position. Every change that becomes necessary during product development, they charge dearly for. Now is the time for them to recover what they sacrificed during the bidding phase.* When we’re in serial production and the time comes for the supply contract to expire and be renegotiated, the arm-wrestling starts again.* I threaten the supplier that I won’t extend the contract unless they lower the price.* They calculate how much a supplier change would cost me. In my business, these are substantial sums. That’s why the supplier will explain at length that the previous price is no longer profitable for them and they therefore demand a price increase.* Each side tries to extract the maximum for themselves. I’m in the weaker position because my costs will rise either way. Either I accept the cost increase or I invest substantial sums to switch suppliers.* My leverage returns when the next project begins. However, the current supplier benefits from the experience and assets gained during the previous project, giving them a significant competitive advantage over competitors. They will fight aggressively to retain the business, undercutting any rival without hesitation. The supplier knows they can increase prices again once I’m back in a weak negotiating position—which happens with predictable regularity as soon as the product is completed.* If the supplier manages this skillfully over a long time, they have the opportunity to eliminate all competitors and build a monopoly. Then I’m really in trouble!And of course, my customer does exactly the same thing with me as a supplier!Do you recognize this pattern in your environment? Were you already aware of it, or does it surprise you to see how this actually plays out? You’ll probably also conclude that this approach isn’t efficient and certainly doesn’t lead to an optimal outcome for anyone. There’s either a winner and a loser, or even two losers—which is always the case when neither side makes money in the end.The Way Out: Strategic PartnershipI think it’s clear that we wouldn’t have accomplished our task back then if we had proceeded as just described.Instead:We entered into strategic partnerships with our suppliers.Now I’ll explain how that works and what prerequisites are necessary.It Starts with a Shared VisionUnlike the approach just described, my intention here is not to delay the decision as long as possible, but to make it as early as possible.The supplier decision and contract isn’t based on a detailed negotiated price, but on an agreed compromise based on mutual trust.I lay on the table what product goals I need to achieve and what costs I can afford to reach my required profitability.The supplier lays on the table what their product can do and what price they need for their profitability.Of course, this doesn’t fit together yet. Each side must move away from their optimum somewhat.I have to make compromises on product requirements and also be willing to compromise on my price expectations.The supplier may have to invest more effort in their development and also price in cost efficiencies they can’t yet prove.We agree on a mutually supported compromise that includes risks for both sides.Trust Is the Foundation, and That Always Exists Between PeopleThe essential difference from the approach described at the beginning is that the basis for the contract isn’t supposedly objective facts, but agreed-upon goals for which both sides must contribute throughout the project to achieve.That’s exactly the crucial point. Both sides must become convinced that each will do everything to realize the agreed overall optimum.There can be no “not my problem” attitude here. All problems are shared problems.This trust only develops when the compromise is intensively discussed. And specifically, the people who also have decision-making responsibility during the project’s implementation phase must talk with each other.This is exactly where the challenge lies, especially for large companies with this approach. The more people who have a say, the more difficult it is to build trust and ultimately to prove worthy of that trust.Back then, we were a very small team with full decision-making authority, and we worked with similar partners. Yet even in that situation, I can say from my own experience that it’s not easy to choose the most trusted partner over the one with the lowest initial price offer.Partnerships and Trust Grow Over TimeOnce you’ve successfully brought a project to completion on this basis, both sides have experienced that they can rely on each other. That the trust is justified.This strengthens the trust basis for the next project.You don’t just quickly switch suppliers then, but build further projects on this increasingly strong trust foundation.This creates long-term partnerships that provide security on one hand and enable efficient work on content on the other, because the power games don’t happen.Even though it might look like a monopoly at first glance, it is something completely different. Other suppliers still exist, even though the partners choose to stick together for mutual benefit. However, there is no guarantee that a partnership will last forever—that has happened to me as well. When it does break apart, you have to find a new partner.Profitability and Partnership Aren’t Contradictory — Quite the OppositeWe’re currently experiencing where power-based business models can lead.Disrupted supply chains, exorbitant costs, and companies struggling to survive.This exact consequence occurs when one side manages to gain absolute dominance without adequate mutual dependencies.If you strive for that yourself, you must also expect that the other side might possibly succeed in building up this position.In a true partnership, this can’t happen. All sides have a common interest and common success.But it’s also important to understand that you can’t force a partnership. If a partner isn’t trustworthy, it doesn’t change anything if they offer the supposedly best price.To put it another way: Cheapness is dangerous!What’s Your Opinion?I could write many more details about partnerships in a business environment. But before I do that, I’d like to hear from you what you think about the topic.What’s your opinion?Are you interested in more details?Have you gathered your own experiences with partnerships?Please write in the comments or let’s 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!I’d be very grateful if you shared my newsletter with your friends and colleagues. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

A Counterintuitive Approach to Better Project OutcomesIn my last article, I made a provocative claim.Project team members shouldn’t report directly to the project manager. Instead, they should have a different supervisor.I know this goes against common practice. That’s exactly why I want to explain my reasoning today.The Core Problem: Power Imbalance in Conflict of Interest SituationsLet me get straight to the point:Projects have multidimensional goals. Trade-offs are inevitable. The problem arises when a single person must negotiate these trade-offs alone with themselves.The result? Stress for that person and suboptimal compromises for the project.A truly optimal, sustainable compromise requires three elements:* Clear advocates: Each goal dimension needs someone who openly champions that position* Equal footing: All parties must negotiate as equals* Neutral facilitator: A Project Management Master who moderates without their own agenda, working toward consensusThis is precisely why I’ve defined project management roles along these goal dimensions:* Project Manager: Responsible for project objectives.* Project Architect: Responsible for the product.* Functional Representatives/Project Team: Responsible for technical execution and content realization.The Power Imbalance ProblemWhen the project manager is also the supervisor of other project management team members, the power dynamic becomes distorted.The project manager possesses additional leverage through their ability to conduct performance reviews and impose disciplinary measures.The consequence is predictable: Team members will carefully consider how hard they push their interests against those of their boss.It’s not easy to contradict your supervisor and consistently advocate for your position against theirs—even when that’s exactly what the project requires.Three Common Objections (and My Responses)“But good managers can make good decisions on their own!”Of course competent leaders can develop compromises independently.The real question is: Are these the optimal compromises?That depends heavily on chance—the manager’s character, their mood that day, the team’s courage to speak up. Why leave project success to chance when we can build it into the structure?“Isn’t this just about performance management?”No. Naturally, managers must monitor performance and address issues. That’s not in dispute.The core of my argument is different: It’s about conflicting interests, not performance deficits.The danger lies precisely in the dual role of project manager + supervisor, where these two issues become too easily entangled. These dimensions must be clearly separated.“In line management, the boss is responsible for everything too!”Ideally, a line manager has a single, clear interest: the functionality of their department.In the dual role, however, multiple contradictory interests systematically overlap.Similar situations exist outside of projects, and they cause significant problems in practice. Often, they’re branded as “micromanagement.”A Concrete ExampleHere’s a classic conflict scenario that illustrates the issue.The SituationProject Goals:* Reduce energy consumption by 5%* Keep product costs constant (versus predecessor)* Be customer ready in 3 yearsThe Reality:The project team developed optimization measures. Combined, they would just barely achieve the 5% target.But there’s a catch:* Implementing all measures increases product costs* Some measures violate platform guidelines, others conflict with brand standardsResponsibilities in a Project OrganizationTo better understand the positions of the individual project team members, here is a brief overview of the responsibilities.Project ManagerThe project manager is responsible for ensuring that the project goals are achieved.Typical project goals for which the project manager is responsible include:* Delivery deadline* Project and product costs* Performance indicators defined in the project charter (quality, performance characteristics, functionalities, etc.)They owe the project team balanced, realistic goals that they must align and agree upon with the stakeholders.Project ArchitectThe project architect is responsible for a customer-appropriate, platform-compliant product that aligns with brand characteristics.They represent the interests of the platform architecture within the project and ensure compliance with cross-project product properties and characteristics.At the same time, they owe the project manager technical architectures and concepts with which the project goals can be achieved.Department Representatives / Project Team MembersThe project team members are responsible for efficient and competent delivery of project work.The project team members decide on the working approach and the technical execution.In doing so, they must consider both the project manager’s specifications regarding project goals and the project architect’s specifications regarding product architecture and properties.At the same time, they owe the project manager efficient, goal-oriented procedures that minimize resource and time consumption, along with balanced risk awareness.The Three Competing InterestsThose different responsibilities lead to the following perspectives.Project Manager’s Perspective:* Implement all measures* Avoid cost increases through more efficient design* Negotiate remaining cost gap with suppliers* Complete everything on scheduleProject Architect’s Perspective:* Implement platform- and brand-compliant measures (even if costs increase)* Drop non-compliant measures (even if the energy goal is missed)Project Team/Functional Representative’s Perspective:* Get more time to search for better solutions* Adjust goals with stakeholdersFinding the CompromiseIn practice, there’s rarely a perfect solution. Not all predetermined goals can be achieved simultaneously.A compromise must be found across all goal deviations:* Time compromise: How much additional time is acceptable? Can other activities be shortened to compensate, or is there flexibility in the delivery date?* Content compromise: Which measures get implemented, which don’t? This determines the gap in energy consumption, costs, and platform compliance.* Process compromise: When are project goals adjusted—immediately or after validation? This addresses how stable or volatile the compromise is.I don’t want to specify a particular compromise here; in each specific situation, a different solution will be the best one. Nevertheless, I think the example illustrates the problem.Deciding or Negotiating CompromiseCompromises can be reached in two fundamentally different ways:Negotiating or deciding.In both cases, arguments need to be brought to the table, but not necessarily all of them.Finding Compromise Through DecisionEvery deviation from a well-considered guideline can have consequences. If there are no consequences, then it’s easy to accept the deviation.However, the consequences are usually neither recognizable at first glance nor assessable in their impact.For this reason, each stakeholder must examine the effects on their area of interest and explain them to the team.In the case of a decision by the project manager, the project managers don’t have to explain their arguments. They make the decision themselves anyway.Of course, it’s a great advantage for the acceptance of the decision if they communicate their arguments in the justification.However, I have very often had to experience that in the hectic rush of daily business, this is exactly what doesn’t happen.The consequence is then a poor collaborative climate and an “I don’t care anymore” attitude.Deciding on a compromise is undoubtedly the fastest solution strategy. However, it’s also the solution strategy with the greatest volatility.The probability of finding the best compromise through decision-making borders on the probability of winning the lottery.As long as it’s a reasonable compromise, it’s not a disaster not to decide on the very best solution. Things move forward in any case, and that’s important.However, possible misjudgments in the decision-making process and a lack of commitment to the compromise within the project team regularly lead to this compromise being frequently questioned afterward.Finding Compromise Through NegotiationIn negotiation, all arguments come to the table.Each advocate explains what consequences arise for their area from each potential goal deviation. Here the project manager is part of the team.Then consensus is sought.Consensus means finding a solution everyone can live with, even if not everyone is happy. But there’s both understanding and acceptance.Prerequisites for stable consensus:* All participants are equal* A facilitator without their own agenda guides the discussionThis is exactly where traditional hierarchy fails:* If the project manager is the team’s supervisor, they’re no longer equal—they have power.* If they also supervise the Project Management Master, the facilitator is no longer neutral—they’re suspected of representing the boss’s interests.When the project manager is on equal footing, the resulting consensus has significant advantages: It’s based on the entire team’s competence and a shared risk assessment, giving it high quality and acceptance.The Bottom LineI’m not claiming projects can’t function without separating disciplinary and professional authority. Many projects run reasonably well in traditional structures.But I do claim this: The separation offers substantial advantages that significantly improve both project outcomes and project climate.Good compromises aren’t found by luck or because someone decides to be nice. Good compromises emerge through structures that enable genuine representation of interests, equal footing, and neutral facilitation.Now’s the right time to jump into the comments – I’d love to hear about similar experiences, parallels you’ve seen, or your take on this.We can also chat on this topic.I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.If you found this helpful, don’t forget to share it with others who might enjoy it too!I’d be very grateful if you shared my newsletter with your friends and colleagues. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Sometimes it proves useful to explicitly clarify matters that intuitively seem self-evident.Upon closer examination of common project management terms, I find that not everything is as clear as assumed. This is precisely what causes misunderstandings in collaboration. People wonder why things don’t run as smoothly as they would like.For this reason, I want to discuss the following terms in this article:* Management* Manager* Project Management* Project Management Team* Project Team* Project Management Office* Project Management Support* Program Management OfficeYou see, that’s quite a long list. So let me get started right away.This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber.ManagementWhen it comes to the term “management,” we need to distinguish: Do we mean the activity itself or the people who perform it?I’ll first focus on the activity and then address the role.Managing Is More Than Giving Instructions!The biggest misunderstanding arises from the fact that “managing” is often understood only as interaction between manager and employee.But it’s much more than that!Unfortunately, it’s also frequently the case that managers inadequately perform these other aspects as well. Which further reinforces this false perception.So what does managing actually include?There’s an abundance of literature that defines the topic very differently.Therefore, I’m presenting a model here that I consider most effective based on my professional experience.Managing includes: Setting Goals, Planning, Commissioning Work and Deploying Resources, Preventing or Solving Problems and Evaluating Results.If you have a different opinion on this, please write to me in the comments—I’m very interested:Now let’s look at the activities which belong to managing:Setting GoalsManaging begins with setting goals.Clarity about goals is the prerequisite for any efficient work.However, defining goals is not a matter of inspiration—it’s hard, time-consuming work in itself.Typically, you start with one or more predetermined goals.To avoid going too deep here, I’m deliberately leaving out goal derivation from visions and strategies.Goals to be achieved must be cascaded into sub-goals:* For topics* For organizational units or individuals* For time periodsPlanningOnce goals are found, planning begins on how the goals can be achieved.* What activities are required?* How much time do the activities need?* Who will be needed for execution?* What conditions and prerequisites must exist?* What dependencies must be considered?* How can partial results and goal achievement be measured?* Who must make which decision when?Commissioning Work and Deploying ResourcesThe next step is the one that management is often mistakenly reduced to.Employees are commissioned to perform their activities according to the plan and develop content.Resources such as budgets, work time, or work tools are provided.Decisions relating to content work are made or triggered.Preventing or Solving ProblemsPlans rarely work out as intended. Therefore: Managing includes anticipating deviations early and taking countermeasures.Evaluating ResultsOnce results are on the table, it must be evaluated whether the set goals have actually been achieved.The evaluation forms the basis for further action.ManagerEmployees who perform these activities are called managers.I consider it very important that managers personally execute all these aspects of management and don’t completely delegate individual ones.This doesn’t mean that a manager can’t obtain support or input.Quite the contrary: Management is also teamwork. I’ll come back to this later when discussing the management team.Conversely, however, a manager should really only manage and not perform content work themselves.Especially in development environments, it’s not uncommon for managers to also possess domain knowledge.Mixing both fields of activity typically leads to poor management performance. Although executives are often called managers, personnel responsibility is by no means a prerequisite for the manager role.Conversely, executives can and should also manage. In fact, management activities are an essential component of every leadership role—personnel management is then added on top.Unfortunately, I frequently observe that executive-managers only personally perform the steps “commissioning work” and “evaluating results” and either omit or delegate the other steps.That’s not good! It’s the cause of many problems we see in companies.All steps require the same attention, have the same priority, and must be performed by the manager themselves. If they don’t do this, they cannot deliver high-performance management.Believe me, I’ve made this mistake myself and suffered the consequences bitterly.I frequently observe that executives neglect goal definition and planning because they believe they don’t have time for it—or because they think everything is already clear and known anyway.A Side Note:Assistants are an important resource because they support executives in management and thus contribute to better management performance.Bosses who want to eliminate assistant positions for cost reasons have not understood how top-level management works.Project ManagementThe starting point of every project is goals specified by the project’s stakeholders.To realize these project goals, two areas of activity are required:* Managing* ImplementingManagingJust as described above, management activities must be performed in the project.The project goals must be broken down into sub-goals along the three project dimensions: cost, time, and performance.Based on this, the project plan is created, the project team is commissioned, and investment funds are released.To control project risks, professional risk management is conducted: risks are regularly analyzed, preventive measures defined and planned.Work results are discussed promptly within the team and with stakeholders. Confirmed results are a prerequisite for reliable and continuous maturity progression.ImplementingSimultaneously with the project, work on the project content begins, which proceeds exactly as worked out by project management.A continuous alignment must take place between content activities and project management activities.Project management takes place before the content processing of project scopes. But then accompanies the implementation activities. Goals, plans, and results must be constantly adapted to realities.Project Management TeamThe project management team consists of:* The Project Manager* The Project Management Master* The Project Architect* The Department RepresentativesEach of them has their own area of responsibility in which they perform management activities. You can read the details in the respective articles.Depending on the size of the organization, it may make sense for the department representative—who is essentially a kind of project manager for the department—to also have a department project management master at their side.These project roles exclusively perform project management tasks, should be freed up for these tasks, and work in only one project.As already indicated in the heading, too many cooks spoil the broth. It’s important to have only the minimally necessary number of employees, each with a clear focus.Only this way is it possible to ensure excellent situational awareness at all times. This is the basic prerequisite for good project management. Too many people means too many interfaces, unclear task distribution and responsibility.Project TeamThe project team includes all employees who work on the project scope. It doesn’t matter whether they are exclusively assigned to the project, work in parallel on multiple projects, or are only temporarily involved.The number of project team members is determined solely by necessity, as determined by the project management team during planning.The rule here is: whoever is needed is part of the team—the number of employees is determined only by necessity and therefore has no lower or upper limit.Unlike the project management team, the project team doesn’t work exclusively on content work.Members of the project team also take on project management tasks within their area of responsibility as part of self-responsibility and self-management.This includes the detailed definition of goals as well as detailed planning of workflows and coordination of collaboration. As experts, they provide important input for risk management and develop the results that are confirmed in project reviews.Project Management OfficeFor the Project Management Office, we need to distinguish how this term is used.I know two different interpretations.A Project Management Office is sometimes the area in the office where the project management team has their workspaces.I just listed who belongs to the project management team. If project management supporters are also present, they also sit in the Project Management Office.Spatial concentration in the Project Management Office is highly recommended. It enables the visualization of important project information on the walls—from project plans to risk portfolios to task boards. At the same time, it facilitates spontaneous exchange and coordination, so that all project managers always share the same situational assessment.The Project Management Office can also be the meeting room where project meetings take place.The other version of a Project Management Office is independent of the actual project.In the Project Management Office, project management experts are brought together who are responsible for project management methods and project portfolios.Here, company-internal project management standards are developed, defined, and brought to decision. Training, qualifications, and experience exchange for project managers are organized. Planning and coaching experts can be pooled here, which projects can access as needed. In addition, the PMO typically selects the project management tools, decides on their use, and adapts them to the organization’s needs.The Project Management Office typically reports to the board of management about the state of project management in the organization. It maintains an overview of the entire project portfolio and evaluates whether sufficient project management resources are available to professionally handle the projects. In case of bottlenecks, it coordinates the deployment of external resources.Project Management SupportProject management supporters are employees who support project management members in conducting project management.This typically includes the following activities:* Planning meetings* Writing minutes* Tracking task completion* Updating schedules* Preparing project status reports* Helping project members work with the project management toolThese are administrative activities.As the name suggests, the project management supporter is intended as assistance and capacity relief for project managers and project members.However, one must note that delegating these administrative activities creates an additional interface between supporter and responsible person, which inevitably leads to efficiency losses. Therefore, I favor optimizing tools, processes and user interfaces so that those responsible can smoothly handle these tasks themselves without being significantly burdened.So if many project management supporters are needed, it’s a sign of poor tools or poor collaboration culture.I also frequently observe that project management supporters are deployed where processes are not regulated or corresponding subject matter experts are missing.Such situations can occur in different contexts, mostly tracking activities.If you deploy PMSs for such activities, something is wrong with your organization.Anyone who has their projects under control without PMSs is very likely working in a very good environment. The need to deploy PMSs should therefore always be an occasion to carefully analyze what they’re needed for and how the situation can be improved so it works without them.Program Management OfficeLet’s conclude with the Program Management Office.Here too, there are two different scenarios.The Program Management Office can take on the role of the Project Management Office. In organizations that strongly bundle projects into programs, cross-project and cross-program methodological competence as well as project management governance can also be bundled in a Program Management Office.Another possibility is to spatially concentrate all program managers and platform architects in one office, thereby improving exchange and cross-program collaboration.The situation is therefore relatively similar to the Project Management Office.Head of PMOI’d like to conclude by pointing out one special feature.Project Management or Program Management Offices with cross-project or cross-program responsibility are independent organizational units with an organizational chart and a head of PMO. The PMO leader is accordingly anchored in the company hierarchy.Project management team members, on the other hand, don’t report to the project leader but either to the PMO leader or—in the case of department representatives—to their respective department heads.Project leaders are often called project managers, both of which suggest that they have disciplinary personnel responsibility.I know it’s absolutely common to organizationally place project management team members under the project leader. However, this has significant disadvantages, which I’ll discuss in detail soon.So please subscribe to my newsletter so you don’t miss these articles.Few Steering the Ship, Many Working on DeckI’ve only covered the selected terms in their essential features here.Nevertheless, it should have become clear why it makes sense to have a focused and lean project management team in a project and to clearly distinguish it from the significantly larger number of project team members doing content work.Therefore, pay close attention in my articles whether I’m talking about the project management team or the project team—these are two fundamentally different things.If you liked the article or have questions or comments, please write them to me in the comments. I appreciate every comment.Also please write me which terms I should go into more detail about in separate articles.Comments are the currency with which free subscribers can reward me for my efforts.We can of course use the chat function to exchange ideas directly.If you liked the article, please share it with others.This Substack is reader-supported. To receive new posts and support my work, consider becoming a free or paid subscriber. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Back When a Truck Was Just a TruckIn the first half of the last century, trucks were beautifully simple. We divided them into three categories:* Light trucks* Medium-duty trucks* Heavy-duty trucksThey were universal tools. You hauled grain, coal briquettes, beer, milk, furniture, machinery—anything that needed to get from Point A to Point B found its ride on the flatbed of the same truck.For manufacturers, the product was crystal clear.One truck type = one bill of materials.You knew the permissible gross weight, you knew the road conditions, and because inspections weren’t as strict back then, you built things a bit more robust just to be safe.Life was simple.Then Came Customer FocusIt didn’t take long for the variety of truck configurations to increase.The original standard truck became increasingly adapted to specific use cases, body types, and customer preferences.At first, manufacturers simply created more types. Alongside the flatbed truck, you now had semi-trailers, dump trucks, multiple wheelbase options, and various axle configurations to choose from.Each of these types had its own bill of materials that guided production.Sales Codes Made Diversity Even GreaterBut then came the flood of additional customer requests, managed through sales codes. Customers could now select equipment details to customize their chosen base model.Different engine ratings, transmissions, tank sizes, power take-offs, weight variants, and much, much more became available.The truck the customer ordered was configured by the salesperson together with the customer, tailored to their specific needs.The bill of materials that guided production was no longer predetermined by engineering. It was now calculated algorithmically using sales codes and plus/minus bills of materials.Each sales code had its own bill of materials with plus and minus positions. These bills of materials modified the base vehicle bill of materials. Part numbers marked with minus were removed from the base bill of materials; part numbers marked with plus were added.A particular challenge was that there wasn’t just one sales code per vehicle order—there could be several. So you also had to list as minus all the parts that might have just been added as plus by another code.This way, a mainframe computer could calculate from the base bill of materials (the bill of materials for the base vehicle) to the correct bill of materials for the customer’s vehicle using Boolean algebra.I can hardly believe it myself, but I personally wrote plus/minus bills of materials.Not on a computer. No, with pencil on printed forms. Entering them into the mainframe was a job for specialists!You can surely imagine that this work was extremely time-consuming and error-prone. The most-used work tool was the eraser. Every designer had to know their scope across all vehicle variants in detail and explicitly document all possible combinations.Inevitably, the time came when this system could no longer be maintained and was replaced by an innovation in product documentation.This innovation was the component bill of materials.NED – The New Engineering DocumentationWith the new product documentation, base bills of materials and sales code bills of materials disappeared and were replaced by component bills of materials.A component bill of materials contains a small number of part numbers that are always—without exception—installed together.Each of these component bills of materials comes with a long instruction sheet of Boolean algebra, called encoding.It describes exactly in which sales code combinations the specific component bill of materials is applied or not applied.The original vehicle type is now just a container holding all component bills of materials that might be needed in any possible combination of sales codes.When a customer orders a vehicle, a computer program (the variant configuration system) calculates the specific vehicle bill of materials for the customer order based on the codes selected by the salesperson together with the customer.You can surely imagine that writing Boolean algebra for component bills of materials is not trivial. It’s probably one of the most demanding tasks a designer faces in their daily work.But there’s one huge positive effect: Everything that fits together doesn’t need to be described!This means that when writing Boolean algebra, the designer can and must focus on what doesn’t fit together or doesn’t work and must be redirected through encoding to a buildable and functional configuration.In this way, a virtually infinite number of possible vehicle configurations becomes possible without having to explicitly develop and document each one beforehand.The Modular Product PlatformThe next simplification step was to standardize interfaces throughout the vehicle.It’s logical: the more things that don’t fit together, the more must be regulated through encoding.The next level of simplification therefore consists of designing the vehicles architecture technically so that through cleverly standardized technical interfaces, as many things as possible fit together. Then they no longer need to be encoded in complicated ways but can be controlled with simpler code rules.Modular concepts were developed and brought into production for all construction scopes.Whether a combination is needed or not, it simply fits and therefore doesn’t need elaborate control.The result:* Fewer parts (component bills of materials)* More possible vehicle variantsEverything Perfect?So we’ve almost arrived in a perfect world, haven’t we? Just add a bit of AI and machine learning to automate the remaining Boolean algebra writing, and we have everything we’ve always wanted.The manufacturer has relatively few parts in inventory, and the customer gets any variant they want.So everything’s perfect?Of course, in reality, this isn’t as trivial as I’m presenting it here in simplified form.But the basic logic is correct.I’ll take the opportunity in many future articles to go into detail about the opportunities and challenges of this variant control.Since it’s an extremely large topic, it would help me greatly if you’d ask questions in the comments about what interests you most urgently. Then I can address those aspects first.Please subscribe to my newsletter so you don’t miss any of the articles.How Variant Control Impacts Development Scope ManagementWhy did I give this whole long preamble when today I’m actually concerned with how development scopes can be controlled?Well, it’s quite simple:I assume that someone unfamiliar with our business in detail imagines development the way it really once was, when a truck was truly one truck.If the truck needed to be renewed or improved, you simply took that specific truck and redeveloped or modified it.In the current situation, that’s no longer possible, because that one truck no longer exists!Even today, not everyone has grasped that the product of every vehicle development is no longer a truck but a truck modular platform!And this has drastic consequences, because unfortunately this platform is incredibly large and must therefore be simultaneously modified in many places for different reasons.These reasons include:* New vehicle applications need to be incorporated, requiring new vehicle variants* Legal requirements must be met, requiring either the entire platform to be modified at certain points or specific scopes to be modified for certain markets only* Technological advancement occurs in technical systems* Quality problems, supplier issues, or other unwanted disruptions must be eliminatedThe necessities to modify the product platform are extremely diverse and require varying amounts of time.But at all times, it must be ensured that the complete product platform functions and is customer-ready! Because otherwise, not a single truck can be configured.The Solution: A Four-Stage Project ArchitectureTo master this complicated situation, the famous elephant must be sliced.A Key Central Element: The ProjectThe project bundles development scopes on the product platform that can be handled by a project organization with minimal interfaces and that follow a common timeline.Minimal interfaces in this context means that project contents are assembled to bundle substantively related matters, thereby keeping the number of involved people and organizational units to a minimum.For this, it must first be clear what exactly is needed. I’ve written extensively about this in my article “Getting the Timing Right: Planning Product Development Projects the Right Way.”Typically, the need for changes to the product platform is so great that multiple projects must be organized. Otherwise the scope of work for the each project management team would become unmanageable large.For This Whole Construct to Actually Work, Project Timelines Must Be Stable and Known for the Entire Project DurationClassic project management is required here.The Project ProgramSo that, what we’ve just separated still fits together, the newly defined projects must be combined into project programs.All projects that have their Start of Production (SOP) in a common time period are now bundled into a program and synchronized using multi-project management methods.This requires a small but excellent program management team that knows all affected projects with their mutual dependencies and orchestrates a structured process that maintains synchronicity.An important detail is that the program management team coordinate the start of projects. This ensures that project timelines are sensibly synchronized from the beginning.Since we’re developing a hardware product, prototypes must be built for testing, and these must be complete, functioning trucks.Therefore, projects within programs must be scheduled so that there are points in time when all projects have the appropriate technical maturity to start vehicle validation.Since we need a market cycle that’s shorter than the duration of a project program, we need multiple staggered programs.The Drum BeatIf you’ve been faithfully following my newsletter, you already know the Drum Beat.It ensures that the milestones and quality gates of the projects that are indispensable for a functioning program are actually achieved with the essential work statuses.This premise is extremely important because schedule delays in one project affect the entire platform and can therefore cause all other projects in the program to run into difficulties.That’s why schedule discipline is absolutely critical!The ToDo SprintThe lowest level in the program architecture is the ToDo Sprint.Since in a matrix organization with a functional organizational structure, work from all projects and programs is processed in the same organizational units, the ToDo Sprint controls task completion.Let me point out here that this organizational form also has something to do with the product platform landscape explained at the beginning.As I explained, the highly variant product platform requires employees who have a complete overview of all relevant content in the segment of the product platform they’re responsible for. This knowledge is indispensable for encoding component bills of materials.But now it’s a prerequisite that all changes to these scopes must also be made by the same team!This isn’t just about packaging space issues but also about knowledge of customer requirements in the corresponding segments of the platform and their functional implementation, which is also reflected in the encoding.Even if systems engineering promises to get all this under better control, it won’t work in the coming decades without highly qualified employees. Believe me.So we organizationally bundle tasks from all projects in such a way that teams have clear priorities and the understanding of the modular product plattform will sustain.ConclusionToday in this article, I ventured an experiment:I wanted to condense a highly specialized situation so that the essential logic of how product structure and project structures are connected fits into a short newsletter article.I’m aware that you surely have many, many question marks after reading this.So don’t hesitate to ask me questions. This way I can target the many other aspects there are to discuss about this very large topic area.I’d also be very interested to know if you have such constellations in your environment.What questions do you have about modular product platforms and multi-stage project management? Share in the comments below, and I’ll address them in future articles.We can also chat about it.I’ll dive deeper into the details in the coming articles. Please subscribe to the newsletter so you don’t miss them.If you found this helpful, don’t forget to share it with others who might enjoy it too!If my newsletter resonates with you, please consider sharing it with others. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

For the most impatient among you, here’s the answer right away:In the commercial vehicle industry, I consider it fast to bring a new vehicle to market in 4 years.With the classic approach used in the past, new vehicle development took 6 to 8 years.In the article “Getting the timing right”, I explain that in the commercial vehicle industry, it’s possible to estimate market demand over a 3 to 4-year period with reasonable accuracy.In many cases, external influences limit the available time to just 4 to 5 years. So it has to be faster anyway, and then it’s good if there’s a plan for how to make that possible.In this article, I will explain what project approach can achieve a short development time while still producing a proper product.If you work in a different industry where these timeframes are different, you may still find food for thought that can help in your environment to reduce project duration to a necessary level.I’d like to ask you to write in the comments whether you were able to find such parallels. Fair warning: this works better if you’ve actually read the article first.Why Do Classic Waterfall Projects Take So Long?Let’s first understand why classic product development projects take so long. Based on that, we can consider where we want to start making changes.Classic Project PhilosophyClassic project management places the highest value on reducing financial project risk.It must be absolutely certain that large amounts are only invested and contracts are only signed when the content work is finished and the result is confirmed through complete validation.* New technologies are only developed when it’s certain they’re really needed in the market.* Suppliers are only selected and purchase prices negotiated when all technical specifications are known and their correctness is proven.* Costs for production tools and factory investments are only spent when the product has been successfully validated.* Customers and markets are only informed after project completion, so they don’t delay their purchase decision to wait for the new product.The cost of this certainty is having to accept a long development timeline before product availability.Well, and since everything is so certain, the investments can be high. If the business case shows a good payback, then this money is supposedly safely invested. - Or so the theory goes. -What Are the Problems?Let me say it right at the start: You can develop very good products with this classic approach! This has been proven in many successful projects in the past.However, all of life is a compromise, and so is the classic approach. Often this compromise is simply not the best compromise.Before I move on to a different approach, I want to address the problems and challenges that come with this classic approach.Not All Assumptions Are SafeTo gain certainty, decisions need a secure data basis.As just described, in classic vehicle development projects, this certainty is created by carefully and laboriously securing all decision premises before a decision is made.Unfortunately, it’s impossible to do this with all premises. Some premises inevitably arise for which assumptions must be made that cannot be validated.These premises now introduce risk into the project that it’s not prepared for and can’t handle well, because absolute risk avoidance is also a project premise.When these risks then actually occur, they throw the project off track.Decisions are reversed, setbacks in project flow cause time delays and excessive costs.Changes in the Environment Create InstabilityThis problem is amplified by the fact that, due to the long project duration, supposedly secure premises become outdated and generate volatility that leads to the same consequences.Sequential Work Is Always Connected with LoopsIronically, the effort to boost efficiency by having departments wait for validated data leads to considerable rework.* First the developers develop. * Then the purchasers negotiate with suppliers. * Production planners plan production next. * At the very end, the after-sales experts figure out how the product can be repaired. * The controllers always carefully ensure that money is only spent when everything is clear.When specialist functions start later, they inevitably discover issues with the supposedly validated data only at a later stage.The premises originally considered secure turn out to be wrong in the course of work, and the correction causes setbacks in project progress.Previously completed work based on the original assumptions must now be repeated.This causes time delays and significant inefficiencies.The Required Time Is Not AvailableThe worst problem is that there’s often simply not enough time for such an approach.Then the 6 to 8 year project plan is simply compressed like an accordion.Now it’s over with the secure premises!The lack of time leads to poor results that are inadequately checked.Occurring risks are no longer a regrettable exception but a certain reality.An organization geared toward certainty is thrown into chaos and is methodologically unable to deal with the chaos.This is the point where task forces, freestyle, and excessive resource and time expenditure become the project management method.Project goals are now secondary; now it’s only about being able to deliver at all.Alternative Approach - The Super SprintProject PhilosophyAn alternative to address these problems is to focus on speed instead of financial certainty.Although it may not seem so at first glance, it doesn’t mean that more money is spent.It only means that the supposed certainty is only proven late in the course of the project.* New technologies are prepared at a time when no concrete market need is yet recognizable.* Project goals are set conservatively and in close alignment with customers, without the expectation that the product must be offered unchanged for a long time. Quick availability and subsequent short-term further development are project premises.* All specialist areas work simultaneously and complete their stages at the same time. (You can read about the individual phases in DCVI in a separate article.)* Short-cycle planning and implementation phases enable situation-appropriate prioritization and proactive response.Solution to the ProblemsPredictive Technology ValidationTechnology development takes time, there’s no way around it.To understand technologies sufficiently well when they really need to be applied on a large scale, you can’t wait until the last moment.What seems like the most cost-effective approach – delaying investment until you’re absolutely sure – actually proves the most expensive.The better approach is to engage with the technology immediately and learn for little money and on a small scale.I’ll describe exactly how to do this in a separate article.This phase can be completed in a few months; for large, very innovative technologies, it can take one to two years including customer feedback.There are several important premises to maintain:* Everyone must participate, not just product engineering! Purchasing, production planning, after sales, even controlling must use this opportunity to acquire the necessary competence to assess and apply the new technology.* End customers must be involved and have the opportunity to develop qualified feedback. They must be part of the activity.* Over-development must not occur in this phase. When the technology is sufficiently well understood, pause until a concrete application project is started. When the time comes that the technology is needed in the market, the product can be developed quickly and without loops based on the identified market need and good knowledge of the technology’s potential.If the technology doesn’t meet expectations, it was better to invest little money in this realization than to bring the technology to production for expensive money because there’s no way back.The DCVI Project - The Super SprintWhen the time comes to start the product development project, the DCVI approach is applied.I know, I know. The agilists will criticize me. You can’t stretch a sprint over 4 years; then it’s not a sprint but something else.Fine by me, let me call it a “super sprint” then.Nevertheless, the approach used in a 1-week sprint also makes sense over a relatively long period.The approach consists of 4 phases that all involved employees complete together.* Definition - Everyone aligns specifications with each other. I really mean “everyone”! This is an exciting phase because nobody yet knows exactly how they will solve their problems. Nevertheless, it’s important that all concepts, strategies, and premises are integrated and coordinated with each other. This is the heyday of systems engineering. At the end of this phase, everyone looks each other deep in the eyes and knows what each individual’s result must be for the product to work in the end.* Creation - Now everyone develops the concrete solutions. Intensive teamwork is required here as well. At the end of this phase, the product and all its accompanying processes are theoretically finished. Again, everyone looks each other in the eyes and says with deep conviction: “I’m sure this will work!” But everyone also knows that no one can be completely sure because there’s no proof yet. The certainty is based purely on the professional competence of the involved employees.* Validation - The product is built and tested together with all accompanying processes. From now on, only what doesn’t work is fixed, and this must happen very quickly. At the end of this phase stands the question: “Are we really finished?”* Implementation - Now only the process capability of the large-series process remains to be installed.There’s naturally a lot to tell about each phase, so I’ll write separate articles about each.The Magic Word Is: SimultaneousFor the product to be developed in half the time, no one can wait for anyone else! All specialist functions work simultaneously and continuously align their work progress with each other.At the end of each of the 4 phases stands a milestone with a detailed review and the freezing of the work result achieved so far.For this highly integrative working method to function, organizational prerequisites and procedures must be implemented.A very important procedure is the Drum Beat and the project roles (project manager, project management master, product architect and functional unit representative) associated with it.At the end of the project, or as I call it, the super sprint, stands a deliverable product.Simultaneously, however, the next super sprint is already running, further developing the product and quickly implementing learned insights.How Long Do the Individual Phases Last?The secret is to take the time at the beginning to think carefully and work thoroughly in order to be fast at the end.* Definition - 1 year* Creation - 1 year* Validation - 1.5 years* Implementation - 0.5 yearsWe exclude technology preparation from the project timeline so that it doesn’t influence the period between project decision and series readiness.So, the product needs 4 years from project start to series maturity.After completion of the creative phase, the focus shifts from design to validation.At this point, the next project already starts with its definition phase.The customer thus receives an improved product every two years. They don’t even notice the four-year project duration.Software Is FasterEverything written so far considers the temporal restrictions that hardware places on the development projects of a commercial vehicle.Software development offers the possibility of being brought to market faster. Therefore, shorter software cycles are overlaid on the hardware cycle of 2 years.Now’s the right time to jump into the comments – I’d love to hear about similar experiences or parallels you’ve seen.We can also chat about this topic:I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.If you found this helpful, don’t forget to share it with others who might enjoy it too!I’d be very grateful if you shared my newsletter with your friends and colleagues. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Picture this: You're the leader of an organization that desperately needs to transform. You've identified the problems, you have a vision for the future, and you're ready to make it happen. But here's the brutal truth—most transformation efforts fail not because of bad ideas, but because of bad organization.As a leader, my job isn't just to spot what needs fixing. It's to analyze my organization, leverage our strengths, address our weaknesses, paint a clear and realistic picture of where we're headed, and—when fundamental transformation is necessary—make sure it actually succeeds.That's what real leadership looks like.Over the years, I've tried countless approaches to transformation. Some worked brilliantly, others crashed and burned. But the most recent transformations I've led have validated a core framework that I want to share with you today.Every organization, every team, and every challenge is unique. But certain principles hold true across the board—and knowing when to be flexible is just as crucial as knowing what never changes.The Top Management Dilemma: Three Levels of Executive EngagementLet's start with an uncomfortable truth:Without top management commitment, transformation is impossible.I think we can all agree on that. But here's where it gets tricky—what role should top management actually play? There are three main approaches, and each comes with its own set of challenges and opportunities.Option 1: The CEO-Led Transformation (The Gold Standard)This is my number one recommendation because it's simply the most effective approach I've seen.When the CEO or a managing director personally leads the transformation—not just announces it, but actually rolls up their sleeves and works alongside the team on both the vision and execution—something magical happens. Credibility becomes unshakeable. Priority and focus become automatic.But here's the catch: the leadership team must invest significant time working with the entire organization, not just a select group of elite employees.This approach is common in startups, and I've experienced it firsthand as a member of a startup's executive team. The efficiency is remarkable, which is why I strongly recommend choosing this option whenever possible.Of course, in the real world, there are plenty of reasons why this ideal scenario rarely happens. Which brings us to...Option 2: Top Management as the PrincipalThis variant comes into play when leadership can't dedicate the necessary time to personally lead the transformation but is fully committed to the transformation.Here, top management appoints a transformation manager and team that has their absolute trust. And I mean absolute—this trust is the foundation that makes or breaks this model.Management and the transformation team must speak with one voice and give the transformation identical priority. Even in this setup, leadership can't completely step back. They need to invest enough time to stay aligned with the transformation team and demonstrate the transformation in their own leadership behavior.When the organization sees this united front between leadership and the transformation team, acceptance follows.Option 3: Top Management as Participant (The Nightmare Scenario)This is the most exhausting variant with the highest risk of failure—and unfortunately, it's the one I've had to navigate most often in my career.The scenario goes like this: Everyone agrees transformation is necessary. Leadership is willing to provide resources—people and money. But they don't see themselves as part of the problem."The people down there need to transform. I'm fine and can keep doing what I've always done."Here's the harsh reality: in every transformation, top management is always affected and must transform their own thinking and behavior.In this situation, the transformation team must work on two levels simultaneously:* Achieving transformation with top management* Implementing transformation with the workforceThe real killer? The workforce picks up on mixed signals from leadership, which compromises the entire effort's credibility.If you're a transformation manager in this situation, don't lose heart. You'll need unbreakable optimism, but I can tell you from experience: it can work. It's exhausting, you'll face countless frustrating phases, and it takes much longer than the other scenarios—but it's possible.Pro tip: Don't be fooled by lip service. Top management rarely admits this attitude openly. Judge them by their actions and adapt your approach accordingly.Building The Transformation Dream TeamYour transformation team should consist of 3 people minimum (2 if you absolutely must), all dedicated full-time to the effort. If you get the luxury of more dedicated team members, take it gratefully—it won't hurt.The Transformation Manager is the brain of the operation. They define strategy and make tactical implementation decisions.The other team members discuss strategies with the manager, organize operational execution, and communicate throughout the organization.Here's what's non-negotiable: The transformation manager must be an opinion leader in your organization. Not in the sense that "everyone likes them," but in the sense that "when they speak, people listen." This usually requires seniority, though I've seen young professionals build this kind of standing too.Regardless of how leadership views the transformation, the transformation manager must have the complete personal trust of top management.The nature of transformation means no one can know exactly what needs to be done or where the journey will ultimately lead. Your transformation team needs solid baseline qualifications in the domain being transformed, keeping them at least two steps ahead of the organization in the learning process.Simultaneously, they must possess the leadership qualities necessary to guide an organization without being able to present a detailed roadmap.The Consultant QuestionTwo or three people aren't enough to transform an organization. At the same time, transformation is temporary—it shouldn't become a permanent state.This is why it makes sense to engage experienced consultants who can provide both capacity and content support. It's helpful when consultants have experience in similar contexts from other organizations.Even though consultants aren't cheap, don't be stingy here. Usually, your company's future is at stake—you must invest sufficiently to make success possible, even when creating a business case and payback calculation is challenging.The Middle Management Make-or-Break FactorHere's a truth that might surprise you:Middle management is the critical success factor for any transformation.* They're deeply involved in business processes enough to understand and help shape change. * They have the leadership experience and hierarchical power to get their employees on board.* But they also have significant influence upward. It's unlikely that top management will ignore middle management's opinions—if trust isn't there, the middle manager gets replaced. So you can assume the people in these positions have their bosses' ears.Your transformation team and middle management must pull in the same direction for organizational transformation to succeed.Take middle management seriously and give them your full attention. They're the critical factor determining success or failure.To ensure middle managers invest sufficient time in transformation while still handling day-to-day business, you must especially appreciate and focus on those with intrinsic interest in the topic. They're your gold nuggets—guard them carefully so they don't get lost.Project Organization: Creating Structure in ChaosYou can't work with everyone simultaneously, so you need a well-structured project organization.Consider which organizational units are represented by whom in your transformation project. Form sub-projects and appoint selected middle managers as sub-project leaders.Even though transformation isn't strictly a project (because goals and endpoints are unclear), you can and should use project management structures.I won't propose specific structures here since they depend heavily on your concrete situation. But if you want to discuss your specific scenario with me, send me a message or write in the comments, and we'll find time to talk.The Communication ImperativeThe final crucial pillar in your transformation framework is communication.Communicate intensively!* Communicate what you're planning* Communicate successes* Communicate lessons learned* Communicate immediate next steps* Communicate who's doing what* Communicate parallels to transformations in other organizations* Communicate praise* And more...Your transformation must always be part of the conversation, everywhere.Use every communication channel available in your organization:* Intranet* Email* Town halls* Quarterly calls* Newsletters* Communities* Training sessions* And moreBut use one communication form extensively: Talk to people. Discuss.Approach people in hallways, in the coffee kitchen, take them to lunch and talk about the transformation.Go into different functional areas and face the criticism—it will come, that's certain.Meet criticism constructively with a positive attitude, even when it might be unfair. It offers you an irreplaceable opportunity to get your arguments across and have people's attention.Don't get discouraged if you don't win every debate. Trust me, over time the desired effect will emerge—people will become more open to transformation and eventually start participating or even helping to shape it.But you must pay the price of investing incredible amounts of time in discussions and communication.The bottom line? Transformation isn't just about having a great vision—it's about building the organizational framework that can actually deliver that vision. Get the structure right, and change becomes inevitable. Get it wrong, and even the best ideas will crumble.If you have questions or suggestions, please write them in the comments.We can also chat.Would you rather message me directly?I'll dive deeper into project management practices 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. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Agile project management is based on Scrum. That's how it all started, so let's introduce Sprint meetings and Scrum boards first.Once that works, we can scale up and think about the higher complexity in projects.Makes sense, right? That's why I often see teams taking this approach.Noooo, that's not the right way to do it!I used to do something similar myself. Back then it wasn't called Scrum - it was called Shop Floor Meeting.But I found that it didn't really solve the problem. We still had issues with the quality of our development projects.So in this article, I'll describe how to do it better - a way that actually makes the problems go away.Starting PointI think it's important to thoroughly analyze the starting situation before any project, change, or transformation.So let's recap what we have and what we want to achieve with the Drum Beat method.We use classic project management in our projects, just like it says in the IPMA textbooks.Well, we say we work according to IPMA. In the end, it's probably more like freestyle.* We have a project plan, * project managers, * project team members, * and defined project roles. * We also have quality gates, * milestones, * and quality gate deliverables. * We have project traffic lights, * reporting, * risk management, * and project documentation.That's good news because it means we don't have to start from zero. There's a foundation we can build on, even if it's not perfect yet.What were the problems I wanted to avoid with the Drum Beat method?* The project plan doesn't work as desired.* Deliverables for quality gates and milestones are delivered poorly.* Project budgets and timelines get out of control.* Quality and performance of the developed product is compromised.The next step was to identify the root causes of these problems and define countermeasures.These countermeasures are the processes and roles I've explained in my previous Drum Beat articles.To find the smartest implementation approach, I need to look at these causes again and prioritize them. I can't tackle everything at once - that would overwhelm people in the organization and possibly ruin the whole implementation.Here's the prioritized list of causes:* Project milestones are too long-term and too big* Poor prioritization of project activities by importance* Too late identification and correction of plan deviations* Poor resource management* Poor coordination of project activities between service providers and recipientsBased on this analysis, I can now stagger the introduction of Drum Beat elements over time. This way, I first create the prerequisites that enable the implementation of further process steps.Here's how it works:Step 0: Project Plan and Project TeamAs I mentioned at the beginning, the project plan and project team already exist.Even though they're far from the state I think is necessary, we'll leave both as they are for now.The project plan is good enough to provide guidance for how the project should flow, and the project team is motivated to implement the plan.That's enough as a foundation for the start. We won't waste energy improving this now - we need to work on more important issues first.Only later, when the team has a clear understanding of what Drum Beats and ToDo Sprints can deliver, will we have the foundation to take the project plan to the next level.Step 1: Define Drum Beat DeliverablesThe change starts with Drum Beat Deliverables.Drum Beat Deliverables are the heart of the transformation because they give the team a clear understanding of priorities in project work and management.Only when Drum Beat Deliverables have sufficient quality can the other process steps produce meaningful results.For this reason, the project management team must first learn how to derive and properly formulate Drum Beat Deliverables from the overall project plan and the current project status.This isn't easy when you've never done it before. That's why it's important to support this implementation step with trained resources.We need people who already know how to do this and can provide guidance and assistance to the project management team.The transformation team itself needs to be involved in the planning and provide guidance to the team.Usually, this manpower won't be enough either. We also need external consultants with agile project management training.So everyone speaks with one voice, the transformation team and consultants must align their concepts before planning begins and agree on a common understanding. It's recommended to practice Drum Beat planning beforehand.On this basis, both can now work together with project team members to define Drum Beat Deliverables and develop the templates I described in my article "Drum Beat Deliverables Create Clarity - and Deliver the Truly Relevant Results."You will notice that Drum Beat Deliverables show strong qualitative improvement over the first three to four Drum Beats. I recommend adjusting the method slightly after each Drum Beat.In this case too, you should do a retrospective after each Drum Beat and implement what you learned in the very next Drum Beat.Even though the following process steps aren't implemented yet, you'll still notice an improvement in project work. This is important because it promotes acceptance of the method.Pay attention to positive feedback from the project team and make sure it's noticed throughout the organization.Step 2: Conduct Planning EventEven the first Drum Beat planning ends with a Drum Beat Planning Event.At the beginning, this will also be organized and moderated by the transformation team and consultants.The entire project management team is present. The functional area representatives on the project management team take on the role of functional area teams in one person.We don't want too many people involved at the start so it stays manageable during this rough phase.We pay the price that the actual project team isn't involved yet and can only be informed about the results afterward.It's clear this leads to poor understanding and commitment from the project team. We have to accept this.The priority is first to enable the core project management team and establish an initial content foundation.Step 3: Implement Project RolesAfter Drum Beat Deliverables are introduced and the team can produce sufficiently good results with support, we now need to ensure the team can manage on its own.For this, we need to implement the new project roles.Usually, the project will already have a project manager. So we need to select, train, and coach: * a Project Management Master, * a Project Architect, * and Functional Unit Representatives We also need to redistribute responsibilities.The project manager gets relief and focuses more on project content flow, while the Project Management Master takes responsibility for the method and the architect for the product.The transformation team and consultants step back more and more, hand over responsibility for the process to project team members, and only support when necessary.Step 4: Implement ToDo Sprints in Pilot TeamsNow we've created the foundation. The Drum Beat Deliverables have quality that reliably provides guidance, and the project management team can independently plan, formulate, and manage DBDs.Now it's time to involve the implementing functional teams.The transformation team and consultants shift their focus from the project team to the functional area teams.Project team employees now need to plan the activities required to realize Drum Beat Deliverables into ToDo Sprints.This needs the same kind of support at the beginning as we organized for the project management team in step 2.Since support resources are limited, we focus on selected pilot teams at first. We identify teams that are particularly relevant to project results and whose employees are open to the new method.These teams are now also included in Drum Beat Deliverable planning and planning events.Even though only the pilot teams are currently implementing ToDo Sprint planning, all other project employees are already being trained. This way they are prepared for the next step and won't have forgotten what they learned when they need it.Step 5: Roll Out ToDo Sprints CompletelyIn the next step, our pilot teams serve as role models for the rest of the organization's employees.Now everyone participates in the ToDo Sprint Planning.The pilot teams' ToDo Sprint backlogs serve as examples, and pilot team members are available as contacts for other teams. This significantly increases the number of employees available for guidance, so we can provide adequate support to all employees despite limited resources from the transformation team and external consultants.Step 6: DashboardsNow all process steps are implemented.To work with planning and continuously improve processes and results in a targeted way, we now need dashboards that show the project team how DBD and ToDo processing is going.Of course, we've had DBD and ToDo boards available and used them in our project management tool from the beginning.But now the focus shifts from the content of DBDs and ToDos to their flow.The transformation team and consultants now support the project team in working with the boards:* Are DBDs and ToDos properly moved from “Backlog” to "In Process" and "Done"?* Is the "Roadblock" column used correctly?* How does the team work with statistics?* Are emerging delays addressed in time?The implementation focus shifts from planning to execution.Step 7: Perfect Project PlanSo the new process steps are now implemented.Now we can return to the project plan and adapt it to the new method.Since we now map many planning scopes and activities through Drum Beat Deliverables and ToDos, we can streamline the overall project plan so it really only contains the essential and long-term relevant planning components.It should provide guidance for DBD planning but not create duplication in planning. I like to refer to an old engineering rule. Maybe some of you still know this rule, even though it comes from a time when technical drawings were still drawn with ink on transparent paper:"Each dimension may only exist once!"The background is that contradictions are avoided by having no duplications. If a dimension exists only once, it can be wrong but not contradictory.This principle also applies very well to planning and avoids one cause of misunderstandings.It means each task should only exist once in planning. What's in the project plan shouldn't be in the Drum Beat backlog, and vice versa.7 Steps Take TimeSo I've divided the implementation into seven logically connected steps.It follows agile logic - always focus on the next important step and implement MVPs instead of waiting and doing everything at once.Due to agile thinking, there's a retrospective after each Drum Beat, and we improve the identified potential in each following Drum Beat, so we become better, more efficient, and more effective.Want to introduce Drum Beat in your organization and still have questions?Write them in the comments and I'll try to answer them to your satisfaction.We can also chat.Would you rather message me directly?I'll dive deeper into project management practices 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. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

As a product development leader, I regularly attend project review meetings where we discuss the status of important product development projects. In these meetings, project teams typically present two very different types of topics to top management:1. Technical Concepts and Product Performance ReportsFor these agenda items, project teams seek management confirmation and approval for technical approaches and performance metrics. In these cases, management takes an active role in the decision-making process, providing valuable input, strategic direction, and meaningful oversight that actually adds value to the project.2. Project Delays and Missing ResultsThe second type of agenda items puts management in a completely different role. Here, project delays and missing deliverables are presented in detail. Teams explain what went wrong and outline their plan to mitigate the consequences of this mess. These presentations carry an undertone of: "We want you to know how critical the situation is. Don't be surprised if things ultimately go wrong - everything we're doing is without alternatives because lost time cannot be recovered. We hope the plan works, but you can't help us anyway." There's not even an expectation that leadership can still help. And believe me, these agenda items are no fun for management!To change this situation for the better, I've been exploring how to prevent it from happening in the first place.There must be a way to manage projects so that critical delays don't occur at all.However, if they do arise, the goal should be to present decision alternatives to management early enough so their decisions help prevent problems from escalating in the first place.If we succeed in this, management will have a positive value contribution for both types of agenda items. And ideally, the project team will solve problems early enough that many of them will not need to be reported at all.One aspect of the solution is the "Drum Beat" that I've introduced in previous articles. This helps project management teams plan more realistically, recognize project risks earlier and proactively avoid problems through better planning.The other important aspect that needs to be addressed is guaranteeing proactive work management in functional departments. Since project content is created in functional areas, these employees must be included in solving the problem.The method to achieve this is the ToDo-Sprint - designed to make task processing more prophylactic, effective, and integrated. I'll focus on this aspect in today's article.But first, let me dive deeper into the fundamental root causes of project delays. I'll explain the causes I've identified so you can consider whether these might also exist in your organization.From these causes, you'll understand why a combination of Kanban and Scrum can solve the problem.Multitasking Needs Clear PrioritiesI work in a matrix organization.In my article "Mastering the Matrix" I wrote about the special characteristics this involves. Take a look at that article - it should help you to understand this point better.When project organization (as process organization) and functional organization (as structural organization) are arranged in a matrix, there's typically no unique assignment of employees to projects. A functional team works simultaneously, but with different intensities, across multiple projects.Without a process to synchronize, prioritize, and organize all these tasks - as was the case with us - tasks remain uncoordinated. The affected project learns too late what won't be delivered in time, putting it into a reactive mode where it shouldn't be.We need a working mode that ensures project-wide planning of all activities within functional area teams.Since we're talking about teams with normal employee numbers (5 to 10 people), we can use a setting similar to agile Scrum.Employees plan their activities together in short cycles, considering the concrete situation as it currently exists.To avoid ineffective multitasking, we need "timely dedication" - temporary focus on a single activity planned so that all important results for all projects can be delivered. This means that while work may be done on multiple activities for different projects within a sprint, at any specific time (hour, day) work is done on only one task. Only when that's completed is the next one tackled.The Scrum Board structure with categories Backlog, In Progress, and Done works perfectly for this.The "Roadblock" category signals urgent support needs for the team.With this approach, emerging problems are recognizable on a quarterly or weekly basis, and solutions can be sought and found proactively before time runs out.Capacity is ObjectiveThe truth is brutal and unavoidable: capacity is finite.Because this insight is so uncomfortable, management tends to use the ostrich method - sticking their heads in the sand and preferring not to talk about it."They'll figure it out somehow. They should just try harder, then it'll work."This attitude puts management in the position of later sitting helplessly in project reviews, feeling bad anyway.It's a non-delegable management task to consciously evaluate whether it really "still works" or whether resources are objectively insufficient and decisions must be made.I'll explore what decision options management has in these situations in a future article.But to even be able to decide, there must be a planning process where these cases are uncovered early and prophylactically, showing the team and the management the decision alternatives.The Scrum approach also helps with this problem.Since planning occurs over short-term intervals (quarter, week), resource availability is easily assessable. The workload is also concrete since the status quo on which the activity builds is clearly on the table.Functional area management must engage with the results of Scrum planning and either make necessary decisions immediately or acknowledge decisions the team has made and consider them in leadership actions.I recommend briefly reviewing the Scrum planning of all teams in a functional area during regular area leadership communication and sharing critical issues.Avoiding Interrupted FlowNothing is more frustrating than having to wait for input and helplessly watching your own deadline wobble because you can't work on the topic.That's why it's helpful to look during planning at who needs what when from whom, so inputs are available at exactly the right time.When coordination between affected colleagues (I call them service provider and service recipient) isn't organized and methodically structured, workflow stagnates."It was obvious I needed that. It's always like that. You should have known.""We talked about it - why didn't you do it?"A well-organized planning method is needed so these detailed plans happen timely, completely, and sustainably, allowing all employees to work efficiently on important tasks in an uninterrupted and unhindered flow.Here I draw on the pull principle from Kanban.For this to work well, there are some rules to follow.ToDo Sprint Rules* Each employee is personally responsible for ensuring that required inputs are clearly and unambiguously defined and communicated to contributing colleagues.* Inputs are scheduled so results are available exactly when needed for further processing. This creates no inventory and results aren't overtaken by time.* Each team member plans their own activities. When a task is scheduled, it signals a commitment that it will actually be completed.* The requester is responsible for scheduling with the service provider. If they can't agree with the service provider, they must seek alternatives or organize escalation. (Escalation isn't negative here - it's involving additional resources to solve the problem.)* Tasks with no requester are omitted. (What nobody needs doesn't get done.)* When problems emerge during processing, the service provider must immediately contact the requester and involve them in solving the problem. (Maybe it can be done with less after all.)Point three is especially important to me because it ensures that whoever has to do something has actually "bought" that assignment - firmly committed to actually doing it.The ToDo Sprint ProcessThe ToDo Sprint approach isn't rocket science and resembles many known frameworks.* Drum Beats are divided into one- or two-week ToDo-Sprints, each getting a backlog with tasks to be completed in each sprint.* During Drum Beat planning, these backlogs are filled for each sprint of the Drum Beat.* During Drum Beat planning, resource availability and task dependencies are also considered.* By PED (Planning Event Drum Beat), there's an initially filled backlog for all ToDo-Sprints of the new Drum Beat.* Each new ToDO-Sprint starts with a review of the previous sprint.* Based on review results and current project situation, the backlog for the coming ToDo-Sprint is updated and refined.* ToDo-Sprint planning is discussed in functional area regular communication.* After completing ToDo-Sprint planning for the current sprint, each team member independently moves their tasks into "In Progress" and "Done" columns.* When a team member moves a task to "Roadblock," line supervisors and the Drum Beat Deliverable Owner step in and support resolving the roadblock.I haven't tried it yet, but I'm still considering setting up a parking area on the ToDo Board where requesters can park their required inputs for backlog planning.Another important point to consider: for every task on the ToDo Board, the recipient of the deliverable is noted!It's also not enough to just describe the task - the expected outcome of the activity must be clearly defined between the service provider and service recipient on the ToDo Board.How much detail to include is something both parties must decide together. What's important is that they agree on the required result. I believe the more detailed it's written down, the more confident you can be that you truly understand each other.The ToDo Sprint Combines Agile Sprint and Lean KanbanFeatures from Agile Sprint:* Fixed timeframe* Team plans work for the coming sprint together* All tasks are visible to all participants* Shared understanding of goals and progress* Regular review of work results and processes* Early recognition of deviations* Immediate correction when problems are identifiedFeatures from Lean Kanban:* Pull principle - only tasks that meet concrete needs are completed* Focus on continuous flow - all activities are scheduled so no "inventory" or "overproduction" occurs* Each backlog item represents a deliverableIn this article, I've described how project work in functional organizations can be organized so that threatening project delays are recognized early and prevented as much as possible.I'm sure there will be many more questions about this. If you have questions about this topic, don't hesitate to ask them in the comments.We can also explore your questions in chat or via DM.I'll dive deeper into project management practices 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. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

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.ReviewUnless 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 WorkIn 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.PrioritizationWhile 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 PlayIn 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 DemocracyYes, 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 ActivitiesAfter 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 PEDThe 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 BeginsIf 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. 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 DeliverablesLet'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 implementationThis 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.TitleThe 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 operationalDrum Beat 2 – First system design is completedDrum Beat 3 – Basic function development is completedEtc.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 operationalDrum Beat 1 – Development suppliers for cab components are selected and operationalDrum Beat 2 – First system design for chassis is completedDrum Beat 2 – First system design for cab is completedDrum Beat 3 – Basic function development for chassis is completedDrum Beat 3 – Basic function development for cab is completedIt 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 ResponsibleThis 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 LevelThe 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 BeatAt 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.RecipientThis 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 DeliverableThe QG Deliverable informs which Quality Gate Deliverable the Drum Beat Deliverable contributes to.StatusThere are the following statuses the DBD can be in:* Backlog* In Planning* In Progress* Done* Blocked* Spill OverMost 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 / IntentThis 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 DoneThe 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 ReadyThe 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 / ImpedimentsPotential 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.ParticipantsThis section lists the key teams or team members who must contribute to the deliverable.An ExampleSo 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. 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 DoneEvery 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 PlanningThe 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 OptimalUsually, 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 SolutionThe solution to the problem consists of conducting detailed planning in an organized, structured, and methodical mannerThe 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 DeliverablesA 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 PlanningOnce 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 ActivitiesAt 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 OversDespite strong focus on reliable delivery of agreed work results, it will always happen that something hasn't been completed.We call this a "Spill Over."It's important not to simply push these matters forward. They must be re-planned.The first question is whether this activity, now delayed, is even still meaningful at this point.In any case, we must prevent the first schedule delay from becoming a chain of schedule delays.The goal must be that by the end of the next Drum Beat, the delay is caught up and no impact on the overarching project plan occurs.Why Drum Beat and Not PI?Isn't the Drum Beat simply a PI as defined in agile project management methods?The answer is: Yes and No.Just like a PI, the Drum Beat is short-cycle planning that follows a strictly prescribed schema.The sequence of planning, implementation, and review/retrospective is the same.However, at the end of the Drum Beat, there's no ready-to-ship product that generates short-cycle customer feedback and thus provides new insights for further development of the product.This isn't realizable with a hardware product like a vehicle.In this regard, the Drum Beat is more comparable to a classical quality gate. It represents a milestone on the path to the next quality gate, just as the quality gate is a milestone on the path to the project goal.However, the Drum Beat isn't planned out from the beginning of the project like the quality gate.I would describe the Drum Beat as a hybrid mixture of PI and quality gate that realizes the advantages of agile approaches under the special restrictions and premises of a hardware development process.After reading this article, many questions are going through your head?Then don't hesitate to ask them in the comments—I'll try to answer them to the best of my knowledge.We can also chat about this topic.I'll dive deeper into the details in the coming articles. Please subscribe to the newsletter so you don't miss them.If you found this helpful, don't forget to share it with others who might enjoy it too!If my newsletter resonates with you, please consider sharing it with others. Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

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” ProjectsDevelopers 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” ProjectsThe 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 ProjectsWith 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 TimeUnlike 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 TechnologiesHow 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 ExpectationsThe 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 ImprovementsLet'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. 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 ProjectThe 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 errorsIn 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 DevelopmentIn 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 assignedAt 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 componentsConcept 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 DevelopmentIn 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 VerificationIn 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 VerificationIn 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 OverviewLet'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. 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 ProblemA 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 RisksRisk 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 itselfDo you have other alternatives for how risks can be found? Then please write them in the comments!Evaluating RisksOnce 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 MeasuresOnce 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. 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 OrganizationWhenever 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 deliversThe 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 AreaIn 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 StructureThe 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! 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 EngineerThe 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 projectThe 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 ArchitectThe 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 TrinityIn 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! 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 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 OrganizationWe 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 OrganizationBoth 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 OrganizationUnlike 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 ComplexityIn 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 OrganizationClear Assignment of ResponsibilityThe 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 DeliversThis 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 RulesClearly 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 FocusTo 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 OrganizationTo 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! 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 PlanningOnce 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 ManagementRisk 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 ActivitiesI 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 AssistantThe 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! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

The moment an employee is assigned responsibility for a project, they know: Something extraordinary begins—from tomorrow onward, their world will never be the same!Does the Project Manager Know Their Responsibilities and Tasks?How does a project manager know what's expected of them?What determines their success or failure?And what decides whether they'll be celebrated as a hero or condemned as a failure in the end?Well, finding answers to these questions isn't simple. In some organizations, project managers have clear guidelines and best practices to follow, while in others, expectations remain frustratingly vague.Ideally, a Project Management Office exists to define project roles, assign responsibilities, establish rules, and outline procedures.When top management elevates this framework to a company standard and aligns their evaluation criteria accordingly, project managers can inform themselves and act appropriately.This brings us to a crucial point:The responsibilities and tasks of project managers must be specifically defined in every company, as well as the responsibilities and tasks of other project members.While agile project management methodologies offer clearly defined roles with corresponding tasks and responsibilities, traditional project management approaches (IPMA, PMI, etc.) remain much more open to interpretation.The framework conditions provided by the Project Management Office aren't always optimal for efficient project management and successful projects. All too often, these guidelines contain gaps or leave too much room for interpretation.The greatest challenge for project managers arises when management has expectations they're unaware of or objectively cannot fulfill. The situation becomes particularly critical when the project performs poorly and fails to meet its objectives. In such cases, the blame game begins, and all eyes turn critically toward the project manager.However, assigning responsibilities and tasks properly isn't just about the project manager's fate. It's about the project's destiny and perhaps even the company's future.When expectations placed on project managers exceed what they can realistically deliver, yet the project's success depends on meeting those expectations, failure becomes inevitable.I hope this introduction clarifies why properly defining a project manager's responsibilities and tasks is absolutely critical.Drawing from my experience and observations, I'd like to present some suggestions as to which responsibilities a project manager should take on under all circumstances.I hope my arguments convince you. You can assess the approaches in your environment that create favorable conditions for the success of projects — and thus of project managers.These Responsibilities Should Be Assumed by Project Managers:Responsibility for Project ObjectivesAt the top of my list comes responsibility for project objectives. They are, after all, the very reason the project exists. If objectives aren't met, the project fails to deliver the impact for which it was initiated. Against this background, it's logical that project managers must be responsible for achieving project objectives.But beware!Project managers don't have the task of achieving project objectives! That must be done collectively by all project participants.What exactly does responsibility for project objectives entail?Let's take a look at the primary project objectives that play a role in every project:* Performance* Cost* TimeThis is the magical triangle of project management. The term itself indicates that it represents a compromise.Time, money, and performance are interdependent. Greater performance typically requires more resources and time, and vice versa. You can also buy time with money by deploying more resources, which naturally must be paid for.The project manager's responsibility is to ensure that the compromise, established as the project objective, represents a realistic compromise.To accomplish this, project managers must:* Be convinced that all three objectives can be achieved simultaneously.* Have a concept of who can realistically contribute what toward achieving these objectives.If the assigned goals are not all achievable at the same time, then it becomes the project manager's task to negotiate a new, but then feasible, compromise with the relevant stakeholders and bring it to a decision.Sounds logical, right?However, it's anything but trivial and places high demands on project managers.They need extensive experience to assess what's realistic and what isn't. While they'll gather information from their team, ultimately they remain responsible for judging whom to believe and where more might be possible than team members trust themselves to deliver or are willing to commit to. Similarly, they must recognize when the team might be taking on too much and making unrealistic commitments.It requires extraordinary courage to tell stakeholders (who are often top managers) that not all wishes can be fulfilled.Company culture plays a crucial role here. In a trust-based culture, project managers find it easier to propose realistic compromises to stakeholders. In cultures dominated by fear and power, one should consider whether being a project manager in such an organization is even desirable.Let's take a look at the secondary goals. In addition to the three main objectives present in every project, there are also additional, often project-specific objectives.Project managers bear responsibility for ensuring all these objectives are clearly defined and communicated to all project participants, from stakeholders to team members.Responsibility for project objectives consequently includes monitoring the achievement of these objectives throughout the project. For this purpose, project managers use metrics that help them recognize when problems are emerging. When this occurs, it becomes their task to initiate organizational measures to remedy the disruption or solve the problem.Since primary project objectives have three dimensions, KPIs must naturally monitor all three dimensions. This requires metrics that show the maturity level of performance development, metrics that show budget expenditure, and metrics that measure project progress over time.Responsibility for the Project PlanIt is the project manager's responsibility to assign the right tasks to all project participants at the right time.For this, they must manage the project plan.What does managing the project plan mean?First, they must develop a complete plan detailing which activities are necessary, which resources are required, and what dependencies exist between activities.On this basis, they then direct the respective project members.The project manager is the one person in the project who precisely understands what must happen for project objectives to be achieved.In reality, the initial plan won't work exactly as envisioned. That's why I say they must manage the plan. This means they must direct the necessary activities to make the plan work. When they recognize that deviations from the plan are necessary or beneficial, they must adapt the plan.I interpret responsibility in this aspect extremely strictly. The project manager alone decides when and how a plan is adjusted. For this purpose, they naturally gather information and decision recommendations, just as any good leader does when decisions need to be made.Too often, I experience project team members urging the project manager to change the plan because it doesn't suit them. They want more time, they demand additional prerequisites, and so on. This is toxic.I want project managers to bear sole responsibility. They dictate how things proceed and bear responsibility for ensuring it works.Every project team member contributes to making the plan function.This creates potential for conflict. Therefore, another role is needed to mediate between the project manager and the project team—the Project Management Master role. (Feel free to come up with your own name for it. In the agile context, the Scrum Master is positioned quite similarly.)I'll describe the responsibilities and tasks of the Project Management Master's in a separate article, so subscribe to the newsletter to avoid missing it. Responsibility for Risk ManagementI consider it self-evident that project managers are also responsible for risk management. This is, after all, a prerequisite for increasing the probability of achieving project objectives.Since project managers are responsible for achieving project objectives, they should also be the ones who best understand what could go wrong. Having recognized potential risks, they must ensure measures are taken to minimize these risks and make their occurrence as unlikely as possible.For this purpose, they use classic risk management methods as extensively described in project management frameworks.To briefly summarize, here are the tasks they must personally complete in risk management:* Identify project risks.* Evaluate project risks regarding the severity of impact and the probability of occurrence.* Develop risk mitigation measures or backup strategies for critical risks.* Incorporate risk mitigation measures into the project plan.* Verify implementation of measures.* Immediately activate backup plans or initiate recovery activities if risks materialize.Stakeholder ManagementThe final responsibility involves continuously informing project stakeholders about the project's status and ensuring coherence between stakeholder expectations and anticipated project outcomes.This can have several dimensions:* If it becomes necessary or beneficial to change or adjust project objectives, project managers must agree on this with relevant project stakeholders or secure necessary approvals.* Regarding customers, they must ensure that solutions developed within the project address the problems customers need solved.* If multiple interdependent projects run simultaneously, they must remain in contact with the project managers of other projects or with program/portfolio managers to ensure these interdependencies don't cause problems. They must consider these dependencies in their risk management.What Are Project Managers Not Responsible For?Oh my, that's a long list! For this reason, I won't enumerate everything here.Subscribe to my newsletter to receive articles about the responsibilities and tasks of other project participants. The matters for which I see other roles bearing responsibility automatically fall outside the project manager's responsibility.To put it briefly, the project manager's responsibility consists of planning and controlling, while the team and other project roles are responsible for execution and implementation. If problems arise, the project manager must escalate them, but others must take action. If they don't do so, this should not be held against the project manager.Too often, I have experienced the project manager being held responsible for this. Not infrequently, this comes from those whose responsibility it actually is.It's important to note that in English, 'control' in project management is often misunderstood when translated to German as 'Kontrolle' (which implies checking or monitoring). What I actually mean is 'steuern' - the active process of steering, guiding, or directing the project toward its objectives.So, please be attentive and analyze emerging problems carefully. If you are a manager or stakeholder, listen to the project manager about where you need to provide support and don't hold them responsible when the team or organization doesn't deliver what the project manager requested.Does the Project Manager Work Alone or Have Staff to Help Fulfill Their Responsibilities?This is a fascinating question that I know has very controversial answers.My opinion on this topic is absolutely not undisputed, I'm aware of that. Nevertheless, I want to present it here.I believe project management is a full-time job.A project is properly scoped when a highly qualified and experienced person can fulfill the aforementioned responsibilities alone and remains fully occupied doing so.I'm not a fan of scenarios where project managers have a flock of helpers exclusively assisting them without bearing their own personal responsibility.If project managers aren't fully occupied with the tasks and responsibilities described here, then the project is too small and consequently suffers from inadequate focus. If project managers can't manage alone, then:* The project is too large and should be intelligently divided into multiple projects, possibly bundled through a project program.* They're insufficiently qualified and the wrong person for the job.* They're doing things that aren't their responsibility, and measures must be taken to ensure the right roles complete their tasks and can fulfill their responsibilities.ConclusionJust as primary project objectives have three dimensions, project manager responsibilities also have three dimensions:* Securing project objectives* Managing the workload* Reducing risks and solving problemsThis keeps project managers fully occupied, leaving no time or attention for other matters. Hence, these have to be dealt with by other project participants.I could probably write an entire book about this article's subject. However, I don't plan to do that at the moment. Let's discuss in the comments or chat about which additional aspects or deep dives particularly interest you and what questions you have. Then we can either exchange ideas directly, or I can write further articles on these topics.I'm really interested in your opinion. Please write your thoughts in the comments, or let's exchange ideas on this 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! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

As a teenager, I tinkered with my motorcycle, always trying to improve it. Today, we call this tuning or customizing.It was my childhood dream to develop vehicles—a dream I almost didn't dare to have. In my twenties, it finally happened. I landed my first job as a design engineer in vehicle development, and shortly afterward, a new vehicle development project began.Can you imagine how proud and excited I was?Since then, I've had the privilege of contributing to many vehicle development projects, with increasingly greater responsibilities. I've tried other jobs, but quickly returned to development work.Product development is addictive, mainly due to the emotions connected with this work:* The excitement when a new project launches.* The stress and fear when you think you won't make it, and everything's going wrong.* The nervousness when driving a prototype vehicle, hoping you'll make it home without breakdowns.* The pride when the vehicle drives onto the stage at the world's largest trade show for its global debut.* The joy, when you encounter your vehicle on the highway.Many of the negative emotions you'd rather avoid can come from the misapplication of waterfall project management methods.Like any methodology, waterfall project management has advantages and disadvantages. You can mitigate or avoid the disadvantages if you're aware of the pitfalls and adjust your approach accordingly.I'll discuss several of these pitfalls below and hope this helps you to avoid them, making your projects run more smoothly, whether you're developing vehicles or other exciting products.Lack of Discipline in Early Quality GatesA characteristic of waterfall projects is a structured project plan with milestones and quality gates. This plan can span several years from project start to completion for large projects.The project plan details individual activities, documents dependencies between work steps, and defines the required deliverables for each milestone or quality gate.Here's where the discipline challenge arises:I frequently observe that delivering results for early milestones and quality gates isn't taken seriously enough."We still have years until the product needs to be finished. We'll somehow make up for this small delay."If the project is comfortably planned with sufficient time reserves, this might even be true. However, I've never encountered a project with this luxury. The project schedules I know are always best-case plans from the start, with no provisions for things going wrong.In this situation, carelessness is extremely dangerous. It leads to cumulative project delays in later phases, creating an unmanageable situation.The consequences are poor product quality, excessive costs, and late product delivery, which affect the company's profitability and always cause unpleasant feedback.Solution:* Treat every milestone and quality gate as if it were the end of the project.* Immediately initiate special measures when delays appear imminent to recover quickly.* Prioritize the project from day one. No project should be treated as a second priority just because the delivery date is far away.Continuous Replanning Distracts from ImplementationThis second pitfall is closely related to the first one.When project delays occur, it's tempting to completely replan the project to supposedly ensure it has a functional plan again.This is not good!I strongly advise against this for these reasons:* Replanning itself consumes resources and time needed for executing the plan. The effort required for replanning only enlarges the problem that has already occurred.* When it becomes known that replanning is underway, people might halt work until the new plan is ready. Project participants might also take more time before it's clear what the new plan will be.* Once a project plan is published, many smaller, sometimes personal plans develop based on it. These aren't published because they don't require coordination with others. As long as these plans serve the overarching project plan, they don't necessarily need to be published. However, replanning the overarching project destroys these smaller plans. This means not only does the project management have to do planning work, but many other project members have additional planning work too. The problem typically grows over time because it's impossible to maintain this evolved understanding of a functioning approach congruently.Instead of creating a new plan, do everything possible to quickly return to the original plan.Solution:* Avoid replanning the project like the plague.* Do everything possible to return to the project plan as originally designed at the start of the project.* React immediately to threatened project delays and take measures to avoid or quickly recover from them.* Plan realistically and avoid "tension factors".Project Goals Changed During the ProjectRepeatedly questioning and revising the agreed-upon project goals is a bad practice that destroys project plans.This is where project stakeholders must step up!I frequently hear the excuse that:* the world is so volatile, * that competitors make surprising moves, * and that customer priorities suddenly shift.Trust me—in 90% of cases, it's not the world's fault. It's poor project preparation, characterized by unprofessional market analysis, incompetent product management, and flawed product strategy.Once this problem has occurred, it's usually irreparable.In classic project management, this should lead to terminating and restarting the project, which naturally causes corresponding delays in product completion.The only solution is to work very professionally from the beginning and invest the necessary effort and resources at the right time, meaning very early. The overall efficiency of the enterprise will benefit.Solution:* Verify the quality of the project goals immediately at project initiation.* Agree with stakeholders that goals are final and that significant goal changes will lead to a project restart.The Project Management Tool is Misused as a Communication ToolWith this pitfall, you might shake your head and think, "This doesn't happen; it doesn't occur in our environment!"That might be true—perhaps this pitfall truly doesn't exist in your environment. But perhaps you should take a closer look just to be sure.A characteristic of waterfall project management is planning and documenting all activities in a comprehensive project plan, complete with dependencies.When I need an activity from another employee, department, etc., I ensure this activity is included in the project plan. To be safe, I add a dependency to my activity, making it clear that I need this!Properly, there must still be an agreement between the two parties involved. I must ensure the person responsible for the predecessor task understands exactly what I need and why. Are they able to deliver what I require?This is the communication that must absolutely occur.The pitfall consists of omitting precisely this communication."I've made sure everything is in the project plan; now the others should ensure it happens. From now on, I'm entitled to it."I don't even want to suggest the malicious thought that the absence of the predecessor's result also provides a good excuse for not delivering myself.This pitfall doesn't exist in agile project management because the method forces communication. In classic project management, the project team must be very attentive and experienced to avoid this trap.Solution:* Organize planning workshops where the project flow is discussed among all participants.* Ensure planned activities are checked for feasibility by the responsible project members.* Make each project member responsible for procedurally monitoring the prerequisites for their own work packages and taking action when deviations occur.Excessive Focus on HardwarePeople love to have something tangible to hold and try out.When developing hardware products, this tempts us to order prototype parts and assemble product prototypes as early as possible.The problem with this approach is that mistakes here are particularly time-consuming and expensive.It's pleasant not to think for too long, because thinking is exhausting. Just putting things together—if I'm lucky, it will work on the first attempt, and I'm done. If it doesn't work, then I have a problem I can analyze and solve.Both approaches avoid the cumbersome process of thinking through all possible risk scenarios, finding risk mitigation options, and preventing potential risks.It feels pedantic and tiresome. It takes time before you can touch and experience something. Therefore, it requires much discipline and consistency to complete work on the virtual product before hardware procurement begins.The reward is that by the end of the project time, fewer unsolved problems remain!Solving problems in hardware development requires lengthy parts procurement and prototype modifications, time that's typically unavailable. This causes stress, project loops, and replanning—all consequences that shouldn't occur.Not infrequently, the delivery date arrives before we've even reached the peak of error elimination.Solution:* Conduct thorough and in-depth product reviews before beginning validation involving hardware.* Have the team jointly assess whether the development's maturity level is sufficient for hardware procurement.* Implement careful risk management in the project, methodically identifying all risks, finding measures, and evaluating their effectiveness.Software Delivered Too Late and ImmatureThis pitfall occurs with mechatronic products.To test the mechanical part of the product, prototypes must be built and checked for durability. This requires months, sometimes years.Software development doesn't have these restrictions. Software doesn't wear out, so validation happens much faster.This misleads software developers into the false assumption that they have plenty of time until the product needs to be completed.However, with a mechatronic product, the mechanical hardware cannot be validated without functioning software.Consequently, the software must function much earlier than might be necessary in pure software development.The beginning of hardware validation is an important milestone for software development. If this isn't met, it has serious consequences for the entire project.To complicate matters, the software doesn't need to be completely error-free at this point. It just needs to enable the product's operation.But which errors can no longer occur and which are still acceptable at this time? This must be evaluated very precisely to focus software development on the important features and functions in a timely manner.Solution:* Ensure the software development plan and mechanical development plan are synchronized.* Define testing-relevant software features immediately at the project's start.* Place special focus on meeting deadlines for relevant features in software development.* Ensure these relevant software features are validated on test benches before product prototypes are assembled.These are the pitfalls I've encountered most frequently during my professional career. There are many more, but I want to prioritize, too.Write in the comments which pitfalls cause the biggest problems in your environment and how you roll them out of the way.I'm really interested in your opinion. Please write your thoughts in the comments, or let's exchange ideas on this 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! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

It was one of those moments that stay in memory for a long time.I was invited to give a keynote speech, and I talked about project management and transformation. During my presentation, I mentioned the DCVI concept — a method that is very close to my heart and on which I have already written an article here.The session was engaging, with interested participants asking thoughtful questions and participating in stimulating discussions.During the Q&A, someone from the audience asked a question I had already thought about a lot in advance:“Isn't DCVI essentially the same as PDCA?”I felt caught off guard and thought: “Wow, these people really know their stuff—they've hit the nail on the head.”But the question also reminded me how often we use methods and concepts without thoroughly discussing their essential characteristics.Yet it's precisely this deep engagement with the subject matter that brings the clarity needed to truly realize the benefits of these approaches in practical application.That, in turn, inspired me to write this article. I want to take a closer look at the difference between DCVI and PDCA – two approaches that both stand for structure and improvement, but nonetheless emphasize different priorities and mental models.I hope you enjoy reading this and that it helps you apply both approaches in their optimal use cases.What is PDCA?In the 1930s, American Walter Andrew Shewhart developed a three-stage process for quality assurance in production processes. The process consisted of the following phases:Specification — Production — InspectionWilliam Edwards Deming, a student of Shewhart's, developed this cycle into the widely known PDCA cycle we recognize today.It consists of 4 steps:P — Plan D — Do C — Check A — ActThis sequence is called the Shewhart Cycle or the Deming Circle, named after its inventors.After World War II, Deming introduced the method in Japan, which led to the Deming Circle significantly influencing the development of quality management methods in Japan for decades.(Source: Demingkreis – Wikipedia)Through this path, the Deming Circle found its way into the Toyota Production System, which, with its methods of Kaizen (Continuous Improvement) and Genchi Genbutsu (Problem Solving & Error Prevention), became a foundation for modern quality assurance methods.I can still remember very well times in my professional life when the Toyota production system was on everyone's lips and really everyone in the industry studied it and tried to apply it in their environment.In recent years, it's become somewhat quieter. I'd be very interested to know if younger colleagues are familiar with terms like Kaizen and Genchi Genbutsu. Please let me know in the comments.Due to this history, the Shewhart Cycle or Deming Circle is reflected in the fundamental ISO standards that represent an indispensable benchmark for all modern industrial companies. (e.g., the ISO 9000 series, which defines quality management systems)The character of continuous improvement was addressed very early by Shewhart, as he emphasized that it's an ever-repeating process, hence represented as a circular flow.Even today, the Deming Circle remains the most important and widespread foundation for continuous improvement processes and thus also for “Lean Manufacturing,” which can be seen as a generalization and expansion of the Toyota Production System.Since product development typically aims for improvement or perhaps solving a specific problem, this cycle is fundamentally applicable to product development projects and is consequently reflected in common product development methods (IPMA, PMI, Prince2, Scrum, LeSS, SAFe).What's crucial is how the individual phases are defined and understood in each specific case. That's why I'll present my interpretation of the four phases in this article.I'm very eager to exchange thoughts with you about your understanding of this subject in the comments.What is DCVI?As you can read in my About page, I've had the opportunity to be involved in many vehicle and powertrain development projects throughout my long career.During this time, many project management and development methods have emerged, and I've had the chance to apply them and gain experience.This wasn't just the Deming Circle, but also, for example, the emergence of the Stage-Gate development process, the V-model for developing mechatronic systems, and, in recent years, agile development methods. But also QM methods that are helpful in the development environment, such as the 5 Whys method, the Ishikawa diagram, FMEA, functional safety, and also product testing methods like Design by Experiments, statistical test planning, and much more. I believe I could continue this list for pages.Looking back at this long history and the experiences gained, I asked myself whether there is an overarching concept that connects all methods and thus forms a foundation for successful product development projects.The result was the DCVI process, which we now want to look at here.The 4 steps are:D — Definition C — Creation V — Validation I — ImplementationAnd yes, DCVI can also be explained with PDCA! Just as other approaches can be explained in ways that are helpful for work in product development projects.However, I've also found that different approaches than those used for continuous improvement are more effective when successfully completing projects or development increments. In some cases, even counterproductive effects can occur.I'll address these issues in the following, as this is the inherent advantage I see in DCVI as a process method.DCVI is not a circular processDid you notice in the title image that PDCA is shown as a loop and DCVI as a linear sequence?This already marks an important difference in approach.As the term “continuous” in continuous improvement clearly indicates, it's about a recurring process. Shewhart articulated this explicitly.This is, of course, also correct and significant in a product environment.Of course, the product, its competitiveness, and performance must be continuously reviewed.In addition, markets and company profitability must be continuously reflected upon, and the need for adjustment must be identified.In fact, this is so essential that, in my opinion, there must be dedicated responsible persons and roles for this.Be it strategy or product management teams in the classic organization, or business owners and product owners in the agile world.However, the analysis of what needs to be done and towards what goal the product needs to be developed or further developed should be done before a project is started. It is the trigger for a project!So, I can assume that the information about what is needed when, and the available resources – meaning time and budget – are already in place.Unlike continuous improvement, I don't need to worry about the “What” anymore; it's all about “How.”But that's difficult enough!To look at it from another perspective.You could also start a project with the following statement:“We should do something with the product again, take a look at what makes sense.”In my experience, this doesn't lead to a good result, and certainly not to an efficient product project.Too many people have a say, making opinion formation democratic but time-consuming and inefficient.Here I quote the old saying: “Too many cooks spoil the broth.”So I can already state an important difference between PDCA and DCVI:While PDCA aims at continuous improvement and thus has no defined beginning and no predetermined end, DCVI, as it is typical for a project, has a concrete beginning and a concrete end.DCVI is a stage-gate processIn addition to the defined beginning with a clear objective and the temporally defined end, the end of each phase represents a milestone where a phase is formally completed, the project status is reviewed, and the result is frozen.This forces us to focus on the respective important activities in each project phase.And everyone must focus!I see a major weakness in classic project management in the fact that quality gates are not targeted hard enough.People let the developers work first. They should lay their egg first, and when they're done, the other functional departments look at the result and form their opinion.Unfortunately, new requirements often come to the table much too late, which consequently leads to expensive project loops, inefficiencies, duplicate work, and immature and qualitatively deficient products.A key goal of DCVI is to avoid development loops by having all involved departments work simultaneously on the respective phase and also complete it simultaneously.Jumping back to the previous phase should only occur in absolute emergencies and should accordingly have severe consequences.In PDCA, I don't see this consistent separation of the 4 phases; here, fluid transitions are possible, perhaps even desired. Not only should the process be improved, but also the improvement measure itself should be continuously improved during the process.I don't want that. At the end of the DCVI cycle, the product is finished in exactly the same condition as it was ordered at the beginning of the cycle.If new goals are identified in the meantime, a new DCVI cycle must be initiated.This can lead to several DCVI cycles running in parallel.While the earlier cycle may be in the validation phase, a new cycle is already starting with the definition phase.It's not envisioned to abort DCVI cycles; once a cycle has started, it's quickly and consistently worked through and completed. This is done knowing that the developed product, after the completion of development, will likely not remain unchanged for long.This can certainly be viewed controversially and is perhaps a topic for its own article. Write to me in the comments if I should delve deeper into this.Now let's look at the 4 phases individually:Plan vs. DefineUnlike the Deming Circle, the beginning of the DCVI process starts with a goal for the project.Just like with PDCA, it's now about planning the achievement of this target state in detail and discussing and agreeing on it with those involved.Both concepts provide for the planning of processes and resources.While PDCA speaks of planning a measure, at the end of the definition phase stands a product concept (architecture) and a comprehensive catalog of requirements.There is no solution yet!This is a very important feature of the DCVI!Before working on finding a solution, it is necessary to decide on an integrated concept with defined system interfaces and detailed requirements for all persons involved and subsystems of the product.Here DCVI separates much more sharply than PDCA. But this is very useful because experience has shown me that working on the concept and the requirement breakdown is often impermissibly shortened as misunderstood efficiency, which later leads to expensive development loops and delays.DCVI draws a clear line here.First, the complete plan with the aspects of deadlines, resources, concept, and requirements is developed, reviewed, and jointly decided. Only then does the solution-finding begin.To say it very clearly again: These defined plans are binding from now on! From now on, everyone must work within the framework of the goals agreed with them and promised by them.Do vs. CreationIn the "Do" phase of the PDCA, the improvement measures are tested in a small and risk-minimized environment.I might also describe it as "Learning by Doing." Difficulties that arise during the implementation of the measure are identified and solved until the process runs smoothly.Thus, the "Do" represents a mixture of elements of "Creation" and "Validation."In the Creation Phase of the DCVI, the aim is to crystallize a solution that represents the best compromise from a large number of possible solution alternatives.Every technical solution is always a compromise between performance, cost, and quality.To find these compromises, the detailed specifications from the definition phase are necessary. They represent the optimization space in which to work.If you will, compared to PDCA, only at the end of the Creation phase are the measures defined in detail, but then definitively.The boundaries must be sharply drawn.For the creative phase to run efficiently and quickly, the important specifications and processes must be correct at the end of the definition phase. Trying out specifications should not be the goal, although it cannot be completely avoided in reality.I like to compare the end of the creative phase to a test in school.Now the pen is put aside and the test is submitted. If the teacher finds no errors, that's it. If not, then the tasks with incorrect results must be corrected.Check vs. ValidationIn the Check phase of PDCA, it's about finding out whether the desired magnitude of improvement has really occurred.If deviations are detected, the causes must be found and eliminated.Validation in DCVI pursues the same goal. The product is produced in the new target state and must prove that the performance characteristics, costs, and quality requirements specified in the definition phase are statistically reliably achieved in reality.If significant deviations are detected, the causes must also be found and eliminated here.I strongly borrow from the V-model of system development. It's formulated more clearly there than in the Deming Circle.For product projects, validation doesn't take place in real customer use, but in a special test environment. If customer deployments are part of the validation, then the customers are contractually engaged as "validation service providers" and appropriately instructed to carry out the test properly.Act vs. ImplementationIn PDCA, the result of the Check phase leads to the decision whether the measure is rolled out to the entire system or, if the check result is negative, a new optimization loop is started and the previous measure is simply not rolled out.In DCVI, this second option doesn't exist.At the end of the validation phase, there is always a product that fulfills the goal set at the beginning of the cycle. The product itself is already finished.The implementation phase is now about ramping up the production processes and sales of the product to the target speed.I hope it's understandable why I see DCVI as a clearer control model for product projects and why PDCA offers too much room for misinterpretations that can have fatal effects on the success of product projects.I'm really interested in your opinion. Please write your thoughts in the comments, or let's exchange ideas on this 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! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

No manufacturer can succeed alone; suppliers are vital to every successful OEM business, directly contributing to the final product's success.In the last article, I discussed the various types of products and their development environments. In doing so, I described the series product as being developed even before its eventual customers are identified.If you’re a supplier or work for one, you might think: 'That doesn’t apply to us—we develop our series products together with the customer!'But who’s right?In this article, I’ll dive into this specific question and explore the collaboration between OEM developers and supplier developers. The goal? To foster mutual understanding and improve cooperation for better outcomes.What does the development process of a final product look like?I will start with a brief overview of the phases in end-product development to provide context for the explanations that follow.Development follows the principle: Specify from large to small — Validate from small to large - a principle that is anchored in the V-model of system development. It all starts with the customer-intended end product, which is usually understood as a more or less complex holistic system. The OEM's developers describe and specify the end product very precisely, ensuring that all requirements are clearly defined.A complex and time-consuming process begins: Performance requirements and specifications are broken down along a new or existing product architecture into subsystems, assemblies, modules, components, and individual parts. The objective is to ensure that all elements work together seamlessly to achieve the intended overall system characteristics.There exists one major challenge in this process: The performance of individual parts, components, and modules directly affects the allocation of specifications within the system. It would not be practical to impose technically unfeasible requirements.This decomposition of requirements follows an iterative approach along the left leg of the V-model. Subsequently, validation takes place step by step along the right leg: First, each part must demonstrate that it meets its assigned specification. Next, the interactions between individual elements are tested at each level, gradually progressing from single parts to the entire product.Finally, at the top right-hand end of the V model, the entire system must demonstrate the defined product characteristics.The development is only considered complete once all requirements have been fulfilled.What does the OEM need from the supplier?In the process of breaking down requirements, it is crucial for the OEM engineer to realistically assess performance and properties at each level.At various system levels, suppliers now come into play.As part of the specification process, the OEM must decide which components to source from partners—whether for economic, logistical, or expertise-related reasons.At this stage, the supplier becomes an active participant in the project.Even though the OEM is the supplier’s direct customer, the focus is ultimately on the end customer who will purchase the final product. In reality, the end customer doesn’t care who contributes which parts—what matters is the overall result.It is crucial that all parties involved understand this relationship. Only if the end customer is satisfied, places an order, and pays for the product can business success be ensured for everyone.While the supplier provides a defined scope of supply, they are also an integral part of the project team during the development phase.So the engineer at the OEM needs the same things from the engineer at the supplier as he needs from his colleagues at the OEM:* Solutions for problems* Information on the performance and properties of subsystems, assemblies, modules, components, and parts* Feasibility and risk assessments for new developments* Costs/prices* Performance evidence for supply scopes* Calculation models, prototypes, and production samplesYou might be wondering why I didn't list any information about time requirements.The reason is quite simple: Time cannot be integrated. If the development of one component or module takes longer, this delay cannot be compensated for by a shorter development time of another component. Components that are not available within the given time frame are automatically ruled out as viable solutions.That's why development frontloading at the supplier is a crucial prerequisite for the OEM to bring technologically sophisticated products to market.On the right-hand side of the V-model, the Original Equipment Manufacturer (OEM) engineer requires proof of performance. Ideally, every engineer involved in the project should provide this verification for their respective scope of work. This includes engineers at supplier companies, who should demonstrate the performance of their supplied components or systems.How can a supplier prepare their product?At this point, I'd like to briefly discuss four key project categories:* Integration projects* Platform projects* Component projects* Technology projectsIntegration ProjectsThe development process for an end-product following the V-model, as previously described, exemplifies an integration project. In this context, the primary focus lies on harmonizing interfaces within the overall system. This critical task is typically the responsibility of the Original Equipment Manufacturer (OEM).Key aspects of integration projects include:* Ensuring seamless communication between various subsystems* Optimizing the performance of the entire system* Managing complex interdependencies among components* Coordinating efforts across multiple teams and suppliersBy effectively managing these integration challenges, OEMs can create cohesive, high-performance products that meet or exceed customer expectations while maintaining efficiency in the development process.Supplier engineers must be prepared to optimize components, manage interfaces, proactively solve problems, and maintain seamless communication with OEMsTechnology Development and Pre-Development ProjectsThe development of new, innovative, and unfamiliar technologies must occur in advance of integration projects. This proactive approach is crucial because it generates essential information regarding performance characteristics and properties, which serves as a prerequisite for successful integration.Suppliers should take the initiative to:* Independently develop technologies relevant to their scope of delivery* Ensure these technologies are available at the project's outset* Conduct technology and pre-development projects to achieve these goalsThis strategy offers several benefits:* Reduces risk in integration projects* Accelerates the overall development process* Enhances the supplier's competitive edge* Enables more accurate cost and timeline estimatesBy investing in technology and pre-development projects, suppliers position themselves as valuable partners to Original Equipment Manufacturers (OEMs), ready to contribute cutting-edge solutions to integration projects from day one.Platform and Component ProjectsTransforming pre-developed technologies into viable supply packages typically requires suppliers to undertake platform or component projects.These projects bridge the gap between innovative concepts and practical, marketable solutions.It's often not feasible or economically viable to have completed such projects when the OEM starts to integrate. Significant investments before a supply contract is secured can pose financial risks. However, the more preparatory work is completed, the smoother and faster the integration project progresses.OEMs prefer suppliers who offer:* Ready-made modules or components* Solutions requiring minimal or no adaptation* Well-prepared scopes that can be easily integratedSuppliers should adopt a forward-thinking strategy:* Conduct preparatory work to the economically justifiable extent* Develop a range of potential scenarios* Prepare comprehensive preliminary investigations and decisionsBy taking this proactive approach, suppliers position themselves as valuable partners, ready to respond swiftly and effectively to OEM needs. This preparation can significantly streamline the integration process, potentially leading to stronger partnerships and more successful projects.How can effective collaboration be achieved?Effective cooperation between Original Equipment Manufacturers (OEMs) and suppliers hinges on two fundamental principles: openness and trustworthiness from both parties.Successful partnerships involve OEMs and suppliers aligning their respective product and technology strategies over the long term. This foresight enables suppliers to prepare thoroughly and in good time for upcoming integration projects.This level of openness demands a high degree of mutual trust, as it involves exchanging competitively sensitive information. Both parties must ensure that this data never reaches their respective competitors, as it's highly confidential.Mutual Responsibilities* For OEMs: Making timely decisions about goals, priorities, and preferred partners.* For Suppliers: Allocating resources early and making upfront investments at their own technical and financial risk.The second statement parallels the series product for the end user, as explained in the previous article. Just as OEMs pre-finance product development at their own risk, suppliers should initiate preliminary work early, assuming calculated risks.What challenges and obstacles must be overcome?Here, I would like to discuss some examples of typical challenges in an OEM supplier relationshipPrice vs. proof of maturityIn supplier competition, prices are typically objective and transparent. Since the supplier's price directly impacts the OEM's costs, it is natural for the OEM to prioritize selecting the supplier offering the most competitive price.However, evaluating the performance and readiness of the supplier's scope of delivery is far more complex. For instance, if one supplier has already completed preliminary work and can provide tangible evidence of their components’ capabilities, while another cannot, the OEM faces a challenging decision. Often, the supplier who has invested in advanced development may charge a higher price compared to a competitor without such preparation.This dynamic can lead to situations where the OEM selects a supplier based solely on a lower price. However, this choice may result in difficulties later in the project, such as delays, integration challenges, or compromised product quality. The lack of preparedness from the selected supplier can ultimately hinder project progress and impact the overall success of the product.To avoid such pitfalls, OEMs must carefully weigh both price and maturity during supplier selection, ensuring that short-term cost savings do not compromise long-term project outcomes.Beyond price: Assessing supplier capabilityA critical, often overlooked aspect of supplier selection is evaluating the supplier's ability to participate in a development project professionally, punctually, and with high-quality work. This assessment is crucial for long-term project success.A contract between OEM and supplier can be compared to saying "I do" at a wedding. Once the "wedding" (contract signing) is over, a "divorce" (contract termination) becomes significantly more complicated and potentially disruptive for both parties.If the honeymoon period is quickly followed by arguments and dissatisfaction with the partner, this will have a negative impact on the final product and thus on the financial situation of both partners.So don't be fooled by appearances. You have to look at what's inside.In-Production Challenges: Cost Reduction vs. Quality AssuranceOnce the end product successfully transitions to series production, the real business begins. This phase introduces a delicate balance between cost optimization and maintaining product integrity. Suppliers naturally seek to reduce production costs to improve profitability, while OEMs often demand price reductions from suppliers to ensure their own profitability. This situation creates an inherent conflict of interest.When a supplier considers making changes to reduce costs, a critical decision point arises. Option 1:The supplier can take a transparent approach, discussing changes with the OEM for system-wide validation. However, this means the OEM becomes aware of cost reductions, potentially leading to demands for price cuts. Option 2:The supplier might implement changes without OEM consultation, potentially retaining cost savings but risking expensive quality issues that could damage reputation and relationships.While the temptation to implement undisclosed changes may exist, the ethical and practical course of action is clear: transparency and collaboration with the OEM are essential. This approach ensures product quality and system integrity, maintains trust in the supplier-OEM relationship, mitigates risks of costly quality issues, and aligns with long-term business sustainability. Although it may be challenging to resist short-term financial gains, the long-term benefits of maintaining transparency and quality far outweigh the risks of unilateral, undisclosed changes. In the end, open communication and collaborative problem-solving between suppliers and OEMs are crucial for navigating these in-production challenges successfully.The evolution of OEM-Supplier relationships in a changing global landscapeThe increasing complexity of products and the intensification of market competition have made the inefficiencies of the traditional OEM-supplier relationship less and less sustainable.A re-evaluation of established practices and an exploration of new paradigms are required to address this shift.Looking at the Chinese market, the degree of vertical integration at OEMs is much higher than in the West.However, it's important to recognize that the current Western model didn't emerge by chance. Despite the disadvantages discussed earlier, it has persisted for decades due to numerous significant advantages.This situation prompts several critical questions about the future of manufacturing and supply chain management:* Will we witness a return to higher levels of vertical integration in the future?* Will the current trend of specialization and division of labor continue?* Can we develop innovative solutions that combine the advantages of both models while mitigating their drawbacks?These questions are not merely academic; they have profound implications for the future of global manufacturing, supply chain resilience, and competitive strategies in the automotive and other high-tech industries.I invite you to share your thoughts and perspectives on these crucial issues. How do you envision the future of OEM-supplier relationships evolving in response to these global trends and challenges? Your insights could provide valuable perspectives on navigating this complex and changing landscape.Let's discuss it in the chat! I'm curious to see what you think.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! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Product development — sounds self-explanatory, doesn't it? But what exactly is a 'product'? I would now like to get to the bottom of this fundamental question and take a closer look at the special characteristics of products.I've worked on vehicle development my entire professional life, so I'm very good at how a vehicle product development process works and the environment in which it takes place.But there are other products, some of which are fundamentally different in nature and are therefore consequently developed with different approaches in a different environment. This became clear to me during an exchange of experiences with colleagues from companies in other industries.As always, one can learn from another. That's why I want to share my insights and thoughts in this article and encourage you to reflect on them. I hope you'll find it inspiring and have fun classifying your products. Have you ever thought about what a product is? How it is defined? Since I will be discussing the characteristics of the product development process and product development projects again and again in the following articles, we should first agree on our understanding of the term “product”. What is a Product?In the literature, the product is often seen in connection with production and the company's goal. As an example, I refer here to the definition from the Gabler Wirtschaftslexikon:Result of the production and objective of an undertaking or also means of satisfying needs. (Source: https://wirtschaftslexikon.gabler.de/definition/produkt-42902/version-266242 Revision of product from 19.02.2018 - 14:37)However, I believe it is more appropriate to define the product not from the company's perspective but from the user's point of view. With this in mind, I have developed the following definition:A product is an item or a device that fulfills a desire or solves a problem.In my opinion, a product must always serve a purpose, without a purpose it is useless and without use it is worthless.The intensity of the desire or the severity of the problem that the product addresses directly influences the customer’s valuation of the product.Or, as Martin Daum used to say:A great product is characterized by the fact that the customer happily separates himself from his money.Martin Daum, former CEO of Daimler Truck AGThus, the product serves as the foundation for any company's financial success. Finally, you've got a connection to the business and, when appropriate, to the product's manufacturing. Product or Service?Some distinguish between products and services, suggesting an inherent difference between tangible hardware products and intangible services.This can be explained if you define the product as the result of production. After all, a service is performed rather than produced, meaning it does not undergo a traditional production process.In my opinion, however, this distinction does not make sense. A product must be understood and implemented as a holistic solution. It is a complete package that brings value and satisfaction to the customer, whether it is tangible, intangible, or both.If you notice this separation in your business, ensure that the hardware and service departments don’t operate in silos at the customer’s expense.I will go into this later in the article.Now that I've defined the term "product," let's look at different types of products.Single ItemA single product is characterized by the fact that only a single copy of it is developed, manufactured, and delivered to a customer.This type of product can come in a wide variety of forms. * As a building, * as a special machine, * as a production plant, * etc.As a rule, these products are based on modular elements or sometimes even series products, which are then heavily modified.Think, for example, of an armored vehicle. Here, a series vehicle (car, van, or truck) is redeveloped into a bullet-proof special vehicle equipped with special equipment.A key feature of single products is that a development project is not started until an interested customer has been found. So sales are at the very beginning here.If a customer shows interest, the offer phase begins. The company collaborates with the customer to develop the product requirements. In this process, project approval takes place both when the customer places the order and when the company formally accepts it.Challenges for the developerThe challenge for the developer in the case of a single product is validating the product before delivery.Due to the product's complexity and cost, all forms of destructive testing are prohibited. As a result, testing and performance measurement must be conducted using theoretical validation methods and model-based validations.Risk management plays a crucial role and must be applied consistently as a method.Impact on the organizationFor companies that produce single products, project management of development projects is at the core of their business. This seems to result in top managers having gained extensive project management experience during their professional development or having managed large projects themselves.Consequently, project management is strongly developed here and is highly prioritized in day-to-day business.Series ProductIn a serial product, there is a strong temporal separation between the development of the product and its sales/production. A typical example that everyone is likely familiar with is vehicles.The decision to develop a product is made by management. Sales begin after the product has been developed and validated. It is then manufactured and delivered in large quantities in a repeatable production process. The individual units may well be one-offs, assembled by combining pre-developed modules. The main difference to the individual product is the decoupling of product development and customer order. Challenges for the developerUnderstanding the customer requirements that need to be met is a challenge for the serial product developer.There are many potential customers with very different wants and needs. However, these customers are not known at the time of development and therefore cannot be consulted. This complicates the specification, the definition of product characteristics, and the selection of validation methods. Through detailed market analysis and a product architecture based on that analysis, a product portfolio has to be found that will meet all major customer requirements in the future. A second challenge for developers is balancing the dual workload of initial development and ongoing series support.Since a new product is being developed while quality issues in the current product need to be resolved, urgent customer requirements integrated, and costs optimized, developers are essentially juggling two tasks at once. This strains resources, makes it difficult to focus, and adds volatility to the task portfolio.Impact on the organizationIn companies that develop, manufacture, and sell series products, revenue is primarily generated through production and sales.As a result, top management naturally focuses its attention on these areas.However, the methods and processes in product development and day-to-day operations differ significantly. While product development follows a project-based, long-term approach, daily operations rely on short-term, standardized, and highly synchronized processes.Balancing these two worlds is a challenge. It is crucial to ensure that the urgency of daily business does not hinder or negatively impact long-term product development.Mass ProductA mass product is designed once and then manufactured and sold almost unchanged over a long period of time. Beverage cans, Euro pallets, or bricks are to serve as examples.Since there is minimal development involved, I will mention this type of product here for the sake of completeness but will not elaborate further.Software ProductSoftware products are characterized by the fact that there is no production or manufacturing. Although it only exists in conjunction with hardware (a computer or control unit), it is not necessarily tied to it in its development.Once developed, the product can be delivered in unlimited quantities and without delay.As software is information processing, there are no physical durability problems. This significantly shortens the product development time, as the time-consuming proof of durability is not necessary.Challenges for the developerTypically, physical product variants are expensive because the manufacturing tool, logistics, and complexity of production set a natural financial limit on the number of economical product variants.In the case of software, these costs are not to be found at all or to a much lesser extent.This leads to an endless hunger for variants, functions, and features.Complexity in development is the limit, but this limit is very difficult to identify.This complexity in development, combined with the high speed due to the absence of hardware procurement times, creates significant pressure on function validation. A large number of functions with a high degree of combinatory variation must be tested in a very short time.Impact on the organizationThe focus of the business here is on the two core processes of product development and sales.Product development therefore plays a key role in the economic performance of the company. In conjunction with the short cycle, it is at the heart of day-to-day business.Mechatronic ProductToday, hardly any physical product can exist without software.Mechatronik Products combines physical products and software.With the help of software, product functionality is significantly enhanced, and costs are reduced when physical product systems are replaced by software.On the hardware side, mechatronic products can include both individual products and series products. The combination with a mass product is rather rare.While historically this type of product was characterized by a high level of integration of hardware and software, the current trend is towards "software-defined products". These are products in which hardware and software are largely decoupled, and thus different development cycles are possible. The software can be further developed on a stand-alone basis, independent of the hardware.Challenges for the developerThe major challenge for developers lies in combining the extremely different speeds of hardware and software development.The hardware can only be operated and therefore validated in combination with the software. Therefore, the software must be validated before the hardware can be validated. This means that the total development time is longer than developing the software and hardware independently.This is of course absolutely undesirable, which is why we have to try to move both timelines into one another. Managing this is a major challenge.Taking a closer look at this challenge is probably worth several articles.Impact on the organizationThe company must function as both a software company and a hardware company simultaneously.This presents an organizational challenge. Hardware-oriented and software-oriented companies operate with fundamentally different structures and processes, yet here, they must be integrated into a single cohesive organization.If the physical part of the product is a series product, then there are actually 3 different processes that need to be integrated.One can imagine that due to this fact, it is extremely difficult to find a suitable organization, a consistent control system, and an integrated process model.ServiceIn connection with software, services are increasingly becoming the focus of the customer's attention.Software is no longer just sold to the customer, but the software is used by the company itself and the solution is sold to the customer.If only pure software is involved, this is referred to as Software as a Service (SaaS).I think everyone is familiar with examples of software products that are hosted "in the cloud" and used by customers without owning them, instead paying a fee for the results.Physical and mechatronic products offer the opportunity to bundle additional services with the product, which are offered to the customer in exchange for regular payments.One example is the service contract, which includes the maintenance and repair of vehicles or equipment. If data from the operation of the product is included in the service, a very high customer benefit can be represented, which of course should ideally be converted into a profitable business.If the mechatronic product itself is integrated into the service, we refer to it as "Product as a Service." In this model, the customer no longer buys the product but only the service it provides.Challenges for the developerIn this constellation, which is very lucrative due to its potentially high profitability, the service must be developed at the same time as the hardware and software. However, the development of services follows its own processes.The challenge for the developer is therefore to integrate all aspects, ideally so that the maximum customer benefit is created. This has to be higher than in the classic model, where the customer is responsible for the operation himself.In the development of both the physical product and the software, the needs of the service must be considered to ensure that the service operates with maximum efficiency.Impact on the organizationIn this business model, the organization must be a master in all three business disciplines.* Development, production of hardware* Software development* Development and distribution of a serviceObviously, selecting the optimal organizational structure, implementing the necessary processes, and managing such a large organization involves a high level of complexity.Sharpen your view – focus on your productI hope this overview gives you enough food for thought to re-evaluate your own product and critically reflect on the challenges associated with it. I am looking forward to an inspiring exchange with you.I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe if you are interested to ensure you do not miss any updates.Let's talk about your product and your experiences with challenges for developers and the organization in the chat.If you found this helpful, don’t forget to share it with others who might enjoy it too! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

A project has a beginning and an end.This statement is an attribute of projects included in the widely accepted project definition.But when does a project really start? ... and what are the requirements for a successful project start? This is exactly what I want to discuss in this article today. If you are clear about this, you can start projects in a way that ensures a good prerequisite for a successful project progression.Be curious, some of my statements are once again controversial, others are self-evident and hopefully many will be helpful. When does a project start? I often encounter the view that a project starts when it is approved by the board, a committee, or someone with the authority to make decisions. I disagree with this, and I will explain my reasons.The approval of a project is always associated with significant consequences for the company.* Funding is released,* Resources are allocated,* the company's profitability and thus its balance sheet are affected,* and customer and market-relevant product decisions are taken with the project approval.The consequences of a project decision for the company are correspondingly serious. Therefore, a project must be prepared ultra-thoroughly!However, precisely this preparation is already part of the project because it requires a project-based way of working, a project-based organizational and communication structure, and released resources, i.e. employees.For this reason, a project must start with an official "project start" that is well before the project decision date.For me, starting a project means that a group of employees is commissioned to:* Organize a project, * Gather or develop the information necessary for making a decision about the project. * Present it to the decision-making body for implementation decision.If this is completed, the project decision can then be made on this basis.The project approval itself is the decision to implement the project in accordance with the defined premises and objectives, and to allocate the necessary financial means and resources.I will discuss the steps from project start to project approval and beyond in different articles. As I mentioned earlier, today is about the project's beginning.The beginning of a project is not an unforeseen circumstance. There must be a reason to start a project!This reason usually arises from a business necessity, which can have different origins.Many organizations have business units tasked with identifying and assessing business needs and gathering information to ensure project success.In product projects, it is usually the product management or product strategy team that takes the lead.So let's take a look now at what information is urgently needed for a successful project start.What information must be available at the start of the project?1. Defining the problem that the project intends to solve.The fundamental question is: Why start a project in the first place?Clearly stating and justifying the issue to be solved is crucial at this stage. The project team should be provided with comprehensive supporting material to ensure they fully understand and assess the issue.Keep the priorities in focus!Clearly and precisely distinguishing which problems urgently and inevitably need to be solved and which smaller problems can be addressed simultaneously is crucial.The first category must not change on the way to project approval and later during project implementation.The second category will be further refined and prioritized in collaboration with the team and the organization until the project approval.When money and resources are scarce or when goals contradict each other, such problems need to be set aside. On the other hand, if resources allow, relevant additional content can be identified and integrated into the project if feasible and beneficial.Here are a few more tips for formulating a strong project rationale:* Describe the actual problem, not the causes of a problem.* Stay solution-neutral.* Verify the real existence and the description of the issue with the person who really experiences this difficulty himself. Don't trust hearsay and postmen.* Avoid wish lists of items that do not solve an urgent problem. Measures will be created later based on the problems identified for resolution.2. Establish the DeadlineThe second crucial piece of information concerns the deadline for actually resolving the issue.Too often I hear: As soon as possible!Upon closer examination, I often find that the problem has been plaguing the organization for years, but is not taken seriously until it becomes urgent.This is very bad, because it usually leads to missing the reasonable start date, and then the crisis is already there before the project can even be decided, because there is no time left for professional work.To avoid this, use the following procedure:* Pick up the issues as soon as they arise.* Specify the latest time by which the issue must be resolved.* Write a corresponding project into a project planning list.* Based on the expected implementation time, set a reasonable project start date that allows enough time for a meaningful project process.In any case, there should be a forward-looking plan that lists all current and hypothetical projects with their start and end dates. This list can and should be periodically reviewed and adjusted to reflect reality.This ensures that you don't miss a project start and that you know how much time is available to complete the project.Commonly observed errors:* The start of the project is postponed, although the time is ripe, because there is no money or resources available at the moment, but the implementation date is maintained.* The urgency is exaggerated because someone wants the project at all costs.Be aware that delaying the start of the project will either require a corresponding delay in the end of the project, or will need to be compensated for by adjusting the project content.3. Setting the Financial Boundaries.BudgetAt the beginning of the project, it must be clear how much funding is available. I emphasize this point strongly. The financial framework should be clearly and specifically defined.This information comes from the company’s overall business plan and is not related to the actual project at this stage.Knowing the available funding allows the project to be managed as it progresses towards approval, so that the content of the project does not exceed the funding available. This results in speed and efficiency by avoiding planning loops.The following errors are commonly seen at this point:Error 1: A budget is set that is less than the available amount.This is usually based on faith: If I tell them how much money is actually available, they will spend it all!This approach is dangerous because it increases the risk that valuable project components won't be implemented or that essential quality assurance steps will be skipped. Either can reduce profitability more than the saved budget could ever compensate.The project must be planned in a way that ensures minimal resource consumption while maximizing cost-effectiveness. It should be a given that the allocated financial framework is only fully utilized in absolute emergencies. If the project team cannot be trusted with this, it may be time to look for different people.Error 2: No budget is communicatedThe reasoning behind this approach is often:"Let’s have the team estimate how much money they need, then we’ll see if we have that amount. If not, we’ll take the planned scope and cut the proposed budget."This creates a highly toxic situation.It can lead to everyone requesting as much money as they can reasonably justify, anticipating that cuts will be made anyway—so they inflate their estimates to ensure the necessary minimum remains.Setting a clear maximum budget from the start prevents the development of concepts that are doomed to fail due to insufficient funding.Important: This has nothing to do with the business case, which only comes into play later in the project approval process.Product CostDefine the product cost trend.At the start of the project, there is no need for concrete product cost targets.It should be clear whether:* A reduction in product costs compared to the status quo is necessary.* Maintaining the same product costs is acceptable.* There is a real possibility of accepting an increase in product costs to implement the necessary solution.An increase in product costs can be justified if it is offset by an above-average pricing capacity due to new customer value, or if other costs, such as quality costs, are significantly reduced.In fact, this insight is automatically brought to the table when the business case is calculated on the way to project approval.However, in my experience, this often comes too late. If the product cost trend is identified early in the solution design phase, it can help prevent mistakes.The business case can’t be fully evaluated until the concept is ready for review. However, by that point, a considerable amount of time and effort will have already gone into developing the concept. If the cost trend doesn't align, the project will face expensive and time-consuming rework.4. Evaluating Technology ReadinessVery often it is already clear that the problem cannot be solved with the known solutions. Something completely new is needed, something we have no experience with in our day-to-day business.New technologies need to be understood well enough so that they do not lead to unplanned project loops.First of all, such new solutions must be available in the first place.Never start a project assuming that the brilliant engineers will come up with a solution technology if they just think about it for a moment.There are departments whose reason for existence is to have such solutions ready at the start of a project. If this is not the case, then the company has an organizational problem. I will discuss this in more detail in a separate article.Second, the potential solution technologies must be evaluated to determine whether they can be made commercially viable in the time frame available. A technology that is not feasible within the available time and budget need not even be selected as the basis for a concept study.To evaluate a technology for project readiness, you can use classic project risk management.5. Identify the Major Project RisksIn addition to technological risks, all other fundamental risks must also be identified.The real project risk management begins after the project starts.But before you start, you need to determine whether there are risks that could jeopardize the project as a whole.If such serious risks exist, they must be resolved before the project starts, otherwise the project will be stopped later, and money and resources will be lost.Are you wondering what such serious risks can be?Here are a few examples:* To produce the new product, a new factory must be built because none of the existing factories are suitable. But there is not enough time or money for a new factory.* There are currently no suppliers available in the market for critical components or systems.* The company lacks essential skills that are crucial for the success of the project.Although these examples are hypothetical, I have encountered such risks in projects. These problems are not merely hypothetical; they truly exist!6. Gather the Essential Resources to Power Your ProjectThe next step is to identify the team needed for the project, from start to approval.* Resources must be defined, * effort must be estimated, * and activities must be planned.The project can start when the supervisors of the required employees have commissioned or released them.It would be beneficial to hold a formal project kick-off meeting.Get together all the people who are affected in any way, * the future project members, * their superiors, * the management of the affected organizational units * and the stakeholders of the project. Let’s all come together to collectively decide on providing the necessary resources.7. Announce the Project Start to the Entire OrganizationNow we have almost everything we need to start a successful project. There is one last requirement that needs to be met.Communicate the project start to all affected employees.The project team is usually much smaller in the period from project initiation to project approval than the project team that implements the project after approval.This small team will depend on the input of many people in the organisation. Therefore, everyone in the organisation needs to be informed that this project has started.It helps to keep everyone informed about what has been done so far, so that support can be targeted and effective.I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe if you are interested to ensure you do not miss any updates.If you have any questions, need my help or want my advice, you can contact me in the chat.If you found this helpful, don’t forget to share it with others who might enjoy it too! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

In my previous article, I explained how to successfully manage projects and emphasized the significant influence that company culture has on a project's success. I promised to discuss how a necessary cultural change can be achieved in a future article.I would now like to fulfill that promise.What is corporate culture?For me, the term “corporate culture” encompasses the values, beliefs, and convictions that are shared by the majority of a company's workforce. Based on these, leaders and employees assess what is “acceptable” and what is not — how things are done or not done, what behavior is encouraged, and what behavior is discouraged.Corporate culture determines how people within an organization collaborate and, as a result, how efficient and successful a company is.However, culture is not easily shaped or changed. It emerges from a company’s traditions, national cultures, and employees’ personal value systems. It is also influenced by the priorities and values that the company's management reinforces or penalizes through its leadership practices.A deliberate change in corporate culture requires several prerequisites, which I will discuss here. Furthermore, specific tools and approaches are needed to transform a desired culture into a lived culture.There's a specific reason why I included the phrase “From Resistance to Habit” in the subheading. The beginning of a cultural change is always met with resistance. People don’t want to change their culture—they like it the way it is. They would have left anyway if not.If the cultural change is successful, the new culture becomes the new habit. People have embraced the new way and wish to maintain it. Once the resistance has disappeared and the change has become second nature, the cultural transformation is complete.Well—until the next cultural change becomes necessary.Conveying the urgency for changeIn every change process, there must be a willingness to change, otherwise the transformation will not succeed.If people don't want to change, they can't be helped.That’s what makes it so difficult and emotionally draining. At times, I struggle with frustration and hopelessness. However, I’ve always managed to hold on to hope and stay motivated through persistence and a strong will to implement change. As a change agent, I know that only if I exude confidence in the process can I inspire others to embrace change. It also helps to have trusted individuals to talk to about it confidentially.I mostly work with engineers, and I often find myself having to explain and justify the need for change in an objective and factual manner. This makes sense, especially among highly rational individuals, as the facts need to be laid out clearly for them. Most of the time, it's not that complicated. People are intelligent and can recognize the shortcomings of the current situation and understand why change offers hope for improvement. We usually reach agreement on that quickly.It is much more difficult for me to reach an agreement on the target state with the people. The existing culture regularly acts as a barrier. They want to change as little as possible, with only the minimum amount of change being acceptable for consensus. The target state that the minimal change is meant to achieve is typically also viewed controversially.An intensive debate is therefore necessary to align on the scope and goal of the required change. Never skip this step—it takes bitter revenge if you do.The time required for the intellectual acceptance of the planned cultural change always takes longer than I anticipate. That’s why I have to start implementing it before full acceptance is achieved. But I persist and don’t give up until the goal is reached, even though it’s exhausting and tedious.In addition to intellectual acceptance, however, I must also create a prerequisite that is much harder to achieve. I call it 'emotional acceptance.' It’s the realization that everyone is personally affected and must question and change their own values, standards, and approach. It’s much easier to accept that others need to change than it is to accept that each individual must change themselves.What follows from this?* Unlike in a project, I can't wait for the completion of the first phase—the intellectual and emotional acceptance of the cultural change. I begin working on creating a sense of urgency and a clear target vision, but I start implementing it in practice relatively quickly. The more tangible the new culture becomes, the easier it is to gain acceptance.* I cannot vote on the necessity and direction of change in a grassroots democratic way. As a change agent, I have to set the direction! I deliberately say the direction, not the target state. In the course of the transformation process, I remain flexible and constantly adapt the goal to the realities and feasibility.Methods for Successfully Implementing Cultural Change,In the cover picture you can see that I use 4 methods to bring about a culture change. These methods differ in difficulty and effectiveness. Let's start with the method that is the easiest to implement.Procedural supportProcedural support involves providing instructions on work processes, handing out checklists, defining responsibilities, and establishing committee or meeting structures that support the new culture. This forms the didactic framework for the teaching of the new culture.I want to explain this point using the example of agile product development, because I believe that makes it easier to understand than an abstract explanation.Agile development embodies a desired culture, I won’t elaborate on in this article — I’ll cover it in a separate one. Here, however, I will highlight methods that reinforce certain cultural aspects.Ensuring accountability for core valuesThe roles of product owners, Scrum masters, release train engineers, and others assign clear responsibilities to individuals and teams, reinforcing a value stream-oriented approach. Each role has distinct responsibilities and is accountable for delivering value within its scope. In this way, these roles and responsibilities actively shape the value stream-oriented culture that forms the cornerstone of agile development.Implementing accountability for deliveryDiscipline and synchronized working methods are enforced through predefined time frames and meetings (artifacts). The structure is so tight that prioritization and coordination become inevitable. This instills efficiency and effectiveness, which are key cultural aspects of agile development.Providing Structure Through ChecklistsFeature Definition, Definition of Ready, Definition of Done, etc., are essentially checklists designed to ensure that critical work steps are completed and not overlooked.I hope that these examples will make the way in which procedural assistance is used easy to understand.I hope these examples help clarify how I use procedural assistance.Of course, such assistance is not limited to an agile context; similar approaches can also be found in Lean, quality management methods, and more.The use of procedural assistance is a proven method that has been used many times over. It is effective when these tools are recognized as such, and when I am clear about which tool is useful for which purpose. I have also developed my own tools, which have proven to be very effective.If you have any questions about this, or if you'd like to apply procedural assistance in a different context and need my help, feel free to reach out and we can discuss it in the chat.Asking the right questionsI wrote at the beginning that culture consists of values, beliefs, and behaviors.This is exactly where the questions come in.I usually work on two levels with questions that encourage reflection on the cultural aspect of actions.Value-Based QuestionsThe value system that defines the new culture should be consistently present, everywhere and at all times.It is advantageous if not all values are new. Some existing values may be good and worth preserving.This value architecture should be visually sophisticated and omnipresent. It should be displayed on the wall in every meeting room, placed on tables as handouts, used as a screensaver on computers, and featured on stickers for briefcases, among other things.Now I can pose the question at every opportunity.* Does this correspond to our values?* Do we really want to do it that way?The benefit of this approach is that it does not dictate a solution, but rather encourages reflection. As the solution is pursued, acceptance of the change grows, as does confidence, because the result seems achievable.Procedural QuestionsThe second level at which I ask questions is procedural assistance, including the processes, responsibilities, and workflows described above.The questions here are highly diverse, requiring me to utilize all my experience and expertise to formulate the appropriate question at the right moment.* What's the problem?* What is the root cause of the problem?* Is that really the most important priority?* Does it make sense to do it this way?* Is this plan realistic?As already mentioned, the questions are extremely diverse at this level, but they all have one thing in common:Questions encourage individuals to engage in critical thinking and arrive at solutions self-sufficiently.Since procedural support didactically leads to a new and desired culture, the interpretation and cognitive processing anchor the new culture in the minds.New thought structures emerge and solidify in people's minds over time, eventually becoming habits. There comes a moment when individuals begin to ask themselves these questions, and that is what I aim to achieve.Of course, it is not solely the responsibility of one individual to ask these questions; all managers must participate, and colleagues should also engage in asking each other these questions.Practice, Practice, PracticeThis brings us to the next element and takes the step towards greater effectiveness.The old saying: "Practice makes perfect." also applies to the transformation process.I ensure that the elements discussed are continuously reinforced. I begin with simple tasks and gradually increase the complexity, in accordance with the capabilities of the individuals within the organization.Even in a marathon, one does not run 42 kilometers in the first training session.In this context, I require what seems like boundless patience and perseverance. Often, I am tired of hearing it myself, and I feel exhausted, but I understand the necessity of persisting. Training demands numerous repetitions and a high degree of discipline in execution to develop the desired skills.Sometimes I think: they'll never get it right if the practice just doesn't seem to work.I convince, I motivate, I force, I use all the means at my disposal to move people to use the procedures, workflows, checklists, committees, meetings, values, tools over and over again.This also serves the goal of forming a habit. If I no longer have to intervene and it has become automatic, then the transformation has succeeded.Leading by ExampleThe final element is the most challenging, yet it is also the most effective.The exemplification of the new culture!It is entirely unacceptable for me, as a change agent, not to implement the new culture within my own environment.That can be a bit bumpy, people know that I'm not perfect either. This even makes one likeable and believable and encourages others to help shape it. However, preaching one thing and doing another is not acceptable.I implement the new culture at every possible opportunity. I utilize the procedural tools whenever I can, ask myself the same questions I pose to my colleagues, and continuously practice, practice, and practice.And, of course, all managers must be on board with it!You can trust me, employees consistently observe their boss's actions and follow suit.When people sense that the boss thinks, 'Culture is something for those down there; it's none of my business, I have other priorities,' it becomes fatal.Without the involvement of managers and everyone, from the team leader to the board of directors, sustainable corporate culture change cannot be achieved.In my daily practice, this means that I must work just as diligently with the top managers to implement the new culture as I do with the employees in the organization.This is not easy, as even bosses are human—and they are allowed to be. They can make mistakes, ask questions, and show emotions. However, employees will understand and accept this.There is one thing that managers must never do: stand on the sidelines during a cultural change, remaining uninvolved or, worse, not showing up at all.I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe if you are interested to ensure you do not miss any updates.If you have any questions, need my help or want my advice on changing corporate culture in your environment, you can contact me in chat.If you found this helpful, don’t forget to share it with others who might enjoy it too! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe

Have you ever wondered if there is a secret formula behind successful and effective projects?Yes, there is—and in this article, I will explain it to you.It is the sequence of:* Definition* Creation* Validation* ImplementationIf you pay attention to it, it is actually simple and logical and should be self-evident. It is the basis of every project management method I know, from Classic Waterfall to Agile and SAFe. It is the basis of Lean and Continuous Improvement. It is found in quality management methods and systems engineering, and we even use it in leisure activities, mostly implicitly rather than explicitly. But why do so many projects still go wrong, are late, go over budget and deliver poorly performing products? My hypothesis is that it is because this simple principle is not followed consistently. What's so difficult about that?That's exactly what I asked myself two years ago when I took on the task of making Development's working processes fit for the future.Why is the organization chronically overloaded, and why do the work results often not meet the requirements and expectations? My analysis revealed that one of the main causes of the problems was the inconsistent application of the DCVI principle. I also came to realize that changing this is far from easy.Here is a selection of the statements I am confronted with: * I do not yet know exactly what we need. I don't have time to think about it now, we have to start developing so that we can make the deadline. (Neglected Definition)* Planning is a waste of time, I already know what I have to do. This is not my first time doing this! (Neglected Definition)* Planning and specifying is unnecessary bureaucracy and only encourages micromanagement by managers. (Neglected Definition)* You can't do it with thought and calculation, we have to build a prototype to experiment with it. (Neglected Creation)* I don't have time to test the final configuration. (Neglected Validation)* We no longer have the money to procure and test the final release status. (Neglected Validation)* We can use special processes in production during the first production period. They shouldn't make such a fuss in the factory, they'll be fine. (Neglected Implementation)* I can still have the error-free software flashed at the customer's company. The error doesn't occur that often. (Neglected Implementation)Does any of this sound familiar? Do you feel the same horror and anger as I do when I hear that?Right, it's all about culture and attitude, and that's what makes it so difficult. Soon I'll be writing about how to change it. Subscribe so you don't miss out.Let's now discuss the individual phases:DCVIDefinitionThe definition phase involves precisely defining the project or undertaking.Regardless of the time period in focus, be it days or weeks for a sprint, months for a product increment or years for a large project, the definition phase must always be taken seriously. The first step is always to define the goal.What outcome should be achieved by the end of the activity?Even in large, long-term projects, it’s crucial to carefully consider what truly should be accomplished with all the money and resources invested.Precisely distinguish and decide whether “nice and beneficial” goals can realistically be committed to within the available timeframes, resources, and budgets or if “necessary and important” goals are the only feasible options.All too frequently, I've witnessed projects begin with a specific objective, only to have it change as obstacles appear and something completely different comes about.The actual need is not being met, but the outcome is novel and different from the status quo. A significant amount of money has been invested with little to no return.The goal can vary in specificity, but it must be clearly defined, documented, and effectively communicated throughout the entire project duration to ensure traceability.The same applies to the second step, the plan. There must be a plan! I always say, “As soon as the plan is finished, you might as well throw it away—because things will turn out differently anyway.”And that’s true—but it’s not a bad thing. The team's thorough consideration and comprehension of the relationships, dependencies, and procedures is what matters utmost.The real value isn’t in the plan itself, but in the understanding that comes from planning. Still, it’s essential to document it properly.The final step is the definition of boundary conditions and system interfaces.System interfaces must be considered, and boundary conditions must be clearly defined. Again, understanding is the key outcome. Everyone needs to know what they need to consider so that their colleagues can work effectively, and the whole system functions as a cohesive whole. It's vital that everyone is fully involved — even those departments whose main involvement comes later in the project. Production and after-sales also need to identify and communicate at the start of the project what needs to be planned and specified concerning their areas of responsibility throughout the project. The attitude of: “I'll let the engineers develop it first, and when the product is ready, I'll just look at it and reject what I don't like” is not acceptable.CreationIn the creative phase, solutions are explored to achieve the goals. There are established processes that allow for systematic and focused work, but it's also acceptable to explore different approaches and then select the one that offers the best compromise.Given the high volatility in this phase and the frequent changes in interface requirements based on solution maturity and selection, close collaboration is essential. During this phase, it is highly beneficial for all involved parties to work together, with ideally dedicated resources focused solely on the project at hand.All solutions must be developed and completed during the definition phase.However, I often find that developers are left to develop first, and other departments only start thinking about their solutions later. This approach is wrong!Everyone has to be creative and work out their solutions at the same time and also be ready at the same time.At the end of the creative phase, the product is defined, the production processes are designed, the suppliers are known and involved, the after-sales concepts are in place, etc. Now the creativity is over. I always say: It's like school. At the end of the exam, pen, and paper are collected. Then the teacher marks the mistakes and if the performance is poor, the mistakes have to be corrected by the student.In our case, reality is the teacher.That leads us to the next phase, validation.ValidationThe validation phase is about finding out if everything works as intended. This involves testing the product, production, etc.Changes are only allowed if errors are identified that need to be corrected.A major challenge in this phase is maintaining the necessary determination and persistence to stay on track.„I’ve come up with a better solution,” “I found a cheaper supplier,” and similar statements are no longer acceptable.This is a significant challenge, as it's hard to resist when there’s an opportunity to save money. However, what is often overlooked is the impact of the substantial quality costs that can arise from these late changes, as it becomes impossible to properly validate them at that stage.ImplementationIn this final phase, absolute consistency is the top priority. This is the time of the absolute change stop. Now the processes are ramped up and accelerated to the planned speed. In sprints and PI’s, the result is finalized, firmly anchored in the systems, agreed and communicated within the organization. The achieved result forms the foundation for the next iteration of the project and, at the end of the project, for customer satisfaction and thus the success of the company. Therefore, this phase must be completed with the utmost discipline and carefulness. At the end of the implementation phase, there must be no way back and no open issues remaining.Tips for practical implementationPlanningUse the four phases as headings in all your planning, under which you assign the specific deliverables, to-dos, or tasks.This makes it clear and transparent in which phase you are currently in, allowing you to align the planning purposefully for each phase.Make sure that at the end of a phase, it is truly completed, and no significant backlog carries over into the next phase.List of required participantsCreate a detailed checklist of all relevant stakeholders, participants, and departments involved, including specific names and departmental identifiers where possible. Review and update this list regularly to ensure comprehensive coverage of all business and project aspects, avoid gaps, and ensure completeness.ChecklistCreate a planning template in which you compile the most important, recurring deliverables, to-dos, or tasks.ReviewConduct a detailed review at the end of each phase, where the results are thoroughly discussed with the team and management.Decide that the results are as expected and will therefore be finalized and frozen. Communicate clearly that no further input will be considered in any of these areas.I will further detail each phase in the upcoming articles and dive deeper into implementation and change management. So subscribe if you're interested to make sure you don't miss anything!If you have any questions, need my help or want my advice on setting up your very own lists, you can contact me in chat.If you found this helpful, don’t forget to share it with others who might enjoy it too! Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe