in Agilität, Anforderungsanalyse, Leadership/Führung, Standards, Teamarbeit

Die Suche nach dem idealen Projektmanager führt in eine Sackgasse

Die Professionalisierung des Projektmanagements brachte es mit sich, dass es die Profession des Projektmanagers gibt. Große Unternehmen haben einen Pool an Projektmanagern (oft in einem PMO zusammengefasst), die in unterschiedlichen Projekten zum Einsatz kommen. Meist wird das verbunden mit einer Standardisierung, im DACH-Raum ist das sehr oft IPMA, international dominiert PMI, in einigen Regionen ist es PRINCE2. Es ist klar, dass solche Standards nicht auf die Spezifika bestimmter Branchen oder Projekttypen eingehen können, sie haben den Anspruch, für alle Arten von Projekten zu gelten. Solange es um die Vereinheitlichung von Begriffen, um Checklisten für die Vollständigkeit von Projektplänen, Beispiele für Best Practices  etc. geht, ist das eine sinnvolle und wertvolle Aktivität. Allerdings besteht die Gefahr, dass man diese Normierung für ausreichend hält, um sich als Projektmanager zu qualifizieren. Ich sehe in diesen Standards etwas, das in der Medizin mit den Kenntnissen der Anatomie und der medizinischen Fachterminologie zu vergleichen ist. In der Medizin ist wohl jedem klar, dass die perfekte Kenntnis des Pschyrembel nicht reicht, um ein guter Arzt zu sein.

Allrounder sind keine gute Wahl

Immer wieder hatte ich die Gelegenheit, mit Universal-Projektmanagern zusammenzuarbeiten. Die Erfahrungen waren unterschiedlich, je nachdem, in welchem Gesamtkontext das war. Es gibt in größeren Projekten genügend Arbeit für Projektmanagement im Sinne von Projektadministration und je qualifizierter diese Projektmanager sind, umso besser. Das funktioniert gut, wenn eine am konkreten Inhalt des Projektes orientierte Expertise im Projekt ausreichend vorhanden und diese mit einer ausreichend starken Position im Projekt vertreten ist.

Das führt wieder zum Grund meiner Vorbehalte gegen den kompetenzorientierten Standard der IPMA, wenn nämlich die Erwartung genährt wird, ein Projektmanager sei tendenziell erfolgreicher, wenn er in allen relevanten Kompetenzbereichen stark ist. Selbst wenn man so einen Wunderwuzzi zur Verfügung hat, ist das kein Vorteil: Es verführt dazu, zu wenig in eine leistungsfähige Teamstruktur zu investieren. Wenn dieses Universalgenie dann einmal ausfällt oder das Projekt einfach zu groß ist, um von einer dominanten Person gemanagt zu werden, ist die Krise umso stärker. Richtig ist, dass in einem Projekt alle erforderlichen Skills vorhanden sein müssen, um es zum Erfolg zu führen. Wie sich diese Skills aber auf die beteiligten Personen verteilen, ist je nach Situation gestaltbar. Insofern ist auch die Regel, man möge Organisationen nicht rund um Personen gestalten, zu relativieren. In einem Projekt mit gegebenem Terminrahmen muss man sich nach der Decke strecken und kann nicht darauf warten, die idealen Personen zu einer idealen Projektorganisation zu finden.

Alles ist möglich, nichts ist fix? So schlimm ist es auch wieder nicht. Es gibt meiner Meinung nach zwei geeignete Ansätze, mit diesen Herausforderungen umzugehen.

Projektmanagement ist Teamwork und braucht keine Universalgenies

Der eine führt über die Definition der Prozesse, die in einem Projekt zu exekutieren sind. Diesen Weg geht PMI mit insgesamt 47 Prozessen, die Projektmanagement ausmachen. PRINCE2 nennt 7 Prozesse, die in zwei oder mehr Phasen jeweils zu exekutieren sind. Die ISO 21500 folgt auch dem Prozessansatz und beschreibt 39 Prozesse, die weitgehend denen von PMI entsprechen. Die Unterschiede zwischen diesen Ansätzen bestehen letztlich in einer unterschiedlichen Granularität der Prozessbetrachtung, ansonsten sind die Unterschiede nicht so gravierend, dass man einen Glaubenskrieg führen könnte. Zu den Skills, die Projektmanager haben können bietet übrigens PMI auch einen Leitfaden an, der diese Kompetenzanforderungen sinnvollerweise aus den Prozessen ableitet: welche Skills braucht man, um die jeweiligen Geschäftsprozesse erfolgreich zu exekutieren. Durch wieviele Rollen und Personen man diese Skills abdeckt, bleibt dem spezifischen Projekt überlassen, was auch nur so sinnvoll ist.

Der zweite  Ansatz, der speziell auf das Management von IT-Projekten zielt, kommt vom Agile Business Consortium, das den Schwerpunkt auf ein Rollenmodell legt. Wie in Rollenmodellen üblich, muss nicht jede Rolle von einer Person besetzt sein, es kann eine Person mehrere Rollen abdecken oder eine Rolle mit mehreren Personen besetzt sein.

Das Set an Rollen muss passen

Die Rollen des Auftraggebers („Business Sponsor“) und des Projektmanagers müssen wir hier nicht gesondert beschreiben, diese sind allgemein bekannt und üblich. Interessant ist allerdings, dass es auf oberster Ebene die Rollen „Business Visionary“, „Technical Coordinator“ und „Business Analyst“ gibt. Damit wird die enorme Bedeutung des Projektinhaltes für den Projekterfolg deutlich gemacht und adäquat in der Projektorganisation abgebildet.

Business Visionary ist meist eine Person, die im Projekt stärker eingebunden ist als der Auftraggeber und dafür verantwortlich ist, die inhaltliche Ausrichtung des Projektes in allen Phasen zu steuern. Es handelt sich dabei um Vorgaben und Entscheidungen, die den Nutzenbeitrag des Projektes für den Auftraggeber sicherstellen.

Ich kenne eine dem Business Visionary entsprechende Rolle in den anderen Projektmanagement-Standards nicht; natürlich ist der Product Owner im Scrum in Teilen damit vergleichbar, aber die visionäre und  innovative Ausrichtung bleibt dort doch der Interpretation der Rolle durch den jeweiligen Product Owner überlassen. Kritisch merke ich an, dass im Scrum der Product Owner vor allem der Entlastung des Teams dient, er liefert Input, er priorisiert und das Team (eine im Scrum sehr technisch ausgerichtete Gruppe) muss sich um diese bei jedem Entwickler zutiefst unbeliebten Themen nicht kümmern. Im Scrum ist ja generell das Business eher out of scope, nur der Product Owner vertritt diese Stakeholder.

Der Technical Coordinator erfüllt aus technischer Sicht die gleiche Funktion wie der Business Visionary aus unternehmerischem Blickwinkel. Er sichert die Übereinstimmung der Projektergebnisse mit der IT-Unternehmensarchitektur bzw. stimmt die Projektentscheidungen mit übergeordneten technischen Vorgaben und Rahmenbedingungen ab. Bleibt also im Scrum und auch im Extreme Programming (XP) die Frage der Architektur immer im Dunkeln, wird diese in diesem Rollenmodell auf höchster Ebene verankert.

Im Rahmen des Solution Development Teams gibt es zusätzlich noch die Support-Funktionen Business Advisor bzw. des Technical Advisor, die das operative Pendant und erste Ansprechpartner des Business Visionary bzw. des Technical Coordinator sind. Im Team selbst nehmen eine oder mehrere Personen die Rolle des Business Ambassador ein, um die Details zu allen Fragen der Geschäftsanforderungen zu klären; damit wird eine der Stärken des XP übernommen, allerdings in einen deutlich stärker strukturierten Ansatz integriert.

Last, but not least muss die Rolle „Business Analyst“ hervorgehoben werden. Dieser ist das Bindeglied zwischen der Auftraggeberseite (wird hier „Projektebene“ genannt) und dem „Solution Development Team“ (das ist die Umsetzungsinstanz, die üblicherweise als Projektteam bezeichnet wird). Das Rollenprofil „Business Analyst“ integriert Aspekte des Product Owners im Scrum mit der traditionellen Rolle des Requirement Engineers. Entscheidend ist allerdings das damit verbundene Rollenverständnis; hier unterscheidet sich das Modell des Agile Business Consortiums von anderen Ansätzen deutlich. Der Business-Analyst agiert als Bindeglied zwischen Business und IT, allerdings nicht als Empfänger und Überbringer von Informationen und auch nicht als Übersetzer, sondern als „Facilitator„, der dafür sorgt, dass die Kommunikation zwischen den beteiligten Personen funktioniert und immer an den übergeordneten Zielen des Projektes ausgerichtet bleibt.

Insgesamt hat für mich das Modell des Agile Business Consortiums den großen Vorteil, dass die Stärken des „traditionellen“ Projektmanagements und die der agilen Vorgehensmodelle in einer idealen Weise integriert werden. Man kann große Projekte nicht mit selbstgesteuerten Teams abwickeln und man kann Innovation nicht in einer Kommandostruktur realisieren. Und man muss für jedes Projekt die bestmögliche Verteilung von Rollen auf die verfügbaren Personen finden und im Verlauf eines Projektes auch immer wieder anpassen. That’s life!

Noch eine Anmerkung: Alle Rollen stehen Männern und Frauen offen, angesichts der vielen Rollen, die hier genannt werden, habe ich aus Platzgründen auf die Geschlechtsneutralität der Bezeichnungen verzichtet.

 

Schreibe einen Kommentar

Kommentar