“We’re blessed that there are no alternative facts for physics”

Wilhelm Claussen can tell you everything about what it means to be a project leader and how to get to success with your team. But there are more angles to project leadership. You also have to ‘influence without power’: keep higher management involved and stay connected to peers like system architects. Project leaders have to be aligned to stay on the right track.

Starting with the upper layers, Claussen immediately dims high expectations. “Having been in higher management positions, I can tell you that there you have very limited insight in the projects that are running, as you’re constantly being tossed around by the various calamities.” That’s why it’s crucial that project leaders understand how they communicate upwards, he says. “You need to do that in a way that people above you can hear and understand you. It’s the first step to be helped.”

Claussen points out that it’s extremely important to have a relationship with your project sponsor or customer. “That of course builds over time. The question then should be: how do you build this relation? Communicating with management follows the same rules as communicating with your team. The main point is: be consistent in your communication. In short, for management, you must come across as straight and reliable. And you have to achieve, but that’s the name of the game.”

As a mandatory prerequisite for consistent communication upwards, Claussen mentions that the project leader himself needs to be aware of the actual project progress. “You have to honestly answer the question: am I on track or am I not on track? You shouldn’t accept bad quality in your project, just for the sake of ticking off a box in time, because this is going to haunt you. Better limit the number of boxes to be ticked in the beginning, by using a smart project setup. Otherwise, this is going to fall back on you much, much later. It’s pretty much like the statement accounted to US president Eisenhower: ‘No one has time to do it right the first time, but everybody has time to take a second look and do it over again.’”

What if problems arise or things really go wrong?

“Then you need to be clear and communicate bad news to the management and sponsors above you. And you must take painful decisions, in a courageous and well-balanced way, as early as possible. People have the strange tendency to close their eyes and avoid a bold decision because they might be wrong or they’re afraid of the consequences. But with every delay, you’re driving further to the cliff.”

“A very funny Roman saying goes: it’s better to be the fool of all the people than to postpone a decision because you’re afraid of becoming a fool. Yes, decisions can be wrong. Did I make the wrong decisions? Of course. But the moment you recognize that you made a wrong decision, and if you have a good track record in your project team, you can stand in front of the group and say: ‘Sorry folks, the last four weeks, we were marching in the wrong direction. By the way, yesterday evening I recognized that. This is why we’re changing today. We’re now heading for that direction.’ If you have a good team, they’ll turn with you as one man.”

After getting some headwind…

“Not at that moment, if you’re working with professionals. The worst will come next Christmas party because then everybody will make jokes about you, but that’s the price you have to pay.”

Trainer Wilhelm Claussen. Photo by Fotogen Fotostudio.

Other rules?

“Similar to the communication with your project team. Like being extra careful with silence. If you don’t hear anything from a particular stakeholder, project sponsor or supplier, it doesn’t necessarily mean that it’s good news.”

Do you have experience with that?

“You call it experience, I call it failure. I remember our team in Korea was waiting for a turbo booster pump shipped from our parent company as the critical delivery to the production start of a newly built factory. The agreed delivery date came and we all went to the airport to pick it up. But when the airplane landed and the hatch opened, we were staring into an almost empty cargo compartment. No pump. Only then, when I furiously called my sponsors, they told me it would arrive three weeks later as they had rerouted the device scheduled for us to some other construction site. And of course, the sponsors did know about that issue earlier but failed to communicate that. So, when the project part – in this case, my superiors – doesn’t inform you about flaws ahead of time, it deprives you of all options to counteract. That’s why you have to act yourself if you don’t hear anything.”

Does that require a specific character?

“I’ve seen lots of different characters that were good project leaders. I don’t think a specific personality is required. Of course, you have to like dealing with the unexpected and making things work. But the weak spots that arise in projects are always pretty much alike and rarely related to the character of the project leader alone. It’s usually a sequence of events that leads the project into the ditch. Failure is also a team effort. The good news is that you can learn to prevent it. If you keep an eye on those essentials and develop a sensitivity for your blind spots, you can make sure that your project has a much bigger chance of success, regardless of the chosen method or methodology or your personal character. That’s also what I transmit in my course at High Tech Institute.”

In high-tech companies, project leaders operate very close to system architects. What’s their relation and how do their tasks differ?

“For me, system architects are the caretakers and wardens of the functional integrity of the system throughout all levels. The project leader is the person that concerts, aligns and coordinates the work along a timeline to make the functions of the system available to the customer. I have very good experience in dealing with system architects. The project leader will provide them with the environment for decision-making, for example with discussions in change control boards, supporting and structuring their requests and allowing them to process their input according to an agreed rule set. The technical decisions I basically leave to them: which functions or features to include or exclude. But I hold them accountable for the technical content, for following the rules and for proper alignment. No lonesome cowboys!”

Can you tell a bit more about the interaction with architects? Presumably, there can be heated discussions sometimes.

“For sure, there can be heated discussions. It’s important to manage these people as well as the technical subjects in a well-balanced manner. Let me give you an example. I once had an issue with one of my piping architects. Through a lonesome design change, he managed to increase the amount of excess heat that had to be removed from the system literally overnight by almost 30 percent. When I challenged him on this in the team meeting, he basically replied: ‘I’ve done that because it’s necessary; you wouldn’t understand anyway.’ At that moment, the communication went completely out of control. I intended to make him explain his measures to the other architects and follow the agreed rule set for alignment. He understood this as ‘this guy is challenging my expertise’ and in return challenged my position as project manager.”

How did you resolve the miscommunication?

“Well, this is the funny part. First, I was about to jump on him, but fortunately, the miscommunication became clear to me just before I did. I started laughing, and after my explanation, he cheered up as well. He then wrote a note to his colleagues, giving the details of and the reasoning behind his design change. In the CCB meeting the following Friday, he got consent from all stakeholders in the project – for a good contribution that had almost ended in a bitter fight.”

Photo by Fotogen Fotostudio.

In technical environments, some people are more square than others. Is that a challenge for a project leader?

“I don’t think so. We’re privileged to work on technical stuff with other educated people. At the end of the day, we have an objective rule set that everybody agrees to and that’s called physics. As long as everybody agrees to this rule set, you’ll always have an objective way to settle a technical dispute in a development project. Sometimes, of course, it can bend a bit left and right before finally coming to a conclusion. We’re blessed that there are no alternative facts for physics. Or to cite the Nobel prize winner Richard Feynman before US Congress when NASA tried to cover up the Challenger disaster: ‘Physics doesn’t care about marketing.’”

Do projects in the high-tech region around Eindhoven differ from an environment like the automotive industry in Germany?

“I think they’re both high-tech, highly integrated, both are hardware driven with a strong software component. From that perspective, they’re relatively comparable. In general, the major differentiator is between realization projects and development projects. In a realization project, you usually have a clearly defined achievable goal, a lot of manufacturing people who are used to following orders and performing tasks in a structured way – you ‘just’ need to get it done in time. Development environments are more interesting. There, the path to success is less clear and even the goal is sometimes uncertain. And you’re dealing with developers, usually very intelligent individuals, who perceive themselves as hidden geniuses – some of them really are. In this case, the leadership challenge is to include them all in the common goal. For that, you have to lead them, guide them, motivate them to deliver a concerted action.”

Some of them will work on a new functionality every day if they have the chance.

“And if they do, you have to cope with it constructively. By asking yourself: is this benefiting my customer, is this fitting into the integration? You actually have to foster this in the early development phase. Because this is your only chance to make a product that’s different from what’s already existing.”

But you have to be very careful with that?

“Yes, I can fully subscribe to that. You must balance it in a structured way. I always rely on the technical experts and architects in my team. They make a balanced and structured assessment of this new idea to incorporate it, yes or no.”

Your new course at High Tech Institute is focused on project leadership, not on project management.

“The reason to focus on project leadership is that project leadership is the art to influence the pace, focus and goal of the project. Along the way, you provide guidance and insight to the team. You have to be the man on deck – that’s what project leadership is about. Project management is the set of means and methods to have a transparent, clear and structured communication and framework. It’s a kind of a basic condition.”

You teach this course in one day. What do participants take away?

“I don’t like the word ‘teaching’ when it comes to leadership. This course is designed for people who already have project management and project leadership experience. I prefer to say that I’m sharing the essentials I’ve gained over the last twenty years in high-tech project management. Participants will be taking away a fresh and independent view on how to manage their projects better, by focusing on a few aspects to make sure that they’re followed. It’s not a project controlling course. The key to success is to not lose the overview and I show how to keep that overview in a complex and fast-changing environment.”

This article is written by René Raaijmakers, tech editor of Bits&Chips. Trainer Wilhelm Claussen. Photo by Fotogen Fotostudio.