The King's Discpline

Mr Hinz, large-scale public projects such as the new Berlin airport simply harbour a "logic of failure". What do you mean by that?

One thing is still expected of large-scale public projects: that the cost and schedule will be exactly as it was submitted at the time of the tender. The logic of public tendering procedures dates back to the last century, i.e. to a time when it was mainly predictable, technically standardised projects that were awarded with budgetary funds - in other words, a cameralistic planned economy.

And with this "planned economy" you can't get any greener today?

At a time when complexity is increasing, there is no need for planned processes of bureaucracy. It is a truism that in public sector projects in particular there is a congenial "mismatch" when tendering law, politically motivated low prices and the skilful "supplementary management" of the companies carrying out the work come together. Here the behaviour of client and contractor complement each other wonderfully in one direction: It takes longer and becomes more expensive than published at the beginning. Because the necessary buffers for uncertainty were just not allowed to be!

What are the alternatives for effective public project management?

As long as project managers do not understand that plans are only a ruler against which reality can be measured, and secondly believe that central project data can be calculated objectively, the planned economy will produce its well-known mediocre results. I call for a completely new attitude: realistic buffers, the real possibility of project termination, and a procurement law that makes continuous renegotiation possible in parallel with project progress would be cornerstones of this modern version of public project management.

"Leadership under uncertainty" is part of the requirement profile of a project manager, you say. To do this today, he must master software tools and methods ...

You might get that impression if you look at all the things that come under the heading of project management. There is a lot of fraudulent labeling at work: bold promises, certified standards and lots of tools and methods. One thing is clear: every project captain who wants to be successful must know and master the methodological basics. A filled toolbox is the necessary condition of good project management.

And where does your criticism come in?

With a blue-eyed and mechanistic application. Only those who also take the step towards real leadership and not just the administration of projects also fulfil the sufficient condition to be a successful project leader. The mastery of instruments and tools must be complemented by the inner attitude of a project captain - by effectively dealing with conflicts, demotivation, changes in plans and team dynamics. It is about the factors that enable effective leadership and effective decision-making under uncertainty.

The title of your book is "The Project Captain". And what can a project manager learn from a captain on the high seas?

Successful project managers go out into the organization with seamanlike composure. Alert and ready to cooperate, they form coalitions, juggle different interests and take care of the progress of the project. As the man on the bridge, a project captain benefits from his wealth of experience and methods. He knows that he will solve emerging problems from the situation itself and cannot regulate them in advance; therefore, an experienced seafarer will never talk his crew into an approaching storm, but will also not immediately order all hands on deck and distribute life jackets as a precaution. Rather, he reckons with both bad and good weather and has already checked the position and functionality of the life jackets in advance.

So the term "seamanly composure" describes a special inner attitude?

Exactly, it is a matter of acknowledging that things can go differently than planned and that reality is not linear but highly complex. It is about saying goodbye to "if-then" thinking. The old categories of "right" and "wrong" are replaced by "appropriate" and "useless". For a project manager, this means always thinking in terms of alternatives and understanding plans as a possible path that can be adapted and changed at any time - and also representing this to the project staff!

It sounds like you can just let a project run ....

On the contrary, a nautically calm project captain acts wide awake, concentrated, well prepared and using all his experience and methodological knowledge of project management - but always as a human being and not as a functionary of some management school.

In what way as a "person"?

Those who use their professional common sense to include project surprises from the outset, instead of trying to calculate them away through methods, remove any horror of them and ensure that the project processes continue to be useful. In the end, that's what the project manager is paid to do. Because working off plans could also be done by a machine!

Communication must be right in every project. Endless team meetings, however, tend to be seen as a waste of time. What needs to change?

Unfortunately, unproductive team meetings are the norm rather than the exception. After the second or third meeting, the last-minute cancellations increase, the group in session becomes smaller and smaller - until in the end the meetings are cancelled due to lack of mass. At the same time, the flood of e-mails that team members send each other swells. An email forwarded ten times becomes the rule.

For a project manager who values effective team meetings, I recommend the following six rules:

1. Every meeting needs to be prepared.

2. The course of the meeting is determined and announced in advance.

3. Only those who need to be involved are invited.

4. Nothing is decided without the people involved.

5. The agenda item "Other" does not exist.

6. There are only result protocols.

And which of these rules is particularly important?

Take point 3: Ideally, you organize the meeting so that individual team members can come to the agenda items that concern them and then leave right away. Of course, there are also items that concern the entire team. For example, when general strategic issues are being discussed, everyone should be involved - as well as at milestones, where decisions are almost always made that affect everyone involved.

Isn't there a danger that team members will feel excluded?

You can also let the team members decide for themselves which agenda items they want to participate in. After all, it is all about the effective handling of the scarce resource time. If you clearly communicate this connection to your team members, the rule will quickly find acceptance and you will be perceived as an effective manager.

"All hands on deck" - everyone is needed on the ship and in the project. What can the project manager do to ensure that no one who matters simply "jumps ship"?

For the project manager in his role as a non-hierarchical leader, one thing in particular is promising: intrinsic employee motivation. Here, it is not a matter of influencing the project team from the outside, but of using the basic motivation of the employees that is already "brought along". This success pattern is based on the insight that people are already motivated by themselves for a certain action. In other words: people are motivated, they don't have to be made to do it first!

So it's a matter of recognizing people as they are?

The effect of intrinsic motivation on performance is not only clearer, but also more stable and lasting. For the project manager who wants to take advantage of this opportunity, this has one consequence above all: he must find out what an employee's intrinsic motivation is and then assign him the task that matches it. Experiencing meaning is a strong intrinsic motivator for a project employee - that's my conclusion. There are two main aspects that matter here: Meaning cannot be prescribed or even decreed by others, and meaningful action arises from an individual's efforts to realize certain personally important values.

And how can it be avoided that he receives the wrong task package?

So that there is no misunderstanding: Meaning-based motivation is not about an employee choosing the tasks they enjoy - rather, it is about them experiencing the task they are given as meaningful. There are enough activities that are unloved but still necessary to achieve the goal. Examples of this are technical documentation or the project completion report.

What does this mean for the project manager?

Above all, one thing: don't push service on schedule, but establish a coalition of the willing.

Because motivation comes from meaning and context - and not from day-by-day schedules. Conduct regular dialogues with each team member instead of just ticking off the items on the "employee appraisal" sheet, asking lots of questions and listening carefully. In this way, you will be able to detect the employee's individual motivators and demotivators and determine which cog in the overall gearbox is the right one for him or her.

So open communication is crucial?

Yes, when you call the team together for the team meeting, it is essentially about giving them meaning and context: What is the significance of the (new) task? And what role do the individual team members play in it? Everyone should recognize which cog they are turning - and how their cog interacts with all the others to make the whole thing make sense. The team is on board when everyone knows their function and the connections.

In every project, internal team development is the be-all and end-all of successful work. What does the project manager have to pay particular attention to?

Leading your project team well means above all: a good, seamanlike, relaxed attitude to the subject of group dynamics. Because this is like the weather - always there. So you have to come to terms with it or, better yet, even use it for the project goal. Realize that you are dealing with three core dynamics: Projects irritate the organization, project work is networking, and all project participants have to deal with uncertainty all the time. As a project manager, you should accept these three phenomena, deal with them calmly - and use the resulting dynamics instead of fighting against them.

And how can he use this "dynamic"?

In order to deal with group dynamics and successfully steer the project ship through difficult waters, it is useful to pay attention to different types and team roles. Only their good interaction enables a joint team performance that is more than the sum of the results of the individuals - and thus makes project success possible.

But doesn't every team have to live with conflict?

When conflicts and friction arise, it is important not only to pull together, but to use contradictions in a targeted way. Effective project teams work on their tolerance of ambiguity by consciously introducing differences into their work process. In this way, they protect themselves from simple truths, slick solutions to problems, and rash consensus. A high tolerance of ambiguity opens the view to alternatives that have not yet been discovered and to ideas for solutions that were previously dismissed as impossible. In this way, different interests can be discovered and used in the project process.

So resistors don't have to be negative?

It is quite normal if frictions show up in the course of getting the project team together. Rather, you should be suspicious if there is no resistance on your way from the project idea to its realization. It is not the occurrence of resistance but its absence that is cause for concern - because resistance shows that something essential is at stake and that the company is interested in it. If resistance is absent, you have to fear that your project is unimportant - or that no one believes in its realization from the outset.

Projects usually run differently than planned. How should a project manager deal with the "unexpected"?

Effective action under uncertainty is better achieved by those project captains who constantly work with vigilant introspection in order to recognize individual patterns. Reacting to unplanned events, working out a suitable solution for each new situation - this requires mental agility. Effective leaders therefore question their patterns of action at regular intervals. For example: What behavior patterns do I repeatedly recall in situations where I am dealing with the unexpected? What steps do I take when I am partially or completely unable to assess a situation? Or what events do I always pigeonhole? Leading in spite of the unexpected is not a question of knowledge, but a question of attitude and ability. And this can be practiced and trained in practice.

Mr. Hinz, how do you explain the adherence to rigid plans and thought patterns, even when a project is on the verge of chaos?

This is certainly due to the promise of salvation of the project management methodology: activities and work steps are entered into the software, milestones are determined and deadlines are assigned. The end result is an overall schedule that can easily be used to wallpaper the walls of the office. Once these schedules are up and running, they create stability and the impression of a controllable process. It is then difficult to escape the fascination of the traditional mechanistic understanding.

Because it gives you the security you need?

This model of thinking is widespread in project management. It is expressed in process methods and tools that are structured according to the if-then principle. A project manager who thinks in linear categories identifies problems and fields of action and then applies a suitable tool that has been proven in the past. Then he follows the given procedure path and assumes that in the end the predicted result will come out of this "machine".

Which leads to the fallacy that you have everything under control ...

The difficulties start when the expected results fail to materialise. This is to be expected, because the if-then relationships in reality are by no means always found in the way they were assumed. Project managers and project teams are then confronted with unexpected situations that they can neither explain nor manage with linear thought patterns. Uncertainty and operational hecticness are often the result because project participants do not know how to react properly. This is the problem of mechanistic understanding, in which people, their interests and the unexpected have little place. The fact that projects are run by people in organisations, i.e. that behaviour, attitudes and group dynamics are also part of fulfilling the project requirements, is unfortunately almost ignored.

Projects are networked with other projects in the company, i.e. in a complex environment. How does the project manager manage to make the "right" decisions in this situation?

Quite simply (laughs): by no longer subjecting himself to the right-wrong requirement! Because leading means deciding the undecidable. This is the apparent paradox that we owe to Heinz von Förster. Because the decidable is already decided, already regulated in the form of job descriptions, "razor-sharp" interface papers, instructions, rules of the game and agreements. Therefore, a project manager who wants to be effective turns to the issues that are not already subject to a rule, he turns to the undecidable decisions. Their occurrence makes it clear that a limit of complexity is exceeded, beyond which the behavior and progress of a project can no longer be precisely calculated and planned, but only predicted and situationally controlled.

You like to talk about project management as "the supreme discipline of leadership". What special requirements do you mean by that?

Leading projects successfully is above all: management on the edge of chaos! It is in the nature of a project that goals change in the process, that members change the team, that deadlines are overturned or that the market makes new demands. Unpredictability is one of the core characteristics of a project.

Of course, a successful project manager should master the basic craft and be able to plan, document and visualize the project process using the usual procedural methods and tools. Beyond that, however, there is something else that is important in the management, communication and staging of the project: an attitude that meets the project-immanent uncertainty awake, focused and - as already mentioned - with seamanlike composure.

What else distinguishes effective project captains?

They can ask open questions and listen actively, they are masters of process management, the control of group dynamics and the lateral leadership of temporary teams. The successful project captain differs from his colleague who relies solely on the power of tools and methods in two main ways: He works with descriptions instead of assuming an "objective truth". And he thinks in alternatives instead of looking for unambiguous solutions. Dealing with these levels of demands with confidence is the big challenge. This is precisely the reason why I like to talk about the supreme discipline of leadership when it comes to managing projects.