Month: November 2021

Dynamics plays a key role in overall system performance. Design choices can have severe consequences. Therefore, it is important to choose the right direction from the start and to substantiate the concept with modelling techniques. “You have to take into account all your forces and interferences, and position the sensors and actuators correctly. Trainers Dick Laro and Adrian Rankers ellaborate about their Dynamics and modelling training.

With each successive generation, the bar for high-tech machines is raised. The new system should move faster or more precise. Design choices from the original development process might turn out to be unfortunate. Eigenfrequencies and vibrations, which were still negligible in the first machine, suddenly put a spanner in the works. At an precision requirement level of typically around ten micrometers, it becomes a real challenge to keep the dynamics of the system under control with standard design rules.

Designers may still know dynamics theory from school, may even have done some calculations, but they often lack the know-how to translate that knowledge into their current physical machine design. “How does the dynamics relate to errors in the system and to the stability problems in your control loop? How do you model that? And how can you then use those models to achieve a better system?”, says Dick Laro, system architect at MI-Partners and teacher at High Tech Institute. During the training ‘Dynamics and modelling’ (DAM), students receive answers to these questions. “We make the link between theory and practice, and between the various subdisciplines. How does the dynamics interact with control technology? And how does the mechatronic design fit in that picture?”

Laro and co-teacher Adrian Rankers use the practice of starting small and simple, and expand later. “I always begin with a bottle on a rubber band – a very basic mass spring system”, says Rankers. “If you understand the basic dynamics of this, you are already well on your way. Then, you have to understand how to describe vibrations of more complex objects.” He takes a sheet of paper, starts bending and twisting it, and says: “There are all kinds of mode shapes in this; shapes that you can describe using modal analyses. In order to design a stable system, you have to understand it, see that one point moves faster than another and that there are even points that move in the opposite direction. This has consequences for the actuator and sensor location, among other things.”

Interferences

According to Rankers, there are two reasons why it is so important to understand all those mode shapes down to the last detail. “One side of the story is that vibrations lead to accelerations and thus to forces. They can seriously hamper your control. Moreover, when two connected parts move with each other, a force is transferred. But that transfer is never 100 percent; there is always some distortion in those parts, certainly at the micrometer and nanometer level.”

“The other side is that in all systems you have to cope with interfering forces,” Rankers continues. Think cables that keep vibrating, friction, all kinds of forces from the process and of course external disturbances such as floor vibrations and acoustic excitation. You have to take all those forces into account. “And every force has a counterforce. A stage pushes against a machine frame that gives back a reaction force. After a while, the two of them are shaking happily.”

When you know all those disruptive forces, you want to control them. “With an expensive measuring system you can accurately determine the relative position of objects. Then you try to straighten things out with corrective forces,” explains Rankers. “You want to do that with a frequency as high possible, and as rigidly as possible. That means a high bandwidth in your control loop. Then you have a stiff coupling between those two objects. However, there are limits that are determined, among other things, by instability in the control loop. And it is precisely those vibrations that can make control loops unstable.”

Magic words

The ultimate goal is to provide insight into all vibrations in a system. “From modal theory you can describe all complex mechanical systems as a sum of a mass-spring systems,” says Laro. “Some have a phase that matches, others move in the opposite direction, making the dynamics more difficult. Still, you can build the larger system from easier-to-understand subsystems. We explain how you do that in the course.”

Dick Laro.

FEM tools are perfectly capable of calculating the modes of those subsystems. “That’s nice, but you don’t design a machine based on mode shapes,” warns Laro. “It is certainly not obvious how to link those sub-results back together. How does that mode shape relate to a transfer function and a system error? How do the mode shape and the eigenfrequency relate to the bandwidth? And more practically, where should I place my sensor and actuator to be able to suppress that one disturbing mode?”

Rankers answers the last question: “It will probably sound as a no-brainer that it is a good plan to drive a system at the center of mass. But that isn’t always an option. Perhaps there is an optical element in the way and you have to let the force apply to one of the corners. Is that okay as well and what is the effect on overall system stability? And where will you measure? Perhaps diagonally opposite might be best because you are close to the point of interest there, for example close to the wafer. Then you do not necessarily measure at the place where you actuate the system, so you are confronted with all kinds of modes that increase the chance of instability.”

Adrian Rankers.

“You will need to model the system in order to estimate whether or not your design choices are allowed,” Rankers continues. During the High Tech Institute’s ‘Dynamics and modelling’ training, participants experiment hands-on in the 20-Sim simulation package. Laro: “How bad is it if I don’t actuate in the center of mass but an inch off? How far can you go and what happens if you go too far? Modeling and evaluation, those are the magic words, because it is very easy to mess things up.”

Rankers again: “You always start with a list of requirements and wishes, nothing more. Then you need to carefully consider what the right choices are and what you can better avoid. In that respect, it is a knockout race. Because you understand what happens in the dynamics and how you can correct for any disruptive forces, you can make a good assessment at an early stage. Some ideas look better than others, so go with those. In 2D, in 3D, until you get to the finite element analysis. That is why you optimize the system, but you can’t solve choices with it that are fundamentally wrong. On a conceptual level, your design has to be good.”

Four essential tips

1. No component is infinitely stiff. A block of metal and even a chunk of granite have internal mode shapes and can deform. A rule of thumb is that if you want to achieve a bandwidth of 200 Hz in your control loop, all other vibrations – including the internal ones – must have a higher frequency by a factor of 10.
2. A guide does not have infinite stiffness either. In any case, you don’t want to rely on that stiffness at all. In a linear system this means that you want to actuate in the center of mass. Actuate the part so that it does exactly what you want even in the absence of that guidance.
3. Think about the mass proportions. In the CD-actuator, for example, that turned out to be a nightmare. In the first generation everything was bulky and there was no problem, but in later generations there was a considerable challenge because the mass of the part that had to move aproached the mass of the ‘fixed’ world.
4. Be aware of the reaction forces. The force you use to drive the stage, for example, always has a counter force. That force goes to the machine frame and probably also to the sensor block that is attached to it. In short, you excite the sensor block through the reaction force. And a vibration of the sensor block can be seen in the sensor signal just as well as when the stage moves. So you have to include the full reaction path.

This article is written by Alexander Pil, tech editor of High-Tech Systems.

We’re working in the age of integration, where lonesome inventors can only make an impact with a good team. In this second interview, Wilhelm Claussen, project leadership trainer at High Tech Institute, talks about the changing environment of system integration, how cultural diversity benefits project teams and the challenge he specifically sees for the Dutch.

When Wilhelm Claussen told his brother ten years ago that he was going to ramp up a manufacturing site in the Netherlands, he got laughed in his face. At that time, his brother ran a factory for building specialty machines in Germany, employing several hundred. His advice was: never manufacture in the Netherlands; you’ll only get individual parts made by individuals and sometimes they may even work.

“The general perception of Germans being more process oriented and disciplined and the Dutch being more chaotic and more creative has some truth in it,” Claussen admits when asked about the impact of cultural differences in projects. “I always appreciate working with Dutch people. They’re more daring, more inclined to look for opportunities, rather than coming up with reasons why something can’t work.”

Project leaders can benefit from both, Claussen argues, but you need to balance them. “Especially in development projects, you immediately recognize that there’s a certain period when you need to embrace change. In the beginning, you need creativity and you want to foster a positive drive for new ideas. Later on in a project, there of course comes a time when you need to make sure that you’re going ahead in a structured way.”

Trainer Wilhelm Claussen. Photo by Fotogen Fotostudio.

Can this chaotic behavior of the Dutch be a hindrance in projects?

“I wouldn’t say a hindrance. Wherever in the world you want to be successful in whatever project, you must always accept that the people in your team are the best people you can have at that moment. You have a goal, and you need to perform. The challenge is to get people moving in the same direction with the same pace, with the same sense of quality and with the same objective. That’s what you need to get going. For that, you need to utilize the cultural differences to make sure that the right person is in the right place in your project.”

So what did your brother not see?

“First of all, I think he was just nurturing his stereotype that Dutch are never able to run straight on a straight line. In that particular case, I was establishing a manufacturing process and that has always its own challenges. To get things done, you need to find the right contributor for each spot. That’s the same anywhere in the world. The bottom line is that our team succeeded, got the products out, outpaced all competition and were first on the market.”

But there’s an increasing challenge for the ‘Dutch way of working,’ Claussen warns. “When we look at current innovation processes in technology, most are combinations of known things. To make an innovation work in a product that’s useful for a customer, it needs to obey and follow a lot of already established interfaces because most of the time, we aren’t innovating, we’re mainly neatly integrating things.”

This is the age of integration?

“I think that’s exactly what we should call it, the age of integration. Even a fundamentally new invention needs to connect to a lot of interfaces and obey rules before it becomes useful for the customer. That means that you have to maintain a lot of discipline and structure before you’re actually rewarded with the benefits of new contributions.”

Why is that so difficult?

“Because it means that nobody can be an individual inventor anymore. Besides having a brilliant idea, which remains an individual act of creativity, the inventor needs to collaborate with a team of various people and disciplines to make the invention work. Every contribution nowadays is blending into an architecture with existing interfaces. That means the mandatory prerequisite for obtaining a working system is to understand how all the blocks or elements are working synergetically together with your new functionality, solution, idea or concept. For example, the first cars were made by only a few persons, visionary but lonesome inventors and investors. If you now look at a Daf truck, you see a system with a huge number of complex elements with interfaces that you must adhere to and operate with flawlessly. Lonesome inventors just can’t excel on their own anymore.”

And all basic elements are more or less invented?

“Certainly not. If you say that, you’re underestimating the creativity of some mad genius developer who comes up with some completely new concept. The point is that his new concept has to be integrated first to become useful. In engineering, we’ll keep on inventing new solution principles. I don’t think this will ever come to an end, but to integrate these and develop them into a product will become more challenging.”

And you presume that this is more challenging for the Dutch than for the Germans?

“Now, when I speak of the ‘Dutch way of working,’ I’m not referring to the Dutch as a people. I’m talking about a way of working characterized by a low level of displayed hierarchy, an accepted high degree of individualism and an optimistic and pragmatic attitude toward risk-taking on the way to new horizons that I’ve observed here in the Netherlands. It’s the same bold attitude that led the ancestors of today’s development engineers centuries ago to climb aboard small wooden sailboats – crazy, I say – and set out for the East Indies. That in itself is a very positive attitude. But in the age of integration, it must be accompanied by serious efforts at quality, structure and speed in system integration to turn an invention into a perfectly functioning, marketable product. And my observation is that the art of integration is a topic where we can learn from others, namely from the Asian environment. Our task in development in Central Europe will be not to lose the advantages of the ‘Dutch way of working’ and remain professional and fast in system integration. This will demand new qualities in project leadership to keep all that jazz in a healthy relationship with each other. That’s to say, Germans or whoever can also work ‘the Dutch way’ and will have to face the same challenges. I’m an example of this.”

Is inventing more like combining known technologies and is systems engineering getting more complex?

“I don’t like the word ‘complex’ because it’s a relatively unsharp term, often used in the context ‘being difficult and not clear.’ I observe that nowadays, we’re integrating subsystems to fulfill very specific purposes. That’s leading to a completely new way of managing product lifecycles and system integration requirements. I don’t see this race for complexity continuing endlessly. We’ll be building more for purpose.”

“For example: 25 years ago, automotive suppliers were building ten different water pumps for car manufacturers to choose from. They were attached to the motor using an external bracket and they were ready to go. Nowadays, each variant of a car type has a sophisticated supply chain for its own optimized water pump. If you’re buying a Volkswagen Golf with a combustion engine, there’s a pump for each variant of that engine. Bottom line: the component itself may get less complex. It can be simpler because it has to fulfill fewer purposes than each of the former ten variants of water pumps, which had to do basically everything.”

What’s driving this?

“The driving force behind this kind of segregation of variants is the fact that we’re using only the fully integrated products. Customers want a perfect car, not a perfect water pump. They don’t pay for that. That basically means the water pump needs to be just good enough for the user profile of the car buyer.”

When it comes to system design, there’s a big difference between building specialty machines and high-end consumer products like cars, says Claussen. In the consumer market, you can design the component lifetime. “The rear lights of modern cars are designed to work during the whole lifetime of the super system. You can’t exchange individual LEDs anymore, only the complete module. So, you must understand in detail the aging behavior and the major reasons why your devices fail – as part of your design and development process.”

In specialty machine building, Claussen says he has so far not seen anyone designing for reliability. “Designing for a certain lifespan of the complete system, I mean. When you buy plasma deposition equipment, an extruder or a wafer scanner, they’re built to be repairable and upgradable. As such, the chosen system architecture makes it possible to extend their life almost indefinitely. This is a system choice you must make deliberately and really early in the project.”

“A good project leader repeatedly asks the developers: what are the consequences for the customer who uses your product?” Photo bij Fotogen Fotostudio.

You and your development team need to understand from the very beginning what your product is going to be in the end?

“That’s why it doesn’t help if you just say systems engineering is getting more complex. You must consciously make fundamental choices on scales like ‘indefinite lifetime’ concepts versus ‘the first fail that kills the system’ concepts. And this happens very early in the project, when there’s still a lot of uncertainty and ambiguity.”

“Here, a good project leader comes into play. He needs to get the required expertise together on one table and has to drive his people into a corner where most developers are feeling uncomfortable, by asking them repeatedly: what are the consequences of your decision for the customer who’s going to use your product? Will it help him solve his problem? Is he going to be happy with it or not? Do the customer’s wishes match the product that you envision yourself?”

Why do developers feel so uncomfortable with that?

“When you look at conventional education, most of the engineers are taught to look downwards into their system. They’re experts in delivering detailed solutions to problems someone else gave them. Now, in the age of integration, we must turn this around to be effective and efficient with our solutions. When we turn it around and ask engineers whether they’re about to solve the right problem for the customer’s value, most will feel uncomfortable in the beginning. The good news is: I’ve never experienced that a smart engineering team isn’t capable of answering these kinds of questions once they embrace the importance of it and recognize the way to get there.”

So, a project leader has to recognize the kind of project he’s dealing with and set priorities accordingly?

“This is exactly what I expect from a good project leader. That he can slice down the problem. In doing so, he consciously identifies what is the right approach for which part of his project. If he can’t, it’s going to be a failure. If he can, it’s going to be a thrill ride.”

To explain what this means for project leaders, Claussen draws a comparison with dropping paratroopers. “When they land in a field after jumping from an airplane, they don’t start running in all directions. The first thing they’re supposed to do is look around, gather intel and understand where they are. That’s exactly what a good project leader does. The first thing is to make sure the people in his group understand where they are and where they need to go. That’s step one, always. If you obey that, I think it’s completely irrelevant whether you’re developing a water pump or an X-ray scanner. Because you bring into your team the persons with experience for making a pump or an X-ray machine. A project leader doesn’t need to have all the experience for that. I would even say it’s more important to have a well-developed awareness of your and your team’s limitations and blind spots. And of course, a methodology needs to be established to digest all relevant system architecture aspects before you start running. Then you may make very conscious choices for all different aspects within your system architecture, including reliability, performance, redundancy, repairability and so on. All these decisions have to be made at the beginning of your development. Providing structure paves the road to success. And if the development succeeds, it’s highly satisfying.”

This article is written by René Raaijmakers, tech editor of Bits&Chips.

Taking a swing at his 3rd career opportunity, High Tech Institute trainer Kees Rijssenbeek has found his cup of tea and his calling. Now, he’s putting his energy into helping technical minds navigate challenging social interaction and giving them the tools, and knobs, to help them fine-tune their approach.

After a few years of trying his hand at mergers, acquisitions and employment law with the Dutch office of the US-based multinational law firm Baker McKenzie, Kees Rijssenbeek realized that corporate law just wasn’t his thing. “In hindsight, I guess you could say the company was much clearer on it not being my cup of tea – more so even than me,” recalls Rijssenbeek jokingly. “In law, you either move up the ladder or you’re out. And while I was just starting to entertain the idea of becoming a partner, it turns out the firm didn’t share the same vision, so out I was, along with about two-thirds of my colleagues.” Rijssenbeek continues, “It turned out to be a blessing in disguise. Looking back, the 80-hour work weeks with troves of legal paperwork was never going to make me happy.”

Kees Rijssenbeek: “I came to the realization that the most exciting and interesting part of any of my jobs was the personal human interaction.”

For his next move, Rijssenbeek had a go at the retail domain, where he contributed to the marketing and commercial team of the cosmetics brand Rituals. This was during the brand’s early days, when it was just working to make a name for itself and had only one office in Amsterdam with about ten employees. “While it was a big change from corporate law, I found I was having the same kind of feeling. For the most part, it was just a job and didn’t really give me any energy,” remembers Rijssenbeek. It was then that he began thinking about what would motivate his interest. “I started to take some personal training courses in my free time to discover who I was and what I wanted. I came to the realization that the most exciting and interesting part of any of my jobs was the personal human interaction.”

“Looking back at this part of my life, I realize two things. First, I’ve always been interested in learning about people and I’m good at listening and truly hearing what they have to say. Of course, it was coming to the business of training that helped me come to that realization,” suggests Rijssenbeek. “The second thing is, I really should have purchased shares in Rituals way back when it was so small. I guess we learn a lot of things in hindsight.”

 

Jealous

Now in the professional training domain for the last ten years, Rijssenbeek seems to have found his calling, or his cup of tea, as it were. Three years ago, he joined the High Tech Institute team where he delivers the training “Effective communication skills for engineers” aimed at helping technical people master some of the biggest communication challenges and pitfalls. But it’s working with this particular audience of highly technical people that leaves him a little envious.

“Not to generalize too much, but something I notice in many technical people is that they have a few traits that I’m pretty jealous of. One is that they’re pretty humble and have good insight into the limitations of what they know and what they don’t yet understand, be it in the laws of nature, the laws of physics or beyond. They’re also wired with a very real desire to solve problems,” illustrates Rijssenbeek. “There’s sort of an absence of the whole political way of dealing with each other. They’re interested in, does it work? If it does, great, we’ll use it. If it doesn’t, then it’s right back to the drawing board to find a solution. It’s not about getting all the credit. That’s certainly not the case in business law and marketing.”

 

Knobs

That said, there are also some common obstacles that prove to be a challenge for many technical people, especially in communicating. For instance, spending a lot of time in circular conversations and getting nowhere, having trouble getting buy-in from stakeholders or coming off as too critical when delivering feedback. While in the technical world most issues can be quantified and calculated, using data to make assumptions, when it comes to personal communications, it can be a little more challenging if you don’t know what cues to pick up on. And it’s to this end that Rijssenbeek looks to help guide training participants.

“From miscommunications to personal life issues to people just having a bad day, there are a number of factors that affect interpersonal communications. What this training is all about is to teach some of these basic knobs that can be fine-tuned to help people communicate more effectively,” highlights Rijssenbeek. “The first and probably most important knob is active listening. As simple as it may sound, active listening is often completely overlooked and underappreciated.”

According to Rijssenbeek, in the high-tech domain, when surrounded by highly intelligent experts, people often think they’re on the same page and have come to an agreement, only to find later that they interpreted the conversation completely different. “Too often, we fall in the trap of being stuck on send, rather than receive, or truly listening. Active listening takes practice and effort and requires someone to turn off their desire to jump in, to really hear and understand what someone is saying,” explains Rijssenbeek. “The easiest way to do this is to listen intently and then give a summary response to ensure understanding. It might sound easy, and it can be, but that’s one of the most effective parts of the training.”

Another knob used to help promote effective communications is the nonverbal cues, like body language and facial expressions that we use to communicate. “Nonverbal cues can be difficult for technical people to pick up on. With many of them tending to have their focus on content rather than interaction, they often have the expectation that others perceive things the same as they do. Reality, on the other hand, suggests something else,” says Rijssenbeek. “That’s why we spend the vast majority of the training practicing these and other skills. This isn’t a course based on theory and endless discussions, it’s about putting it to practice and trying to build new habits to better navigate communications in a technical workplace.”

This article is written by Collin Arrocho, tech editor of Bits&Chips.

As a project leader, you have to be clear about your personal boundaries, says Wilhelm Claussen. Bringing with him experience in the semicon, automotive and special equipment industries, he’s starting as a trainer in project leadership at High Tech Institute. In this interview, Claussen talks about what makes a project leader and the dos and don’ts.

“With the right attitude, the right focus, the right spin in the right team, you can do pretty much anything, regardless of the cultural backgrounds of the people in your team.” Wilhelm Claussen raises the subject when asked about what influences development projects. According to him, the most important component is leadership. The term keeps popping up in our conversation. Claussen himself has plenty of experience in this field, having led tech development projects throughout his whole career in automotive, semicon and special equipment.

To kick off with the basics, Claussen underlines that he likes to separate project management from project leadership. “Project management is administration. It builds an environment for the project execution. The leadership part is about the people. It gives them a focus, the right pace and the right goal. To phrase it differently: bad project management with good project leadership may still prevail and give good results. Good management with bad leadership will result in a well-documented disaster.”

In the same vein, Claussen argues that the success of a project isn’t dependent on the chosen methodology – Prince2, waterfall, Agile or whatever. “The essence of success in projects is leadership, recognizing and sensing ahead of time if something is missing or looking strange.”

Trainer Wilhelm Claussen. Photo by Fotogen Fotostudio.

Flawless execution

Claussen started his career in the mid-nineties in the Dresden wafer fab for DRAM memory chips of Siemens Semiconductors. “That might sound boring and traditional, but at that point in time, I experienced an environment with a real startup mentality. Siemens had almost missed the train in the microelectronics race and got a last chance to succeed.”

By the time the chip activities were spun out as Infineon in 1999, Claussen was ramping up wafer fabs around the world. “Basically, we transferred process technology from Dresden to fabs in the US, China and Taiwan.”

The big challenge was to flawlessly copy technology while it was still in development. “It was highly dynamic and had to be done with an extremely high pace. Especially in the DRAM business speed matters. Every month of delay translated directly into lower margins. The key task was to establish a robust but flexible project structure enabling the transfer of a manufacturing process of six hundred individual steps and make it work at a different site thousands of kilometers away. All the while, the process itself was still in development. That meant we had to be flexible for adaptations that were coming out of Dresden with respect to recipes, tools, sequence changes and all these things while being crisp and clear on the verification of the results on our product.”

Asked about the importance of a flawless project execution here, Claussen answers: “It’s really pretty simple. If you do anything wrong, the chip is dead. If you miss even a detail in one of your six hundred process steps, the result is very expensive scrap. We were transferring the processes to running foreign factories. There, we had to deal with different rule sets, different toolsets, different languages and, last but not least, different mindsets of the engineers.”

Later in his career, Claussen worked in the automotive industry and for special equipment companies like ASML and Roth & Rau (now Meyer Burger).

Outside view

Talking about the dos and don’ts in project leadership, Claussen dishes up four focal points. The first: never lose the main line. “In two minutes, you have to be able to explain the main steps and how you want to achieve the goals. The moment you realize you can’t, you need to rethink your strategy. Funny enough, I also do that in daily life sometimes. Just to check whether I can still cover it all. Once I recognize that I’m no longer able to summarize my project in two minutes, my alarm bells go off and I basically start to rethink my project. Otherwise, complexity will kill you. You’ll start to make mistakes, overlook things and at the end of the day, you’re exhausted and your products are dead.”

The second pitfall is ticking off boxes blindly. “Check, double-check and check again. Make sure you’re aware of the real project progress.” Claussen explains that this is all about creating an unbiased and independent outside view of the project. “Because you have to recognize that the moment you’re following a certain sequence or a manner of asking about the project progress, the system will start to bend to satisfy your request.”

Claussen developed his own methods to avoid this. “I frequently force myself to change the way I look at the progress of the project. And in doing so, I’m able to challenge the way the team reports progress. I do this to understand whether the people are actually delivering in time and if the reports are reasonably correct.”

“People in an automotive company could be rewarded for mounting wheels on cars because, in this company, this should be the last thing you do in manufacturing,” Claussen illustrates. “If your metric of project success is based on mounting four wheels on every car, you create an intrinsic opportunity for people to adapt to the metric rather than to the real progress by mounting wheels to even unfinished cars. This is normal human behavior and as a project leader, you constantly need to prevent these kinds of distortions. If you publish a reporting request, people will naturally try to look good in this reporting. And they’ll always report in the way that was successful last time. So you have to avoid that because you want to make sure that no one is ticking off boxes blindly and that people are reporting the real progress that they’ve made.”

Claussen’s third point is also a don’t: never delay required decisions, as hard and as painful as they might be to take and to communicate. “Naturally, you can expect headwinds and hiccups there. This is what real leadership is about. You should do this early and intelligently. Because this is a delicate subject, which can also seriously limit your career if you do this wrong. Nevertheless, it’s extremely important to act early after you’ve become aware. With an early decision and an early maneuver, you can maintain the legroom to counteract.”

His fourth and last advice: never take no news for good news. “The fact that you don’t hear anything from a certain project part doesn’t mean that they’re making progress. De-commitment is always silent. Later, it will come to haunt you for sure. It’s actually a little brother of the third rule because the persons not communicating their problem are basically avoiding the decision to communicate. As a leader, you need to recognize this. You have to understand: wait a minute. These guys haven’t talked to me for the last two weeks. Why is that? There can be a very simple reason. The person making the report might have had a personal problem, but there might also be a big hiccup they’re reluctant to talk about.”

Did you ever arrive at the point where you couldn’t defend your project anymore?

“Sure. And at that point, you have only two options. First, reshape your project, approach your sponsors and stakeholders and make sure that you get a new commitment to what you’re trying to change. If that doesn’t work, the second option comes into play: you have to give back your assignment and leave. This is one of the few things Donald Trump was correct in: you always have to be prepared to walk away from the table. Otherwise, you’ll become a victim. Becoming a victim is one of the traps I’ve seen many project leaders fall into – including me.”

It’s rather big trap.

“Yes, and it can lead to a lot of frustration.”

Once again: you have to have the guts to walk away?

“Yes. You won’t do that easily, but it’s very important for your personal well-being. You have to know your limits and need to communicate that to your stakeholders: that’s the red line that they mustn’t cross.”

Claussen gives an example from the time he worked in a company that developed special machines for the solar industry. Located in Korea, he was running the projects for the Indian and Asian branches. “That in itself was already quite a lot of work. All of a sudden, I received a call to also rescue a project they had running in Spain. I told them: because you have no one else to fix it right now, I’ll do this for three months, but not longer. Apart from traveling to Shanghai, Incheon and Hyderabad, I started to routinely fly to Madrid. After six weeks, I noticed that my management hadn’t taken any steps to mitigate the situation. They simply hadn’t followed up on their part of the deal and so I reminded them: I’ll do this for another six weeks and if you don’t change the situation, I’ll leave. Guess what happened? In the remaining time, they still didn’t do anything. So I left.”

Were they surprised?

“They sure were. The message I want to convey is that you have to protect yourself, and you need to be clear about what your red lines are. You have to communicate these red lines to the stakeholders and participants in the project so that they can act on them. Of course, I felt a little bit like a traitor walking away from my onsite team, as we were a good crew. Nevertheless, it was the right decision.”

Are these situations not the very nature of being a project leader?

“These situations are common in many projects. And that’s exactly why it’s so important for project managers to master them constructively. To do that, you need a certain mindset and preparedness. As a project manager or project leader, you constantly feel pressured to be faster, use fewer resources, be cheaper, get to market sooner. However, if you’re clear about your limits and constraints, your chances increase of getting across to people on the other side of the table what commitment means to a project. Commitment basically means signaling your agreement to follow the path you’ve laid out to achieve the project’s goal – nothing more, nothing less. When people’s expectations of you as the project manager become too strange, too weird and too abrasive, you have to cross the line and say, ‘Thanks, but no thanks.’”

“Being at this crossing point, it’s very helpful to realize, engagement is not a one-way subject. It’s kind of a two-way performance contract. Your sponsors can’t arbitrarily change the scope or any other agreed-upon part of the project and expect you to blindly follow. If the rules agreed upon by you and your stakeholders or project sponsors are violated, there must be consequences. If you don’t take immediate action on those violations, they’ll be committed again the next Monday.”

Claussen stresses that this has nothing to do with running away from or avoiding responsibility. “Nor is it about refusing to change. I’m talking about a serious violation of the agreed-upon set of rules by the people who gave you your marching orders without renegotiating or adjusting. And that’s where you have to be clear about where your boundaries are.”

Is staying true to yourself more important than your career?

“That’s a question that everyone has to answer for themselves. I think what’s important is that you know your own red lines and that others know that you take them seriously. No matter how powerful the stakeholders and project sponsors look, they need the project manager to get something done. So you need to be clear at the outset how much you’re committing and how much you’ll deliver, and you also need to hold the other ‘contractors’ accountable for delivering on their promises.”

This article is written by René Raaijmakers, tech editor of Bits&Chips.