The best way to a decision
One of the biggest pain points of projects lies with the project client: important decisions are not made in time. And if they are made, they are often not binding and are not supported. What to do? What may surprise many project managers: they have more power and more possibilities than they are aware of.
Project managers are like hairdressers …
The other day I had an important appointment, but the best wife objected that my hairstyle was no longer a hairstyle, I urgently had to do something about it. The hairdresser I trust had no more appointments at such short notice, so it had to be another hairdresser. It won’t be so bad, I thought …
Undaunted, I sat down and answered the question how I would like it to be, how I imagine it to be: “As short as possible at the back and sides, so that you can’t see through to the scalp („Männer kriegen dünnes Haar“ / “Men get thin hair”… Herbert Grönemeyer already knew), and a little shorter on top than now. But if you have another suggestion…?” With that I believed I had done my part of the work.
Well, the young lady wanted to know, “Shall I do that with the machine?” I shrugged my shoulders and smiled at her. She took that as a “yes.” With the hair clippers in hand, the next question was, “How many millimeters?” It was as clear as mud. “How many millimeters should I set the machine to?” she specified. “Eight or rather twelve millimeters?” I had no idea what the one and the other meant to me, but I didn’t want to expose myself. So I bravely answered “Eight”, and the young, friendly lady – now that she knew everything she wanted to know – quickly took up her work.
Back with the best wife of all, the verdict was critical. “Oh God, you can see through that! Did she cut that with the machine? Didn’t you tell her that?!” Yes, but…
Problem experts and solution experts
What happened to me with the hairdresser is something you regularly encounter in a similar way when customers are dealing with suppliers, or when project managers talk to their clients or – heaven forbid – to top management. This often has to do with the fact that we usually have different roles, but we don’t perceive them properly and don’t respect the roles of others.
In the concrete example I was the “problem expert”. I recognised the problem (after a little advice from my wife). I was able to explain roughly what the problem was. And I also had first ideas in which direction the solution could go. However, I could not describe this solution professionally. And at the same time I was open for alternative suggestions.
The hairdresser on the other hand was the “solution expert”. She was able to find a solution for my problem and to implement it. However, we did not perceive our different roles properly and did not allow each other to play them. She also treated me like a solution expert in the dialogue. She asked me questions that I did not want to or could not answer due to a lack of expertise. And in doing so, she made a mistake that many project managers also make… At the same time, I too was not clear in my communication. I shrugged my shoulders where I should have rejected the decision and gave an answer where I had no idea. And in doing so I made a mistake that many project clients and top managers also make.
Top managers are no solution experts
Exactly this game also exists in the project environment. There are problem experts who can roughly describe the problem, who understand where the shoe pinches, and who initiate or approve projects. These are often the project initiators. And there are solution experts who can develop and implement a solution for the described problem. These are usually project managers and experts who work on the project. Exactly at the interface between these two groups it crunches powerfully. This is also shown by the study “Ecosystem Project”, which was conducted by Prof. Ayelt Komus from the University of Applied Sciences in Koblenz.¹ More than 700 participants were asked which factors from the project environment have a particularly strong influence on the success or failure of a project. Desire and reality drift furthest apart where project managers have to deal with project clients and top management, namely in the commitment of decisions, the quality of specifications, the change culture of superiors and the willingness to make decisions. For me, this was a nice confirmation of an impression I have gained in my work. Because from project managers I often hear sentences like
- “To properly explain my topic/project I need two hours, but I only get 15 minutes.”
- “At the end of the appointment I will not be given a decision, but the order for further analysis.”
- “If a decision is made, it is often questioned and overturned in the next meeting.”
Do you know these and similar sentences from yourself and your colleagues? Have you ever asked yourself what it looks like on the other side?
Some people complain. And others?
That’s exactly what I regularly do, asking decision-makers how they are doing with reports and decision requests from projects. That sounds something like this:
- “Most people here seem to think that their issue is the most important one and expect me to deal with it at length. “I feel like I have to deal with 100 issues a day.”
- “In meetings, people steal my time and bother me with insignificant details.”
- “I am presented with (too) extensive documents, on the basis of which I still cannot decide. Again and again important points are missing.”
If these two laments are laid side by side, the story of a great misunderstanding becomes apparent. Some (the project managers) would like to have recognition, clarity and reliable decisions. Others (the decision-makers) would also like to have clarity, but a different kind of clarity, and they would like their life reality to be respected and brought to the point.
And because the outlined dialogue is usually a monologue and at best takes place in conversation with colleagues, but almost never between the two groups, project managers and project clients often face each other without understanding and sometimes almost hostilely, without understanding of the worries and needs of the others.
What to do? And who makes the first step?
The solution is surprisingly simple. It is important to respect the project client, the top manager, the decision-maker as a person, in his role and in the reality of his life. It is important to accept that the role of the decision-maker (problem expert) is different from one’s own role (solution expert).
Because if you approach the decision-maker properly, if you prepare documents in a way that is appropriate for decision-makers, you are much more likely to get the decisions you need for yourself and your project.
At first glance, this is bad news for some people: it’s back to the project manager, to me. I am supposed to orient myself to the needs of the management? Nobody is interested in my needs either! Are these or similar thoughts running through your head? Welcome to the role of victim!
Personally, I have a much more positive view on this: I am not defenceless, I can create! Whether and for what managers decide to do lies within my sphere of influence! When I address decision-makers according to their needs, not only they benefit, but above all I do. I get the decisions I need for my project in time and reliably. And in return I like to jump over my shadow and take the first step.
What is important to decision makers?
But how do you address the needs of decision makers? If I ask top managers what is important to them when they think of project meetings and project steering committees, I always get the same answers:
- Consider the view of the decision-maker
For most experts it is important HOW something works. And that’s a good thing, because this is the only way to achieve functioning processes and products. Therefore, these experts – and also project managers who have delved into the subject – tend to talk in detail about HOW. Many decision-makers, however, don’t care about the HOW, and whether is all the more important. In other words: how to solve the interface problem, how to ensure battery capacity or how to get the voltage drop under control is much less important to the decision maker than getting the problem under control. In general, focus on IF information and provide HOW information when asked.
- Be well prepared
Especially when it comes to top management, the quality must be right. And in most cases, this does not mean more paper, but quite the opposite: less paper, but all questions important to the decision-maker understood and clarified. There is hardly a decision-maker’s appointment for which a ten-page (plus backup) is not enough. To the disappointment of most decision-makers, however, there are only a few project managers who can summarise their messages on a maximum of ten pages. And there are even fewer who want to do so. After all, they want to show what they have achieved! Beware of the trap! Recognition and appreciation from the decision-maker is usually not for a lot of good work, but for good results. And for respecting his needs.
- Let them decide
Especially top decision makers like nothing less than to nod off decisions that have already been made. A decision needs options, otherwise it is not a decision. Ideally evaluated options, combined with a proposed decision. What many do not know: Decision makers don’t just want to make big decisions, they want to make small decisions. Concrete example: the project manager considers a detailed agenda for the appointment. What does the decision-maker do first? He overturns the agenda. What is that supposed to do?! Quite simply, the decision-maker wants to decide, and when a detailed agenda is available, the decision on how to proceed with the appointment is taken out of his hands. He resists this. What to do? Very simple: present the agenda – like everything else – as a proposal on which one can decide.
- Get to the point
Impatience is literally written all over the faces of many decision-makers. Then it likes to say “Move forward” or “Get to the point”. Unfortunately, we learn exactly the opposite in school and training, in seminar papers and theses. The procedure must describe what we did, and who we talked to, what analyses we carried out and what came out of it. And finally, at the very end: what we recommend on this basis. None of this is wrong, just unfortunately in the wrong order. Getting to the point means: arguments and documents are structured pyramidally. And that means: the core message comes right at the beginning. Only then do the reasons follow, the details, and the details to the details. This has the advantage that the decision-maker can decide how far into the details it should go. And this is in line with his time budget on the one hand and his need to decide on the other. Voilà!
Whether you actually get the decisions you need for your projects and your work, on time and binding, is something you can influence. The first big step is the needs of the decision maker. If you include the needs, the role and the life reality of the decision maker in your considerations, you will receive the decisions you need much more often. And this with a very manageable amount of effort.
Georg Jocham has published another post in the t2informatik Blog:
Georg Jocham is an author, management trainer and university lecturer at the Vienna University of Economics and Business Administration.
After several years in strategy consulting (Roland Berger), he worked in various management roles in the corporate environment before becoming a freelance trainer. His focus is on executive communication ("How do I get management to make the decisions I need for my work?").
He completed his training at the University of Innsbruck, the Universitá La Sapienza in Rome and the Vienna University of Technology. With his podcast "Abenteuer Problemlösen" (Adventure Problem Solving) he has already topped the iTunes charts several times and reaches tens of thousands of listeners every month. In 2019 his book Schneller Entscheidungen bekommen – Die besten Strategien und effektivsten Methoden“ (Getting faster decisions - The best strategies and most effective methods) was published by Redline / Munich publishing group.