Sandra Luttenberger ist seit 2016 Beraterin und Trainerin bei Coverdale Deutschland. Davor hat sie neben eigenen Projekten im Marketing gut 1.500 IT-ler schwerpunktmäßig in der Projektmanagement-Methode PRINCE2® ausgebildet und zertifiziert. Zudem beriet und coachte sie Kunden bei der Einführung von Projekt- und Programmmanagement-Prozessen.

Die Berlinerin wohnt seit 12 Jahren in Frankfurt am Main. Der perfekte Ausgangspunkt, um für den Job deutschlandweit unterwegs zu sein. Auch privat reist sie gerne und ist in den Städten dieser Welt genauso anzutreffen wie in den Bergen.

 

Was sind in deinen Augen die gröSSte Herausforderung in der Projektzusammenarbeit?

Die Menschen. Für ein Projekt kommt in der Regel eine Gruppe von Menschen neu zusammen und soll innerhalb kurzer Zeit gemeinsam ein Ziel erreichen. Da gibt es eine Menge zu tun. Und damit meine ich nicht die inhaltliche Arbeit. Ich meine den anderen, in meiner Erfahrung viel wichtigeren Teil, der, in dem die Rollen definiert, das Ziel geklärt, sich kennengelernt, Feedback gegeben und genommen wird. Die Beziehungsarbeit wird selten in Projektplänen berücksichtigt. So ein Teamformungs-Prozess braucht erfahrungsgemäß Zeit und in dieser Zeit kann das Team – selbst wenn der Projektmanager „alles richtig macht“ – (noch) nicht die komplette Energie in die inhaltlichen Ergebnisse stecken.


Was ist dein Verständnis von der Rolle eines Projektmanagers im Unterschied zu einer Führungskraft?

Fangen wir mal bei den Gemeinsamkeiten an: Beide führen. Der Unterschied ist, dass die Führung im Projektmanagement auf Zeit angelegt ist und der Projektmanager keine disziplinarische Verantwortung trägt.
Die größte Diskussion entzündet sich immer an der Frage, inwieweit ich als Projektmanager fachliches Know-how benötige. Aus methodischer Sicht gibt es da eine ganz klare Antwort: Der Projektmanager managt das Projekt. Die Fachexperten erstellen die Produkte. Wenn der Projektmanager inhaltlich mitarbeitet, dann wechselt er seine Rolle und ist für dieses Arbeitspaket ein Teammanager oder Teammitglied. Das ist übrigens bei Scrum genauso. Der Scrum Master arbeitet nicht inhaltlich, sondern sorgt dafür, dass das Team arbeitsfähig ist und bleibt. Die Tendenz – ich sage es mal bewusst flapsig – sich inhaltlich reinzuhängen, ist umso gefährlicher, je komplexer ein Projekt wird. Aus meiner Sicht entsteht diese Diskussion, weil lange Zeit die besten Fachleute über Nacht zum Projektmanager ernannt wurden.
Eine ähnliche Entwicklung sehe ich bei Führungskräften. Ihre Rolle verändert sich gerade massiv durch die agilen Transformations-Prozesse. Wenn ich Verantwortung an ein sich selbst organisierendes Team abgebe und als Coach agiere, verschiebt sich meine Aufgabe als Führungskraft dahin, die Rahmenbedingungen und Leitplanken für das Team bereitzustellen. Die allwissende Führungskraft ist immer weniger gefragt.


Kannst du ein grobes Bild umreiSSen, was unter agilen Projektmanagement zu verstehen ist?

Für mich ist das eine Risikominimierungs-Maßnahme. Bei vielen IT-Projekten in der Vergangenheit haben technische Experten Zeit, Energie und Geld in die Entwicklung von Produkten investiert, die – wenn sie dann endlich perfekt waren – in der gelieferten Form vom Kunden nicht (mehr) gebraucht wurden. Unter anderem auch, weil während der Entwicklung möglichst wenig mit dem Kunden gesprochen wurde, damit dieser mit seinen Wünschen das Projekt nicht verzögert.
Agiles Projektmanagement erfordert eine ganz andere Haltung und Herangehensweise. Hier werden ausgehend vom Kundennutzen in kurzen iterativen Schleifen schnell einsatzfähige Produkte gebaut und dann gemeinsam mit dem Kunden weiterentwickelt.
Interessanterweise sind Methoden wie PRINCE2® im Herzen sehr agil. Die Steuerung über anpassbare Managementphasen, den Kunden in die Entwicklung und Abnahme der Produkte einbeziehen, den Fokus auf den Nutzen und die Produkterstellung richten und nicht zu vergessen: „aus Erfahrung lernen“. Alles da. Man muss es ‘nur‘ machen.


Wie können Unternehmen das für sich geschickt anwenden? Was braucht es dafür?

Zwei Dinge. Zum einen braucht es die Bereitschaft, wirklich etwas zu verändern. Ich habe es leider zu häufig erlebt, dass halbherzig Tools angeschafft und Mitarbeiter zu Schulungen geschickt werden. Nach dem Motto: „Der Rest wird dann schon von allein passieren.“ Jeder IT-ler lernt schnell: „A fool with a tool is still a fool.“ Der Ruf nach Werkzeugen und Methoden ist nachvollziehbar, bringt aber keinen nachhaltigen Effekt.
Deshalb braucht es in erster Linie ein agiles Mindset, die Haltung. Methoden können unterstützen. Der Fokus muss jedoch auf den Menschen und ihrer Kommunikation miteinander liegen. Dabei leisten agile Ansätze einen großen Beitrag. Die erste Forderung im Manifest für Agile Softwareentwicklung lautet: „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“. Das ist aus meiner Sicht der größte Hebel.


Wie gut lassen sich die Methoden aus der IT-Welt in anderen Bereichen anwenden?

Woran scheitern Projekte? Ich habe 1.500 Projektmanager gefragt und die häufigste Antwort war: Kommunikation. Wenn Menschen gemeinsam arbeiten, egal ob klassisch oder agil, ergeben sich immer die gleichen Fragen: Was braucht jeder für die Zusammenarbeit? Was ist, wenn jemand einen Fehler macht? Wie geben wir Feedback? Wie gehen wir mit Ideen um? Wie stellen wir sicher, dass jeder im Team gehört wird? Was ist eine faire Verteilung?
Das war für mich der Grund, den Fokus meiner Arbeit zu verschieben. Methoden sind sehr hilfreiche und logische Werkzeuge. Das Problem entsteht erst, wenn sie auf Menschen treffen. Wie mit jedem Werkzeug, nehmen wir mal als Beispiel einen Hammer, kann ich je nach Kompetenz entweder ganz wunderbar einen Nagel in die Wand oder mir ganz furchtbar auf den Daumen hauen. An sich können die Methoden auf viele Bereiche übertragen werden, wenn den Beteiligten klar ist, zu welchem Problem sie die Lösung sind. Also die Ur-Coverdale-Frage nach dem „Wozu“.


Ist das Glas für einen guten Projektmanager halb voll oder halb leer?

Haha. Für einen Projektmanager ist das Glas doppelt so groß, wie es sein müsste.