Wozu eigentlich noch Projektleiter? Wenn der Projektleiter sich im agilen Projekt als Auslaufmodell fühlt

Agile Methoden wie Scrum sehen die Rolle des Projektleiters nicht mehr vor. Bei der Einführung agiler Methoden stellt sich daher die Frage, welche Aufgaben die bisherigen Projektleiter in der neuen Projektwelt übernehmen sollen. Optimalerweise verschaffen sich diese frühzeitig selbst Klarheit, wie sie ihre veränderte Rolle ausfüllen wollen.

Wozu eigentlich noch Projektleiter? Wenn der Projektleiter sich im agilen Projekt als Auslaufmodell fühlt

Agile Methoden wie Scrum sehen die Rolle des Projektleiters nicht mehr vor. Bei der Einführung agiler Methoden stellt sich daher die Frage, welche Aufgaben die bisherigen Projektleiter in der neuen Projektwelt übernehmen sollen. Optimalerweise verschaffen sich diese frühzeitig selbst Klarheit, wie sie ihre veränderte Rolle ausfüllen wollen.

Karin T. arbeitet seit nunmehr 15 Jahren als "klassische" Projektleiterin in der IT-Branche. Nun übernimmt sie die Verantwortung für ein Software-Entwicklungsprojekt, in dem nach Scrum gearbeitet werden soll. Schnell gerät die erfahrene Projektleiterin an ihre Grenzen.

Ihr bisheriger Führungsstil, der auf klare Ansagen ausgerichtet ist, will in dem agilen Projekt einfach nicht funktionieren. Ganz im Gegenteil: Mit ihrer Art eckt sie im Team immer wieder an. Ihre Mitarbeiter fordern Freiräume – und keine Chefin, die kontrolliert und ihnen Vorschriften macht.

Gerade in IT-Projekten sind klassische Projektleiter meistens diejenigen, die über ein breites fachliches Verständnis und ein umfangreiches Projekt-Know-how verfügen. Diese Rolle übernimmt in Scrum der Product Owner – dem Projektleiter bleibt oft nur, auf die Rolle des Scrum Masters auszuweichen.

Von dem wird ein ganz anderes Führungsverständnis verlangt: Ein Scrum Master ist gegenüber seinem Team eine dienende Führungskraft. Wer diesen Rollenwechsel nicht beherzigt und stattdessen weiterhin munter Anweisungen gibt, setzt schnell die agile Performance des ganzen Projektteams aufs Spiel.

Agile Projekte leben von Mitarbeitern, die Freude daran haben, kreativ und innovativ zu arbeiten. Mit Druck lässt sich das kaum erreichen. Die Folge: In agilen Projekten steht für viele Projektleiter das alte Selbstverständnis von Projektleitung zur Disposition.

"Bin ich jetzt überflüssig?"

Seit gut 15 Jahren setzen agile Methoden ihren Siegeszug im Projektmanagement fort – gerade in der Software-Entwicklung gibt es nachweislich Erfolge. Die Ideen der agilen Methoden, wie beispielsweise Scrum, werden zunehmend auch auf technische Entwicklungsprojekte oder auf Organisations- und Veränderungsprojekte übertragen. Auch hier mit Erfolg. Allerdings sucht man in den Beschreibungen der agilen Vorgehensmodelle vergeblich die Rolle des Projektmanagers. Heißt das, agile Projekte brauchen kein Projektmanagement?

"Bin ich jetzt überflüssig?", fragen sich viele Projektleiter, die sich wie Katrin T. erstmals mit einem Scrum-Projekt konfrontiert sehen. Um die Antwort vorwegzunehmen: Nein, überflüssig wird der Projektleiter nicht. Aber seine Rolle verändert sich.

Der "klassische" Projektleiter gibt im agilen Projekt viele seiner Aufgabenbereiche ab
Bild 1: Der "klassische" Projektleiter gibt im agilen Projekt viele seiner Aufgabenbereiche ab

Von Moderatoren und Möglichmachern

Karin T. begreift schnell, dass ihr fordernder Führungsstil als agile Projektleiterin überholt ist. Sie muss stattdessen moderieren und koordinieren, Impulse setzen, einen Teamprozess in Gang bringen – und dann die Sache laufen lassen.

Auch wenn es ihr zunächst schwerfällt: In agilen Projekten verbleiben Verantwortung und Monitoring im Team. Agile Projektleiter führen, indem sie passende Rahmenbedingungen schaffen, das Arbeitsgeschehen im Projektteam moderieren und Vorschläge zur Verbesserung machen.

Projektleitung auf den Kopf gestellt

Karin T. muss also radikal umdenken. Agiles Projektmanagement verlangt von ihr eine andere Haltung: Das klassische Führungsmodell wird auf den Kopf gestellt, hierarchische Führung dank Macht wird durch dienende Führung dank Vorbild ersetzt. Projektleiter wie Karin T., die sich viele Jahre über Vorgabe und Kontrolle, feste PM-Methoden und -Prozesse sowie ihre fachliche Autorität definiert haben, stehen vor der Herausforderung, Projektleitung neu denken zu müssen.

Projektleiter in agilen Projekten sind in erster Linie dafür verantwortlich, für das Projektteam gute Rahmenbedingungen und die nötige Infrastruktur zu schaffen. Die fachliche Verantwortung wird dorthin verlagert, wo die Entscheidungen am besten und am schnellsten getroffen werden können: in das Projektteam. Dort wird ohne Angst vor Fehlern und Konsequenzen Neues ausprobiert; Entscheidungen werden dezentral selbst organisiert und selbstverantwortlich gefällt (siehe den Fachbeitrag "Effizienter entscheiden im Team").

Projektleiter sind kein Auslaufmodell in der agilen Welt!

Keine Sorge: Projektleiter werden nach wie vor auch in agilen Projekten gebraucht. Jedoch in einer anderen Rolle: Ein agiler Projektleiter hat die Aufgabe, das Team zu moderieren, es vor äußeren Störungen zu schützen, Hindernisse aus dem Weg zu räumen und auf die Einhaltung der Spielregeln (z.B. Scrum-Regeln) zu achten.

Er ist nicht länger Anführer, sondern Dienstleister des Teams, sein Moderator und Unterstützer. Er sorgt dafür, dass das Team die Ziele kennt, die Regeln klar sind und das Team ungestört arbeiten kann. Die Devise lautet also: weg vom "Command & Control", hin zur kooperativen Führung.

Der "klassische" Projektleiter …

Der agile Projektleiter …

  • hat einen Projekt- und Aufgabenfokus
  • hat einen Team- und Prozessfokus
  • sorgt für einen klaren Projektauftrag, entwickelt einen Projektplan und steuert das Projekt entlang des Plans
  • schafft die Rahmenbedingungen für ein funktionierendes Miteinander im Team
  • fungiert als Schnittstelle zwischen den Fachbereichen und dem Projektteam
  • unterstützt den Product Owner, übernimmt jedoch keinerlei Abstimmung mit den Fachbereichen
  • ist für die Ergebnisse verantwortlich, die das Team erarbeitet
  • ist für die Produktivität des Projektteams verantwortlich

Tabelle 1: Die Aufgabenprofile für Projektleiter unterscheiden sich je nach Vorgehensmodell – genug zu tun gibt es jedoch immer

Survival-Tipps

  • Werden Sie für Ihr Projektteam zur Identifikationsfigur. Begeistern Sie Ihr Team für die Aufgaben, setzen Sie Impulse, bringen Sie einen Prozess in Gang und lassen Sie die Sache dann laufen.
  • Stecken Sie das Spielfeld für Ihre Projektmitarbeiter ab. Nicht zu groß, aber auch nicht zu klein – abhängig von Aufgabe und Mitarbeiterprofil.
  • Schaffen Sie frühzeitig Orientierung, geben Sie Anforderungen vor und sorgen Sie für einen reibungslosen Projektablauf.
  • Nachdem Sie die Eckpunkte einer Aufgabenstellung besprochen haben und die Leitplanken gesetzt sind, ziehen Sie sich zurück und greifen Sie nur noch im Notfall ein.
  • Bestimmen Sie einige wenige, aber dafür sehr klare Spielregeln. Jedem im Team muss klar sein, welche Verhaltensweisen gewünscht sind und welche nicht.
  • Etablieren Sie eine konstruktive Fehlerkultur und regelmäßige Feedbackschleifen. Sorgen Sie auf diese Weise für zügige Fortschritte im Projekt.

 

Während die Entwicklungsabteilungen in vielen Unternehmen mittlerweile Scrum verwenden, erfolgt die Projektabwicklung im restlichen Unternehmen weiterhin nach einem klassischen Vorgehen. Diese beiden Welten lassen sich mithilfe der Rolle des Agilen Projektleiters vereinen, wie Claus Kolb an einem Praxisbeispiel zeigt ...

 

 

Bewertungen und Kommentare

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
11 Kommentare anzeigen & selbst mitreden!
Gesamt
Bewertungen 16
Kommentare 11

Das könnte Sie auch interessieren

Alle Kommentare (11)

Thomas
Dietinger
Dr.

Ich stimme zu, dass viele agile Vorgehensmodelle sich primär auf die Entwicklung und interne Prozesse konzentrieren und klassische nach außen gerichtete Organisationsaufgaben wie Stake Holder Management, die Einhaltung und das Management wirtschaftlicher Rahmenbedingungen, PM-Marketing etc. außen vor lassen. Es ergibt sich daraus die Frage wo und wie nun diese Aufgaben im neuen Kontext insbesondere in einer klassischen Projektauftraggeber/auftragnehmersituation abgebildet werden. Aus meiner Sicht passen hier die klassischen Aufgaben eines Projektleiters viel besser zu den nach außen und zum Kunden hingerichteten Aufgaben eines Product Owners. Der Product Owner übernimmt schon wie auch ein Projektleiter zuvor die inhaltliche Verantwortung für das Projektergebnis und hält auch den primären Kundenkontakt. Aus meiner Sicht kommen die agilen Vorgehensmodelle in so einer Rollenaufteilung den Zielen des Projektmanagements sogar entgegen, da der Scrum-Master hier den Projektleiter wesentliche interne Aufgaben abnehmen kann und sich die Projektleiter, nun Product Owner, noch stärker auf den Kunden konzentrieren kann und, was wesentlich für den Projekterfolgt ist, noch stärker mit dem Kunden kommunizieren kann und inhaltlicher noch tiefer einsteigen kann. Ein weiterer Vorteil ist, dass eine Transition von eher klassischen zu agilen Zusammenarbeitsmodelle auch auf Kundenseite viel friktionsfreier möglich ist, da alte und neue Muster ähnlicher sind und leichter weiter entwickelt werden können.

Roland
Wanner

Ich bin der gleichen Meinung wie Thomas Dietinger: ... "Aus meiner Sicht passen hier die klassischen Aufgaben eines Projektleiters viel besser zu den nach außen und zum Kunden hingerichteten Aufgaben eines Product Owners."

Oliver
Lehmann

Ich bin mir nicht sicher, was ich von dem Beitrag halten soll.

Ich sehe es als Problem, wenn aus agilen Methoden ein neuer "Best Practice" wird. "Best Practices" sind Projekt-Alchemie, die die fundamentale Einmaligkeit von Projekten ignoriert.

Tatsächlich sind agile Methoden nach Befragungen für ca. 1/3 der Projekte/Projektsituationen geeignet. Bleiben 2/3, wo sie es nicht sind.

Als Projektmanager sollte man daher zuerst prüfen, welchen Anforderungen man in einem besonderen Moment gegenüber steht, und anschließend situativ passende Methoden auswählen und einsetzen.

Noch ein Problem: Immer mehr Projekte werden heute als Kundenprojekte für zahlende Kunden durchgeführt, der Trend ist messbar. Agile Methoden ignorieren diesen Trend jedoch weitgehendst und gehen, wie leider auch der Autor des Artikels, davon aus, dass Projekte interne Aktivitäten sind. Projektgeschäft stellt jedoch andere Anforderungen an Projektmanager - auf beiden Seiten, Kunde und Lieferant - als interne Projekte.

Wer nur einen Hammer hat, um seinen Lebensunterhalt zu verdienen, muss die Welt überzeugen, dass sie genagelt ist. Wer nur über einen Schraubendreher verfügt, muss die Welt glauben machen, sie sei verschraubt.

Hallo Oliver,
Deinen Ausführungen kann ich nur zustimmen!
Auch wenn wir über das Konzept von "Best Practices" schon viel kontrovers diskutiert haben, sind wir uns doch vollkommen einig darüber, dass Alchemie oder gar Ideologie bei der Auswahl von methodischen Ansätzen für ein zu bewältigendes Projekt nichts verloren hat.
Viele Grüße
Georg Angermeier

Hallo Georg,

Danke für Deine Antwort.

Die Realität im Projektmanagement ändert sich gerade fundamental. In der Welt von VUCA ändern sich Anforderungen an Projektmanager zunehmend schneller. Was gestern noch zum Erfolg geführt hat, passt heute schon nicht mehr, und während Projekte in der Vergangenheit vorwiegend cross-functional waren, werden sie zunehmend cross-corporate.

Wir müssen aufpassen, dass wir in unseren Theoriediskussionen nicht den Anschluss an die Realität verlieren, und dass die Praktiker die notwendigen Hilfen an die Hand bekommen, in dieser veränderten Realität ihre Projekte zum Erfolg zu führen.

Grüßle aus der Fasanerie nach Taufkirchen, Oliver

Georg
Angermeier
Dr.

Hallo Herr Neumann,
danke für diese Gegenüberstellung der Rollen von Projektleiter, Scrum Master und Product Owner. Ich kann Ihren Ausführungen allerdings nicht ganz folgen. Das Scrum Team hat ja "lediglich" die Aufgabe, das Produkt in enger Kooperation mit den Stakeholdern (wofür der Product Owner zuständig ist) möglichst effizient (wofür der Scrum Master zuständig ist) herzustellen (wofür das Entwicklungsteam selbst organisiert verantwortlich ist).
Jeder Projektleiter kann nur "Hurra" schreien, wenn das so klappt. Er oder sie hat ja eine ganze Menge andere Dinge zu erledigen, wie z.B. sich darum zu kümmern, dass die anderen Teilprojekte (z.B. Produktionsanlauf, Patent- und Lizenzangelegenheiten, Abnahmen, Marketing u.v.a.m) koordiniert mit der Produktentwicklung laufen. In der Tabelle vermischen Sie meines Erachtens Scrum Team und Projektteam. Wenn Scrum gut funktioniert, muss der Projektleiter sich um das Entwicklungsteam nicht kümmern, das hat mit PO und SM genügend Overhead zur Verfügung.

Stefan
Müller

Ich stimme mit Mario Neumann voll zu. Mich wunder ein bisschen, dass gerade in der IT diese Sicht erst später etabliert hat. Wer sich seit längerem in verschiedenen Projekten in der Industrie (Entwicklung, Produktion, Verkauf, SCM) bewegt ist von dieser Entwicklung nicht überrascht. Bereits vor 20 Jahren war man als "klassischer Projektleiter" weniger innovativ als wenn man sich in den Dienst des Projektes gestellt hat. Wer die Verantwortung nach Aussen trägt hängt im wesentlichen von der Art des Projektes ab, aber meist ist dies nicht die Aufgabe des Projektleiters.

Thilo
Becker

Den PL auf die Entwicklungsmöglichkeit hin zum Scrum-Master einzuengen wäre das Gleichsetzen des PL mit einem Teilprojektleiter eines nach Scrum arbeitende (Teil)-Teams.

In meinem Umfeld gintves im agilen Kontext drei Prospektiven für den PL:

1) Projektleiter arbeiten auf der teamübergreifenden Ebene an der Schnittstelle zwischen Kunden und (mehreren) Teams, die gemeinsam ein großes Vorhaben stemmen. Der PL übersetzt vom der linearen in die iterative Welt, fördert Team-of-Teams-Strukturen udgl.

2+3) Alternativ übernimmt der PL je nach Skill- und Interessenschwerpunkt im Team die Aufgaben als PO oder AM (Team Facilitator/Agile Lead) bereichert um Führungsaufgaben der bisherigen Führungskraft und ist damit kein Scrum Master und kein halber PL.

Wer den Weg in die Richtung AM (Agile Lead/Facilitator Team) einschlägt, merkt schnell, dass Command&Control einerseits unvorteilhaft aber auch Führungslosigkeit im Team kein empfehlenswerter Zustand ist. Die Lösung - und damit unmittelbare Kernaufgabe - ist nun "Empowerment des Teams". Also die Summe an Strategien und Maßnahmen, die den Grad an Autonomie und Selbstbestimmung des Teams erhöhen und das Team mit all seinen Individuen und Interessen eigenmächtig, selbstverantwortlich und selbstbestimmt operieren lässt. Bei uns häufig auch als Förderung der Selbstorganisation des Teams bezeichnet. Selbstorganisation des Individuums übernimmt das Elternhaus gewöhnlich...

Viele Grüße

Thilo

Alexander
Schley

Hi zusammen,

genau genommen haben wir hier 2 Herausforderungen:
1. wir befinden uns auf einer Website, die vom klassischen Projektmanagement her kommt.
2. Mario Neumann ist seit vielen Jahren ein klassischer Berater für Projekte.
Beide müssen nun "irgendwie" dieses agile "Zeug" berücksichtigen. Wie kann dieses "irgendwie" gelingen? Schwierig, wie man sieht. Etwa die Hälfte der Kommentatoren haben Mühe mit dem Artikel.

Im Einzelnen:
* Im Grunde hat Mario Recht. Der klassische Projektleiter muss sich neu orientieren.
* Er irrt jedoch (mit Einschränkung) über das Wie. Seiner Meinung nach hat es Platz für alle 3: Scrum-Master, Product-Owner und Projektleiter. Das ist falsch. Es benötigt den Projektleiter in der (weiteren) Zukunft nicht mehr.
* Dessen Aufgaben werden stattdessen auf den PO und den SM verteilt. Zum Beispiel wird die Tabelle korrekt, wenn man die Überschrift der 2. Spalte anstelle von "Der agile Projektleiter..." umformuliert in "Der Scrum-Master...". Denn dies sind alles Aufgaben des Scrum-Masters.
* Berücksichtigt man dies nicht, dann sind Konflikte wegen Überschneidungen zwischen den 3 Rollen vorprogrammiert.

Welche Einschränkung meinte ich oben? Auf dem Weg von der Wasserfall-Welt weg kann der PL wertvolle Beiträge liefern, um das agile Produktteam von einer Organisation abzuschirmen, die von einem Projekt noch sehr viel will: bei uns waren das Quality Gates, Quality Points, RFAs (Request for Architecture), PKAs (Projektkreditanträge), etc.
Wenn also das Team agil arbeitet, das Unternehmen aber weitestgehend in der Wasserfall-Welt verharrt, hat der PL die wichtige Aufgabe, sein Team abzuschirmen, sodass sie in Ruhe agile Produktentwicklung betreiben können. Ich selbst habe lange Jahre als PL genau dies gemacht. Wichtig ist herbei, dass er keine der vielfältigen Aufgaben des POs und des SMs übernimmt. Ob das noch interessant ist, muss sich jeder PL selbst stellen. Er ist für viel weniger verantwortlich als vorher. Auf diese Weise könnte er jedoch viel mehr Projekte als vorher betreuen und sich so breiter aufstellen. In die Tiefe dringt er so jedoch nicht mehr.

Hat das Unternehmen die Wasserfall-Welt dann endlich hinter sich gelassen, dann sollte sich der PL entscheiden, ob er lieber PO oder lieber SM machen möchte. Unser Unternehmen ist gerade mitten in der Umstellung auf eine produktorientierte Organisation. Dann gibt es nur noch Produktteams und Serviceteams mit den entsprechenden agilen Rollen.

Zu den Kommentaren von...
...Thomas Dietinger: die von Ihnen erwähnten nach aussen gerichteten Organisationsaufgaben werden vollumfänglich vom PO wahrgenommen. Genau das ist seine Aufgabe. Der PO ist wie der Geschäftsführer einer kleinen GmbH.

...Oliver Lehmann: die von Ihnen erwähnte Aufteilung 1/3 zu 2/3 halte ich für falsch. Alleine schon aus einer Befragung würde ich so etwas nicht schliessen. Aber ich bin mit Ihnen auch der Meinung, dass sich agile Vorgehensmodelle keinesfalls für alle Vorhaben eignen. Ich emfehle hier die Anwendung des Cynefin-Framework, mit dessen Hilfe klar ersichtlich ist, wo agil anzuwenden ist und wo Wasserfall.

Bei den von Ihnen erwähnten Kundenprojekten stimme ich Ihnen zu. Es gibt hierfür Ansätze, wie z.B. der agile Festpreis. Problematisch bleibt diese Konstellation jedoch weiterhin solange, bis sich eine vertrauensvolle Zusammenarbeit zwischen Auftraggeber und Auftragnehmer etabliert hat. Bis es soweit ist, benötigt es ein gewisses Grundvertrauen, dass "dies" schon gut kommen wird. Wir dürfen jedoch nicht vergessen, dass immer noch das PM-Dreieck gilt: man kann nicht Zeit, Kosten *und* Funktionalität/Qualität maximieren. Man kann 2 davon maximieren unter der Vernachlässigung des einen Übriggebliebenen. Oft höre ich beim Vergleich Agile vs. Wasserfall genau dieses Argument. Und es gibt Auftraggeber, die alles 3 maximieren wollen - den Projektabschluss in der kürzest möglichen Zeit zu den geringsten Kosten mit maximalem Funktionsumfang. Das war im Wasserfall falsch und im Agilen ist es immer noch falsch.

...Thilo Becker: der Agile Lead ist eine Rolle, über die wir in unserem Unternehmen bereits oft diskutiert haben, aber letztendlich ohne zur Überzeugung gelangt zu sein, dass es ihn tatsächlich benötigt. Wir kommen mit den klassischen Rollen PO und SM sehr gut voran. Der AM stiftet nur wieder mehr Verwirrung, da es grosse Überschneidungen zum SM gibt. Und: Empowerment des Teams ist eine selbstverständliche Voraussetzung dafür, dass Agile überhaupt funktioniert.

Mario, ich hoffe, ich habe nicht noch mehr Verwirrung gestiftet.
Dein ehemaliger HP-Kollege Alex

Martin
Rohner

Ich finde den Artikel gut als Basis für die Diskussion! Es enthält viele Punkte, welche meiner Meinung nach durchaus gerechtfertigt sind, andere denke ich sind situativ zu beurteilen und können nicht in allen Projekten über denselben Kamm geschert werden. Und dann gibt es noch die hybriden Modelle, welche - zumindest in meinem Umfeld - immer mehr zum Zuge kommen, weil es halt immer noch Komponenten gibt, die nicht rein agil arbeiten können.
Ich denke es ist wichtig zu analysieren, wie die Hauptstakeholder funktionieren und ob die Organisation überhaupt fähig ist, agil zu arbeiten. In den meisten Fällen hat es für mich dazu geführt, dass ich dann eine hybride Organisation eingeführt habe und diese als Projektleiter dann prima führen und kontrollieren konnte, und gleichzeitig doch einige Vorteile aus der agilen Welt mitnehmen konnte.

Stefan
Nanzer

Es ist ein verbreitetes Missverständnis, dass das agile Projektmanagement keinen Projektleiter mehr brauche. Der Grund ist, dass viele agilen Produktentwicklungsmodelle die Rolle nicht vorsehen, was aber nicht automatisch auch heisst, dass auf der Projekt- oder Programmführungsebene, diese Rolle keinen Sinn macht.
Die Praxis hat gezeigt, dass sich bei grösseren, komplexen Vorhaben die Rolle der Projektleitungsperson mit wichtigen Führungsaufgaben weiterhin bewährt. Der Projektleiter ist dann oft Teil des Projektowner-Teams und für die wichtigen übergeordneten Planungs- und Steuerungsarbeiten wie Changemanagement, Stakeholdermanagement etc. zuständig.