Hinter dem 20. Türchen unseres Agilen Adventskalenders verbirgt sich die Antwort auf eine Frage, die sich bestimmt viele von uns schon einmal gestellt haben:
Worin unterscheidet sich der Product Owner vom klassischen Projektleiter?
Product Owner vs. Projektleiter
Klassische Projektleiter tun sich oft schwer, ihre Aufgaben von denen eines Product Owner zu unterscheiden. Besonders dann, wenn sie bisher noch nicht in einem agilen Umfeld gearbeitet haben.
Umgekehrt können Product Owner die Herausforderungen eines klassischen Projektleiters oft nicht verstehen, wenn sie in ihrer Laufbahn noch keine Berührungspunkte mit klassischen Organisationen hatten.
Nun, da ich beide Welten gut kenne, wage ich mich an einen Abgrenzungsversuch in Form meines Blickwinkels aus meiner Praxis.
Projektleiter
Beginnen wir mit dem Projektleiter. Für gewöhnlich lassen sich seine Aufgaben grob so zusammenfassen:
Oft beginnt die Arbeit des Projektleiters bereits in der Initiierungsphase des Projektes. In dieser müssen die einzelnen Projektphasen mit den Beteiligten ausgearbeitet, abgestimmt und zu guter Letzt die Freigabe für den Projektplan eingeholt werden. Dabei gilt es, den Zeitplan und zuvor festgelegte Budgets einzuhalten.
Dazu werden temporär Ressourcen in Form von Fachexperten zur Erledigung der Teilaufgaben aus dem Projektplan bereitgestellt. Diese Ressourcen müssen koordiniert werden.
Der Projektleiter muss nun Sorge tragen, dass jeder beteiligte Fachexperte zum richtigen Zeitpunkt weiß, was er zu tun hat. Er muss quasi den Ablauf überwachen und auftretende Rückfragen klären (lassen). So, dass zum Ende der Projektlaufzeit aus vielen kleinen, für sich modulare Arbeitsaufgaben, ein großes, ganzes und stimmiges Gesamtprojekt vom Kunden abgenommen und gegen die ursprüngliche Beauftragung geprüft werden kann
Stichwort: Manage people and workitems. Focus on the contract!
Die Herausforderungen eines Projektleiters lassen sich so zusammenfassen:
- Plan vs. Realität: Plan und Angebot gehen oft von einem Best-, vielleicht noch Likely-Case aus. Dieser Unsicherheitsfaktor führt unweigerlich zu Abweichungen, die zumeist keine Berücksichtigung im Projektplan finden.
- Erbringung der Leistung geht einher mit dem Teilen von Wissen und Kontext-Verständnis der Beteiligten. Diese werden aber nur für ihre Arbeitsaufgabe eingeplant und aufgeschlaut. Das Verständnis für den Gesamtkontext bleibt so auf der Strecke. Auch Kreativität – was das Lösungsdesign angeht – ist nicht gewünscht oder gefordert. Dadurch wird nicht das volle Lösungspotenzial ausgeschöpft.
- Der Projektleiter ist der „Single-Point-of-Control“. Bei ihm laufen alle Fäden zusammen, und mit ihm steht oder fällt oft auch die erfolgreiche Umsetzung. Seine Zuordnung und Delegation von Aufgaben ist erforderlich, damit andere ihre Arbeit erledigen können.
Product Owner
Zum Vergleich nun der Product Owner. Auch hier gehe ich zunächst auf die Aufgaben ein:
Die wichtigste Aufgabe des Product Owners ist es, anhand von Priorisierung, Transparenz und Feedback aus dem Markt dafür zu sorgen, dass das Produkt möglichst viel Mehrwert für seine Stakeholder/Kunden liefert. Dazu ist Stakeholder- und Kundenmanagement enorm wichtig – also das Einholen und Priorisieren des Feedbacks der Stakeholder und Kunden – damit es bei der zukünftigen Entwicklung des Produktes berücksichtigt werden kann.
Product Owner legen darüber hinaus die strategische und inhaltliche Entwicklung des Produktes fest. Sprich: sie entscheiden über das was und deren Reihenfolge. Das erfordert die kontinuierliche Pflege des Product Backlogs. Sie ermöglicht eine empirische, iterative Produkt(weiter)-entwicklung in kurzen Zyklen.
Stichwort: Maximize the value of a product. Focus on the customer!
Die Herausforderungen des Product Owners lassen sich wie folgt zusammenfassen:
- Oft treffen sehr unterschiedliche Wünsche und Vorstellungen der Stakeholder eines Produktes auf den Product Owner. Diese gilt es möglichst wertsteigernd und kundenzentriert unter stetiger Berücksichtigung der Risikominimierung in die Produktentwicklung einzuplanen. Kein leichter Job!
- Das Setup, um eine solche Arbeit leisten zu können, ist oft nicht gegeben. Es gibt viele Missverständnisse und Wissenslücken in den Organisationen in Bereich der agilen Arbeitsweise.
- Knappe Entwicklungsressourcen und Doppelbelegung von agilen Rollen (Entwickler sind nebenbei Scrum Master, Product Owner sind zusätzlich Scrum Master) erschweren die Arbeit zusätzlich.
Fazit
All das bringt natürlich eine Menge Konfliktpotenzial mit sich, nach dem Motto: „Projektleiter vs. Product Owner – klassisch vs. agil“.
Einen Appell möchte ich mitgeben: Sorgt selbst dafür, das Konfliktpotenzial in eurer Organisation abzubauen. In dem ihr agiles Wissen aufbaut – oder aufbauen lasst. Denn welche Art der Projektabwicklung besser geeignet ist, sollte am Ende durch die vorherrschenden Fakten und nicht durch fehlendes Wissen entschieden werden.
Die Leidtragenden sind am Ende eure Kunden! Das habe ich in meiner Berufspraxis zu häufig am eigenen Leib erlebt.
[smartblock id=11351]
Schreibe einen Kommentar