Wer als Product Owner in einen Hochschul-Relaunch startet, ohne Rollenklarheit zu haben, setzt den Projekterfolg schon in Woche eins aufs Spiel. Die ersten Entscheidungen prägen alles Folgende.     

Oft läuft es so: Jemand aus der Hochschulkommunikation, dem Dekanat oder der IT wird ernannt – meist ohne klare Übergabe, ohne Handbuch, manchmal ohne es selbst zu wollen. „Du machst das jetzt“ – kein seltener Satz in Hochschulen.

Hier sind sechs Fragen, die sich jeder stellen sollte, der neu in diese Rolle kommt – und die Antworten und Tools, die Stunden an Frustration verhindern und einen erfolgreichen Projektstart, und somit ein erfolgreiches Projekt begünstigen.

1. Welche Rolle habe ich als Product Owner und was sind meine Aufgaben?

Der Product Owner arbeitet im Dienste des Projekts. Sein Steuerungsinstrument ist das Backlog – er priorisiert und trägt dafür Verantwortung.

Zu oft werden Project Owner auch als Project Manager genutzt, was zu vermeiden ist, da es verschiedene Rollen sind und zu Überforderung führt.

Hier ist eine Differenzierungshilfe:

Für eine produktive Arbeitsweise gilt:

• Der Product Owner entscheidet darüber, was gebaut wird, nicht darüber wie

• Der Product Owner kein Vollzeit-Kommunikationskanal für alle Stakeholder

Für den Werkzeugkoffer: Der Product Owner braucht ein Mandat. Es ist die schriftlich bestätigte Befugnis (z.B. von der Hochschulleitung an alle Stakeholder kommuniziert), Entscheidungen in einem definierten Bereich verbindlich zu treffen, ohne jedes Mal neu um Erlaubnis fragen zu müssen. Ohne dieses Mandat kommt es zu ständigen Nachverhandlungen, Priorisierungschaos, Lähmung und Frustration.

2. Wer hat welches Interesse an dem Projekt, und wie arbeiten wir zusammen?

Erwartungsmanagement startet nicht in Woche drei. Es startet in Woche eins. Um Eskalationen, Blockaden und nachträgliche Anforderungen zu vermeiden, müssen die Interessen, Einfluss und Zuständigkeiten aller beteiligten Stakeholder früh geklärt werden.

•        Hochschulleitung / Kanzlei → hohes Interesse, hoher Einfluss

•        Dekanate / Fachbereiche → starke Einzelinteressen, mittlerer Einfluss

•        IT / Rechenzentrum → Umsetzungshoheit, operative Abhängigkeiten

•        Kommunikation / Marketing → inhaltliche Expertise, teils ungeklärte Zuständigkeiten

•        Datenschutz, Personalrat → Veto-Protenzial, oft zu spät einbezogen

•        Entwicklung → Meta Interesse, setzen es um

Für den Werkzeugkoffer: eine einfache Stakeholder-Map (Einfluss × Interesse). Dieses am besten bereits zu Beginn anlegen, um alle Interessen überblicken und einordnen zu können.

3. Wie sieht der optimale Projektstart aus und wer muss involviert sein?

Der Kick-off ist ist die erste gemeinsame Weichenstellung und entscheidet, ob das Projekt mit Klarheit oder mit offenem, gefährlichem Interpretationsspielraum startet.

Was hier geklärt werden muss:

• Scope: Was gehört zum Projekt, was explizit nicht

• Ziele: Was soll die neue Website leisten – nicht nur wie sie aussehen soll

• Erste Backlog-Struktur: grobe Cluster, noch keine User Stories

• Definition of Done: Wann ist der Relaunch „fertig"? Kriterien benennen, nicht offen lassen

• Rollen: Wer entscheidet was – und wer wird nur konsultiert?

Pflichtteilnehmende:

• Hochschulleitung / Kanzlei – geben Mandat, setzen Ziele

• Product Owner – übernimmt Entscheidungsverantwortung

• IT / Rechenzentrum – klären technische Machbarkeit und Abhängigkeiten

• Kommunikation / Marketing – inhaltliche Ziele, Scope-Definition

Optional:

• Dekanate / Fachbereiche – ein Vertreter reicht, nicht alle

Nicht im Kick-off, aber früh danach einbinden:

• Datenschutz / Personalrat – Veto-Potenzial

• Entwicklung – bekommt die Ergebnisse

4. Welche Startfehler sind typisch, und wie vermeide ich sie?

Bei großangelegten Website-Projekten findet sich häufig das gleiche, unheilvolle Muster: Großer Enthusiasmus am Anfang, wachsende Unklarheit in der Mitte, Frust am Ende. Und meistens lässt sich der Ursprung auf die ersten zwei Wochen zurückverfolgen.

Hier typische, vermeidbare Fehler und die Gegenmaßnahmen:

5. Zusammengefasst: Was sollte in Woche 1 passieren?

Die Top 3 To-Do: Was hier nicht geklärt wird, bringt das Projekt später ins Stocken.

Mandat klären – schriftlich, mit definierten Entscheidungsrechten 

Der PO braucht eine klare Befugnis: Was darf er entscheiden, ohne rückfragen zu müssen? Das muss schriftlich vorliegen – nicht als informelle Absprache im Flur, sondern als bestätigtes Dokument der Hochschulleitung.

Stakeholder-Map anlegen – Einfluss und Interesse aller relevanten Gruppen 

Wer hat Einfluss auf das Projekt? Wer hat Interesse – und welches? Ziel ist ein Überblick: Wer muss früh eingebunden werden, wer hat Veto-Potenzial, wer wird nur informiert?

Kick-off terminieren – mit Zieldefinition, nicht nur Projektvorstellung 

Der Kick-off ist der Moment, in dem Ziele, Scope und Rollen verbindlich festgelegt werden – das muss allen klar sein.

Ob man nun mit einem ‚Du machst das jetzt' ins Projekt startet oder sich bewusst für die Rolle als Product Owner entschieden hat, für ein erfolgreiches Projekt braucht man Klarheit über seine Rolle, einen Überblick über die Beteiligten und einen effektiven Kick-off. Wer diese drei Dinge hat, trifft von Anfang an tragfähige Entscheidungen.

Im nächsten Artikel: Wie der Product Owner den laufenden Betrieb strukturiert – zwischen Backlog-Management, Hochschulpolitik und Stakeholder-Kommunikation.