Zwischen allen Stühlen? Der Product Owner in der öffentlichen Verwaltung

Im Scrum-Rahmenwerk gibt es keinen Projektleiter im herkömmlichen Sinne mehr. Einige seiner Aufgaben übernimmt der Product Owner (andere Aufgaben gehen auf den Scrum Master oder das Team über, einige fallen ganz fort). Und er bekommt Kompetenzen und Aufgaben zusätzlich, die für eine öffentliche Verwaltung oft in Richtung „Amtsanmaßung“ deuten. Mit einem Wort: der „PO“ hat es nicht leicht. Und er ist – ganz unabhängig von Scrum – ein Beispiel für die Änderungen der Organisationskultur, die agile Arbeitsweisen für die Verwaltung bedeuten.

Die Rolle des Product Owners

Die folgenden Erklärungen und Beispiele beziehen sich auf Digitalisierungsprojekte („Einführung der eAkte“) in Verwaltungen. Aber ich glaube, auch in anderen Projekten der Organisationsentwicklung dürften Verantwortliche ähnliche Erfahrungen machen.

In unseren Seminaren beschreiben wir die Rolle des Product Owners als eine Art „Mini-CEO“ für das Projekt:

  • Er ist verantwortlich für die Erreichung der Projektziele und die Einhaltung des Projektbudgets (in Euro und in internem Personalaufwand).
  • Er hat die Hoheit über die Anforderungsliste des Projekts (das sog. „Product Backlog“). Er sorgt dafür, dass neue Anforderungen, die im Laufe des Projekts aufkommen, in die Anforderungsliste aufgenommen werden.
  • Er definiert Umfang und Qualität, mit denen Anforderungen umgesetzt werden (nur „Pareto-Niveau“? Oder inclusive „Sahnehäubchen“?)
  • Er entscheidet über das „Was“ im Projekt: Er wählt die Aufgaben aus, die im nächsten Sprint erledigt werden sollen.
  • Er nimmt die Sprintergebnisse im sog. Review ab.
  • Er bestimmt nicht, wie das Team die Arbeit erledigt.
  • Er greift nicht in die Selbstorganisation des Teams ein.

Der Product Owner (PO) ist der Nutzenmaximierer (Nutzen für die Anwender und Nutzen für die Organisation). Er muss deshalb ein gutes Verständnis für Verwaltungsprozesse haben und dafür, was die künftigen Anwender der eAkte brauchen. Dann kann er sie gut unterstützen beim Formulieren von Anforderungen. Er muss nicht sehr IT-affin sein oder die internen Datenstrukturen von DMS-Produkten kennen.

Der große Unterschied zu herkömmlichen Projekten: auch kein Auftraggeber und kein Lenkungsausschuss kann dem PO in seine Entscheidungen hineinreden. Das ist für hierarchische Organisationen (egal ob Öffentlicher Dienst oder Privatwirtschaft) eine extreme Umstellung. Immer wollen Führungskräfte entscheiden dürfen, ob sie mit einem Projektergebnis zufrieden sind oder nicht. Bei Scrum liegt das Recht der Ergebnisbeurteilung allein beim Product Owner. Alles andere würde zu dauernden unnötigen Verbesserungsschleifen führen und das Projekt unabsehbar in die Länge ziehen.

Der Product Owner im Fadenkreuz zwischen Umsetzungsteam und allen Stakeholdern des Projekts

Herausforderung: Delegation von Entscheidungen nach unten

Ich bringe zwei Beispiele, um zu zeigen, wie die Kompetenzzuschreibungen zur Rolle des PO’s zu Konflikten mit herkömmlichen „Zuständigkeiten“ führen können.

Beispiel 1:

In agilen Projekten wird in Sprints gearbeitet. Im Umsetzungsteam für das DMS ist immer auch ein Programmierer des Software-Lieferanten dabei (zumindest solange, bis die DMS-Administratoren in der Verwaltung so fit sind, dass sie die Software eigenständig, ohne Rückgriff auf den Hersteller, customizen können). Diesem Programmierer wird in der Regel am Ende des Sprint-Planungsmeetings ein Auftrag zur Realisierung bestimmter Customizing-Anforderungen im System erteilt. Dieser Auftrag stellt rechtlich einen Werkvertrag dar. Wenn es um zwei, drei Programmierertage geht, kann der Aufwand schon eine vierstellige Summe ausmachen. Agile Philosophie bedeutet: der PO darf diesen Werkvertrag abschließen. In vielen Verwaltungen übersteigt das aber die Wertgrenzen, für die er Zeichnungskompetenz hat. Also meldet sich die Beschaffungssstelle: „Lieber Kollege PO, du musst einen Beschaffungsantrag bei uns stellen.“

Das sprengt natürlich die ganze agile Logik des Arbeitens in kurzen Zyklen. Zum Beispiel ist die Sprintlänge im DMS-Projekt zwei Wochen, und die Beschaffung braucht mindestens eine Woche, bis sie den Beschaffungsantrag durch ihren Prozess („best practice! KGSt-geeicht!“) durchgeschleust hat. Der Antrag wird genehmigt zu einem Zeitpunkt, an dem die Leistung schon erbracht sein müsste.

Beispiel 2

Der Product Owner ist zuständig für die Abnahme des Produkts. Der oder die Auftraggeber („Lenkungsausschuss“) erhalten keine Projektstatusberichte mehr. Sie haben stattdessen die Möglichkeit, am Ende des Sprints zum sog. „Review“ zu kommen und sich den Zwischenstand der Projektarbeit praktisch vorführen zu lassen.

In einem meiner Projekte nahm der Hauptamtsleiter, Herr Büttenküfer, diese Möglichkeit ab und zu wahr. Immer wenn er zur Tür reinkam, meist zehn Minuten nach Meetingbeginn, schnaufte er ein bisschen. Weniger wegen der Treppen zum Sitzungszimmer unter dem Dach, als um auszudrücken: „Jetzt muss ich mich zu meinen Untergebenen bewegen. Früher war das aber anders!“

Ein Ereignis ist mir noch im Gedächtnis, obwohl es bestimmt vier Jahre her ist. Das Ergebnis des Sprint-Reviews war „ein Standard für Dokumentennamen“. Zur Erklärung: in einem modernen DMS gibt es keine Dokumentennamen mehr. Es gibt nur noch Metadaten zu Dokumenten, ähnlich wie schon bei E-Mails: die zugehörige Vorgangs-ID, ein Erstellungsdatum, der Verfasser, evtl. ein Betreff oder ein Stichwort usw. Namen für Dokumente und Dateien treten nur wieder beim Export auf, wenn ich eine Datei als Anhang mit einer E-Mail an einen externen Empfänger versenden will oder auf einen USB-Stick kopiere.

Das Team erläuterte, welche Metadaten künftig in die Bildung von Dokumentennamen einfließen werden und welche Bedarfe verschiedener Anwendergruppen man berücksichtigt habe. Auf einmal hielt es Herrn Büttenküfer nicht mehr. „In unserer aktuellen Dienstanweisung, die wir schon zur Einführung der ersten PC’s ganz aktuell verfasst hatten, steht ganz eindeutig, dass das Datum am Anfang jedes Dateinamens zu stehen hat. Und das haben wir uns damals ganz genau überlegt und aus guten Gründen so beschlossen. Jetzt haben wir endlich ein DMS und wir können dafür sorgen, dass die DA auch endlich eingehalten wird, und was machen wir?? Wir werfen alles über den Haufen! Damit bin ich überhaupt nicht einverstanden. Das müssen Sie bitte noch einmal überarbeiten!“ Sprach’s und verabschiedete sich wieder aus dem Meeting.

Was Herr Büttenküfer nicht verstand oder nicht respektieren wollte: Er hatte massiv seine Rolle verletzt. Die Frage, wie ein bestimmtes Detail im DMS zu customizen ist, ist nicht Sache der Führungskraft als Auftraggeber (in diesem Falle ist er Anwender wie jeder Sachbearbeiter). Sondern es ist Sache des Teams, das eigenständig Lösungen erarbeitet auf Grundlage bestimmter Qualitätskriterien . Und es ist Sache des Product Owners, der diese Lösungen abnimmt und dies auch nicht willkürlich, sondern eben auf der Basis der vereinbarten Anforderungen und ihrer Qualitätsstandards.

Im Ergebnis hatte der Hauptamtsleiter das Umsetzungsteam demotiviert und den PO herabgesetzt.

In beiden Beispielen geht es darum, dass Entscheidungen „nach unten“ – an den (in herkömmlichen Begriffen:) Projektleiter = Product Owner delegiert werden. Das erste Beispiel verweist zusätzlich darauf, dass Prozesse in den Verwaltungen oft lokal optimiert werden (der Prozess „des Einkaufs“) und nicht global (als End-to-end-Prozesse). Prozesse werden in den Silos optimiert, auch wenn das global einen Rückschritt darstellt.

Im zweiten Beispiel entpuppt sich Herr Büttenküfer als Mikromanager, der sich als besserer „Fachexperte“ in Sachen Dokumentennamensregel-festlegungsfertigkeit beweisen will und darüber seine Rolle als Führungskraft aus den Augen verliert.

Autor: Wolf Steinbrecher

Volkswirt und Informatiker. Zuerst als Anwendungsentwickler in Krankenhäusern und Systemhäusern tätig. Dann von 1995 bis 2008 Sachgebietsleiter für Organisation und Controlling in einem baden-württembergischen Landkreis (1.050 MA). Seitdem Berater für Teamarbeit und Dokumentenmanagement. Teilhaber der Common Sense Team GmbH Karlsruhe, www.commonsenseteam.de. Blogger bei www.teamworkblog.de.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.