Wie viel PM steckt drin, wenn PO draufsteht?

In den letzten Jahrzehnten sind vermehrt agile Methoden dort zum Einsatz gekommen, wo das klassische Projektmanagement längst etabliert war. Da aber Projektmanagement-Methoden eher explizit, und agile Vorgehensweisen wie Scrum bewusst vage definiert sind, ist es nicht verwunderlich, wenn Rollenverständnisse beider Vorgehensweisen verschwimmen und dadurch Missverständnisse entstehen. Hier könnte ein Grund liegen, warum uns die Frage zum Unterschied zwischen PM und PO immer wieder begegnet. Ein weiterer Grund ist wenig bis kein vorhandenes bzw. belastbares Wissen zu agilen Methoden im Allgemeinen und Scrum im Besonderen. Da ist es sehr verständlich, wenn man sich fragt, wer die Aufgaben eines:einer PM im agilen Kontext übernimmt – Product Owner:in klingt sehr naheliegend, da es doch aufgrund der Titelbezeichnung die Person zu sein scheint, die sich maßgeblich um das Produkt kümmert, wofür einige, wenn nicht sogar alle PM-Kompetenzen sehr nützlich sind. Warum also überhaupt einen anderen Begriff nutzen?

Dies versuchen wir im Folgenden aufzuklären.

Diesem Artikel legen wir den Scrum Guide 2020 sowie die Projektmanagementdefinition nach Prince2 zugrunde. Zusätzlich berücksichtigen wir die von uns erlebte Praxis, die natürlich nicht selten von der reinen Theorie abweicht.

Die Definitionen von Projektmanagement und Scrum

Ein Projekt ist „eine für einen befristeten Zeitraum geschaffene Organisation, die den Auftrag hat, mindestens ein Produkt entsprechend einem vereinbarten Business Case zu liefern.“ (PRINCE 2 – Wikipedia)

Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren (Scrum Guide | scrum.org).

Wer sich diese beiden Definitionen im direkten Vergleich anschaut, erkennt den ersten markanten Unterschied, der sich nicht nur auf die Herangehensweisen Projektmanagement versus Scrum, sondern auch auf die beiden Rollen PM und PO beziehen lässt: Wir vergleichen hier eine klar definierte Projektmanagementmethode (mit der sich ein Buch füllen lässt) mit einem Rahmenwerk, welches sich selbst als leichtgewichtig beschreibt (Länge des Scrum Guides: 14 Seiten). Im Gegensatz zum Projektmanagement lässt Scrum viel Raum für Flexibilität, eine der Voraussetzungen schlechthin für agiles Arbeiten. Insbesondere methodisch lässt sich Scrum beliebig ausgestalten. Man kann beispielsweise verschiedene Methoden zur Effizienzmessung der Teamarbeit heranziehen – dies lässt der Scrum Guide bewusst offen, da unterschiedliche Teams mit unterschiedlichen Zielen sehr individuelle Bedarfe haben können. Scrum wird in der Praxis ebenfalls in zeitlich begrenzten Projektsituationen angewendet. Aus der Historie heraus ist Scrum allerdings eine Vorgehensweise für Produktentwicklung, die in der Regel zeitlich unbegrenzt angesetzt wird. Projektmanagement und Produktentwicklung miteinander zu vergleichen, lässt einen direkt an die sprichwörtlichen Äpfel und Birnen denken, die man eigentlich nicht vergleichen kann. Schauen wir dennoch genauer hin.

Die Definitionen der Rollen Projektmanager:in und Product Owner:in

Der:die Projektmanager:in übernimmt den Verantwortungsbereich der Organisation und Kontrolle. Er:sie wählt Mitarbeiter für die Projektarbeit aus und gewährleistet, dass alles ordnungsgemäß und fristgerecht ausgeführt wird. Der:die Projektmanager:in erstellt Projektpläne, welche die Aufgaben des Projektteams beschreiben und Zeitfristen vorgeben (PRINCE2 Methodik | PRINCE2.com).

Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. Wie dies geschieht, kann je nach Organisation, Scrum Team und Individuum sehr unterschiedlich sein. Der:die Product Owner:in ist auch für ein effektives Product‐Backlog‐Management ergebnisverantwortlich (Scrum Guide | scrum.org).

Die Definitionen ermöglichen aufgrund ihrer Knappheit noch keinen direkten Vergleich, lassen jedoch ebenfalls erahnen, dass wir es mit sehr unterschiedlichen Tätigkeiten zutun haben. Wir gehen im Folgenden also weiter ins Detail.

Die Aufgaben von Product Owner:in ind Projektmanager:in

Um einen Vergleich der Aufgaben zu ermöglichen, haben wir die genaueren Zuständigkeitsbeschreibungen der jeweiligen Rollendefinitionen gegenübergestellt und Formulierungen gewählt, die einen Vergleich überhaupt erst ermöglichen. Diesen stellen wir nun im folgenden Schaubild dar.

Wichtig für das Verständnis des Schaubilds ist: Die Themen, die nur links unter der PO-Rolle bzw. rechts unter der PM-Rolle stehen, gehören im Umkehrschluss NICHT zur jeweils anderen Rolle. Wenn man unter den Aufgaben des:der PM also „Aufgaben verteilen“ findet, bedeutet das im Umkehrschluss, dass der:die PO dafür explizit nicht zuständig ist.

Ein weiterer Hinweis soll an dieser Stelle ebenfalls nicht fehlen: Im Gegensatz zur PO-Spalte, ist die PM-Spalte deutlich länger. Dies bedeutet jedoch nicht, dass ein:e PO weniger zutun hat! Vielmehr liegt es darin begründet, dass der:die PM per Definition sehr viel spezifischere Aufgaben hat. Im Scrum Guide wiederum werden dem:der PO bewusst keine expliziten Aufgaben, sondern grob gefasste Verantwortungen zugeteilt. Durch welche genauen Tätigkeiten er:sie diesen entgegen kommt, ist ihm:ihr überlassen.

Bild: Der Schein trügt: Von der Anzahl der gelisteten Aufgaben ist kein Rückschluss auf die Auslastung beider Rollen möglich. Projektmanagement wie auch Product Ownership erfordern Vollzeitbesetzungen.

Erklärung der Gemeinsamkeiten

Wie nun auf einen Blick zu sehen ist, gibt es durchaus einige Zuständigkeiten, die sowohl auf der Aufgabenliste eines:einer PO als auch eines:einer PM stehen. Gleichwohl haben beide Rollen ganz eigene, nicht vergleichbare Themen auf ihren Agenden stehen. Auf diese möchten wir nicht weiter eingehen und verweisen diesbezüglich auf die jeweiligen Definitionen. Konzentrieren wir uns lieber auf die Überschneidungen – wie viel Gemeinsamkeit steckt hinter den einzelnen Punkten wirklich?

Die Themen Budgetverantwortung und Marktanalyse sind in unserer Aufzählung interessanterweise jene, bei denen wir die größten Überschneidungen sehen. Hintergrund und Umfang können, je nach Verantwortungsträger:in (z.B. Vorwissen, Erfahrung, Kompetenzen) und organisatorischen Voraussetzungen (z.B. Existenz eines Projektmanagement Office, das beispielsweise das Budgetmanagement übernimmt) sehr unterschiedlich sein.

Sowohl PM als auch PO müssen Arbeitspakete (PM) bzw. Product Backlog Einträge (PO) schneiden und in eine logische (PM) bzw. wertemaximierende (PO) Reihenfolge bringen. Allein an diesem Satzbau merkt man schon, dass die genannten Tätigkeiten Ähnlichkeiten aufweisen und doch nicht ganz unter einen Hut zu bringen sind. Dennoch lohnt sich ein genauerer Blick. Im Projektmanagement nach Prince2 handelt es sich beim Schneiden und Ordnen von Arbeitspaketen um eine sehr spezielle und formalisierte Vorgehensweise. Ihr Zweck ist die Planung des Gesamtprojekts und die vollständige und formalisierte produktbasierte Planung der nächsten Managementphase im Projekt. Der Zweck des Schneidens und Ordnens von Product Backlog Einträgen wiederum ist die Vorbereitung und Optimierung einzelner Iterationen von nur wenigen Wochen. So soll stückweise die Produktvision umgesetzt werden. Scrum gibt keine formalisierte Vorgehensweise vor, diese wählt sich der:die PO nach eigenem Ermessen. Aus jeder Iteration soll im Scrum je mindestens ein Inkrement entstehen, was bei einem IT Produkt also ein fertiges Software-„Mosaiksteinchen“ wäre. Das funktioniert nur, wenn zusammenpassende Product Backlog Einträge von den Entwickler:innen zu funktionierender Software umgewandelt werden. Hierfür ist die sinnvolle Ordnung des Product Backlogs eine wichtige Voraussetzung. Im Gegensatz zum:zur PM ordnen der:die PO allerdings nicht sämtliche Product Backlog Einträge, sondern nur jene mit der höchsten Priorisierung, die innerhalb der nächsten Iterationen bearbeitet werden müssen. Der iterative Schwerpunkt in Scrum bedeutet natürlich nicht, dass nicht auch ein:e PO eine möglichst klare Produktvision im Blick haben und behalten muss – den Weg zu ihrer Umsetzung soll er:sie jedoch explizit nicht durchplanen. Dies hat mehrere Gründe, beispielhaft nennen wir den Folgenden: Sobald sich Änderungen am Produkt ergeben – und diese gibt es in Scrum erfahrungsgemäß häufig – wäre die vorher investierte Zeit in eine Vorplanung verschwendet, da einige Product Backlog Einträge angepasst oder gar komplett über Bord geworfen werden müssten. Zusammengefasst sind die Ziele des Schneidens und Ordnens verschieden (Gesamtprojektplanung vs. Iterationsplanung). Die Wege dorthin können jedoch deutliche Parallelen aufweisen, so lässt sich die produktbasierte Planung des Projektmanagements nach Prince2 und das in Verbindung mit Scrum oft verwendeten User Story Mapping durchaus vergleichen.

Das Stakeholder-Management findet sich in beiden Vorgehensweisen wieder und gehört somit sowohl zur Zuständigkeit des:der PO als auch der:des PM. Jedoch bezwecken beide unterschiedliche Ergebnisse. Der:die PM ermöglicht durch eine gute Kontaktpflege mit seinen:ihren Stakeholdern beispielsweise eine gute Überprüfbarkeit des Business Case. Ebenso, um ein zweites von vielen möglichen Beispielen zu nennen, empfiehlt es sich, dass der:die PM umfangreiche Projektreporte verfasst, um dadurch bei den Stakeholdern des Projekts Vertrauen zu schaffen. Dem:der PO geht es im Stakeholdermanagement auch um Schaffen von Vertrauen, aber ebenso wichtig ist das Einholen von Feedback (s.u.), das Intensivieren seines:ihres Kunden- und Nutzerverständnisses und das Generieren von Akzeptanz und Unterstützung seitens der Stakeholder für die Vorgehensweise nach Scrum.

Wie bereits kurz erwähnt, ist es für eine:n PO, aber auch für eine:n PM wichtig, sich Feedback einzuholen. In beiden Vorgehensweisen wird geprüft, ob sich das regelmäßig erhaltene Feedback in das Projekt oder zu entwickelnde Produkt einarbeiten lässt. Der zentrale Unterschied ist so groß wie auch wichtig: Im Projektmanagement hat das Berücksichtigen eines solchen Feedbacks bzw. sogenannter „Anforderungen“ weitreichende Folgen, da in der Regel der gesamte Projektrahmen, einschließlich Budget, Zeitschiene usw., angepasst werden müssen. Daher sind Anforderungsberücksichtigungen im Projektmanagement die Ausnahme. Scrum auf der anderen Seite lebt von Feedback. Dies lässt sich leicht und kurz erklären: Feedback enthält Kunden- und Endnutzerwünsche. Diese Wünsche zu ermitteln und je nach Möglichkeit und Zweckdienlichkeit ins Produkt einzuarbeiten, generiert Zufriedenheit. Und diese Zufriedenheit ist ein zentraler Wert, dessen Schaffung Scrum zum Ziel hat (siehe Definition oben).

Zusammenfassend erkennen wir sogar hinter den gemeinsamen Aufgaben deutliche Unterschiede, anhand derer erkennbar wird, dass die Rollen des:der PM und des:der PO voneinander abweichen und an vielen Stellen kaum bis gar nicht vergleichbar sind.

Unsere Empfehlung: klare Rollen- und Zuständigkeitsfestlegung vornehmen

Zum Schluss gehen wir noch mal von den einzelnen Zuständigkeiten einen Schritt zurück und schauen auf den jeweiligen Zweck der PM- und der PO-Rolle. Das Hauptbestreben des:der PM ist die (Projekt-)Zielerreichung, weswegen er:sie das Augenmerk eher nach innen richtet, eine Vielzahl an Schnittstellen managt und das Projekt ganzheitlich bedient. Der:die PO wiederum strebt nach der Wertmaximierung und richtet hierfür den Blick nach außen auf den Markt, den Kund:innen und die Endnutzer:innen. Bezieht man die PO-Rolle auf einen Projektkontext, so ist sie deutlich weniger ganzheitlich ausgerichtet. Dies liegt an der Scrum-Organisation, die vorsieht, dass ein gesamtes Team (Product Owner:in, Scrum Master:in und Developer:innen) alle erforderlichen Verantwortungen teilt. Dabei sind alle drei Instanzen „ergebnisverantwortlich“ für ihre eigenen Zuständigkeitsbereiche, in denen sie jeweils die Experten sind. Der:die PO ist Expert:in für das Produkt und daher vergleichbar mit der Rolle des:der Produktmanager:in. Würde der:die PO weitere Aufgaben eines:einer PM übernehmen, käme es zu einem Ungleichgewicht im Scrum-Team, welches der Scrum-Vorgehensweise widerspricht. Daher ist es gerade an dieser Stelle sinnvoll und wichtig, die Abgrenzung zwischen PM und PO zu kennen und zu beherzigen. Wie bereits oben erwähnt, gibt es insbesondere bei der PO-Rolle einiges an Auslegungsspielraum. Daher ist es ratsam, zu irgendeinem Zeitpunkt, sinnvollerweise zu Beginn einer Entwicklungs- oder Projektarbeit, eine klare Rollen- und Zuständigkeitsfestlegung vorzunehmen, so dass eine Hybridisierung oder Verwechslung der Rollen PM und PO vermieden wird.