Gleichzeitig Projektleiter und Product Owner?

Ja oder nein – beides ist okay

Die Frage, ob ein Projektleiter auch als Product Owner agieren könnte, lässt sich kurz und knapp beantwortet „ja" oder „nein" beantworten. Negativ entsprechend dem Framework Scrum, da dies keinen Projektleiter vorsieht. Positiv aus Sicht eines Projektleiters, der damit verbunden ggf. eine besondere Wichtigkeit im Anforderungsmanagement sieht (und sich für den Erfolg seines Projektes einsetzt anstatt an Formalien zu denken, wie z.B. Rollen, RACI, etc.).

Allerdings wird mit der signalisierten Bereitschaft bereits eine Annahme getroffen, die es zu hinterfragen gilt. In die gleiche Richtig entwickelte sich die Diskussion beim Stammtisch. Fragen kamen auf, was verspricht sich der Auftraggeber (d.h. welches Ziel soll erreicht werden)? Oder in wie fern besteht ein gleiches Verständnis bzgl. Rollen und Verantwortlichkeiten? Somit lässt sich die Frage eigentlich erst beantworten, wenn die Rahmenbedingungen geklärt sind.

Pragmatisches Vorgehen und Vorsicht vor falschen Vorstellungen

Agile Methoden in das phasenweise Vorgehen zu integrieren können z.B. mittels Daily Stand-Up, Kanban-Board, Pilot-Modell vor der Umsetzung erstellen oder jeweils die nächste Phase konkret planen, etc. sein. Wer bereits positive Erfahrungen gesammelt hat, wird in der Reflektion ggf. erkennen, dass ein pragmatisches Vorgehen zur täglichen Arbeit gehört, in dem die Vorteile beider Vorgehensweisen zum Vorteil des eigenen Projektes für die entsprechende Zielerreichung eingesetzt werden können.

Unabhängig davon sollte agiles Arbeiten nicht mit „totaler" Flexibilität verwechselt werden. Ebenso wenig bedeutet Scrum, dass nicht dokumentiert werden muss (nebenbei: dokumentiert wird, wenn gefordert z.B. nach ISO oder wenn es einen Mehrwert gibt z.B. weniger Aufwand im Produkt). Zudem sollte agiles Arbeiten nicht pauschal mit Kosteneinsparung gleichgesetzt werden, da die Basis für ein Vergleich nicht gegeben ist. Und bzgl. der „totalen" Transparenz wäre u.a. die Mitarbeiterzufriedenheit ein Indikator für mögliche Grenzen.

Zielsetzung klären

Im Bezug auf die eingehende Frage können unterschiedliche Annahmen betrachtet werden. Exemplarisch dazu: Wenn die Anforderungen an das Produkt unklar sind, dann könnte mittels Iterationen diese erarbeitet bzw. konkretisiert werden. Dabei wäre zu empfehlen, neben dem Auftraggeber auch die Kunden/Nutzer mit einzubeziehen. Aus den Ergebnissen, die auf Zuspruch stoßen, wird je Iteration die Anforderungen für das Produkt immer konkreter entwickelt. Von Vorteil ist, wenn dem Auftraggeber klar ist, dass sein Engagement Indikator für die Wichtigkeit ist.

Mit Blick auf das Rollenverständnis: Wenn ein*e Verantwortliche*r für das Produkt ein Projekt leitet, dann kann davon ausgegangen werden, dass ihr*ihm die Linientätigkeiten bekannt sind. Dann stellt sich die Frage, in wie fern Know-How im Bezug auf Projektmanagement vorhanden ist oder aufgebaut werden sollte. Andersherum stellt sich die Frage, welches Know-How und welche Aufgaben muss ein*e Projektleiter*In erfüllen, wenn davon ausgegangen wird, dass die Aufgabe mit der Einführung des Produktes endet. D.h. unabhängig der Konstellation ist die Zielsetzung zu klären, bevor die Frage jeweils individuell beantwortet werden kann.