Product Ownership im KMU – warum jedes IT-Projekt eine klare fachliche Verantwortung braucht

In fast jedem IT-Projekt, das ins Stocken gerät, gibt es einen Moment, in dem alle Beteiligten gleichzeitig auf jemand anderen zeigen. Der Fachbereich sagt, die IT habe die Anforderungen nicht verstanden. Die IT sagt, die Anforderungen seien unklar gewesen. Die Geschäftsleitung fragt, warum das Projekt doppelt so lange dauert wie geplant. Und mittendrin fehlt eine Person, die eine entscheidende Aufgabe hätte übernehmen sollen: die fachliche Verantwortung für das, was gebaut wird.

In der agilen Welt hat diese Rolle einen Namen: Product Owner. Doch viele KMU verbinden den Begriff mit grossen Scrum-Teams, Post-it-Wänden und zertifizierten Methodenberatern. Die Realität ist eine andere. Die Kernidee hinter Product Ownership ist universell, methodenunabhängig und gerade für kleinere Unternehmen entscheidend. Sie lautet: Jemand muss verbindlich entscheiden, was gebaut wird, warum es gebaut wird und in welcher Reihenfolge. Und diese Person darf weder ausschliesslich aus der IT noch ausschliesslich aus der Geschäftsleitung kommen.

Das Problem: Verantwortung ohne Adresse

In vielen KMU laufen IT-Projekte nach einem Muster ab, das auf den ersten Blick vernünftig wirkt: Ein Fachbereich formuliert einen Wunsch, die Geschäftsleitung gibt grünes Licht, ein IT-Dienstleister oder die interne IT-Abteilung beginnt mit der Umsetzung. Was fehlt, ist die laufende, operative Steuerung zwischen diesen drei Welten.

Der Fachbereich hat formuliert, was er sich vorstellt, aber er ist im Tagesgeschäft gebunden und hat keine Zeit, jede Detailfrage zu beantworten. Die Geschäftsleitung hat das Budget freigegeben, aber keine Kapazität, um in der täglichen Projektarbeit mitzudenken. Die IT setzt um, was sie verstanden hat, aber sie trifft dabei zwangsläufig Annahmen – weil niemand da ist, der sie zeitnah korrigiert.

Das Ergebnis sind Projekte, bei denen am Ende ein Produkt steht, das technisch funktioniert, aber am Bedarf vorbeigeht. Nicht weil die beteiligten Menschen schlecht gearbeitet hätten, sondern weil die fachliche Steuerung niemandem klar zugewiesen war. Verantwortung ohne Adresse führt zu Ergebnissen ohne Wert.

Was Product Ownership wirklich bedeutet

Der Begriff Product Owner stammt aus dem Scrum-Framework, aber sein Kern ist älter als jede agile Methode. Es geht um eine einfache Frage: Wer entscheidet, was das Projekt liefern soll – und wer stellt sicher, dass das Gelieferte auch tatsächlich nützlich ist?

Ein Product Owner – egal ob man die Person so nennt oder nicht – übernimmt drei zentrale Aufgaben.

Erstens: Anforderungen klären und priorisieren. Nicht alles, was sich ein Fachbereich wünscht, ist gleich wichtig. Nicht alles, was technisch möglich ist, ist auch wirtschaftlich sinnvoll. Jemand muss den Überblick behalten, Anforderungen gegeneinander abwägen und entscheiden, was zuerst umgesetzt wird. Das ist keine technische Aufgabe, sondern eine geschäftliche. Und es ist keine Aufgabe, die man an einen externen IT-Dienstleister delegieren kann.

Zweitens: Entscheidungen treffen. In jedem Projekt gibt es Hunderte von Detailfragen, die nicht im ursprünglichen Konzept stehen. Soll das Formular fünf oder acht Felder haben? Welche Benutzergruppe bekommt welche Rechte? Was passiert, wenn ein Sonderfall eintritt? Wenn diese Fragen nicht zeitnah beantwortet werden, passiert eines von zwei Dingen: Entweder das Projekt steht still, oder die IT trifft die Entscheidung selbst – nach bestem Wissen, aber ohne Geschäftskontext.

Drittens: Das Ergebnis bewerten. Ein Feature ist nicht fertig, wenn der Code geschrieben ist. Es ist fertig, wenn jemand aus dem Fachbereich bestätigt, dass es den Bedarf trifft. Das klingt selbstverständlich, wird in der Praxis aber erstaunlich oft übersprungen. Der Product Owner schaut sich regelmässig an, was entstanden ist, gibt Feedback und korrigiert den Kurs, bevor aus einer kleinen Abweichung ein grosses Problem wird.

Warum die Rolle gerade im KMU so wichtig ist

Grosse Unternehmen haben Projektmanagement-Offices, Business Analysten, Requirements Engineers und dedizierte Product Owner. KMU haben das in der Regel nicht. Das bedeutet aber nicht, dass die Aufgabe entfällt. Es bedeutet, dass sie von jemandem übernommen werden muss, der bereits eine andere Funktion hat – und genau hier wird es in der Praxis schwierig.

In vielen KMU übernimmt die Geschäftsleitung diese Rolle informell, ohne sich dessen bewusst zu sein. Der CEO gibt das Projekt in Auftrag, schaut alle paar Wochen einmal rein, ist dann unzufrieden mit dem Stand und greift punktuell ein. Das ist kein Product Ownership, das ist reaktives Krisenmanagement. Es fehlt die Kontinuität, die ein Projekt braucht, um auf Kurs zu bleiben.

Andere Unternehmen delegieren die fachliche Steuerung komplett an den IT-Dienstleister. Das ist verständlich, aber riskant. Ein guter IT-Partner kann beraten, Optionen aufzeigen und technische Empfehlungen geben. Aber er kann nicht wissen, welcher Prozess für das Unternehmen wirklich geschäftskritisch ist, welche Daten die Geschäftsleitung tatsächlich braucht oder welche Arbeitsabläufe die Mitarbeitenden im Alltag nutzen. Dieses Wissen steckt im Unternehmen selbst – und nur dort.

Die Stärke von Product Ownership im KMU liegt darin, dass sie dieses interne Wissen mit der technischen Umsetzung verbindet. Nicht über endlose Dokumentationen und Freigabeprozesse, sondern über eine Person, die regelmässig mit dem Projektteam spricht, Entscheidungen trifft und sicherstellt, dass das Ergebnis zum Geschäft passt.

Product Ownership ohne Scrum – wie das in der Praxis funktioniert

Viele KMU arbeiten nicht nach Scrum. Sie arbeiten nicht in Sprints, haben kein Backlog und kein Daily Stand-up. Das ist völlig in Ordnung. Product Ownership ist keine Methode, sondern eine Verantwortung. Und diese Verantwortung lässt sich in jedes Projektformat integrieren – ob klassisch, agil oder irgendwo dazwischen.

In einem klassischen Wasserfall-Projekt bedeutet Product Ownership, dass eine Person die Anforderungen nicht nur einmal zu Beginn formuliert und dann verschwindet, sondern das Projekt durch alle Phasen begleitet. Sie überprüft die Spezifikation, nimmt an Meilensteinterminen teil, testet Zwischenergebnisse und gibt Feedback, bevor das Projekt in die nächste Phase übergeht.

In einem Projekt mit externem Dienstleister bedeutet es, dass das Unternehmen einen festen Ansprechpartner benennt, der befugt ist, Anforderungen zu klären und Entscheidungen zu treffen. Nicht jemand, der jede Frage erst intern eskalieren muss, sondern jemand mit ausreichend Überblick und Entscheidungskompetenz. Das beschleunigt das Projekt massiv und reduziert Reibungsverluste.

In einem laufenden System – etwa nach der Einführung einer neuen Software – bedeutet Product Ownership, dass jemand die Weiterentwicklung steuert. Welche Verbesserungswünsche werden umgesetzt? Welche Fehler haben Priorität? Wie verändert sich der Bedarf, wenn das Unternehmen wächst? Ohne diese Steuerung verkommt jede Software innerhalb weniger Jahre zu einem System, das die Mitarbeitenden umarbeiten, anstatt es zu nutzen.

Wer eignet sich für die Rolle?

Die ideale Person für Product Ownership in einem KMU hat drei Eigenschaften: Sie versteht das Geschäft, sie kann Entscheidungen treffen und sie hat die Bereitschaft, sich regelmässig mit dem Projekt zu befassen. Technisches Fachwissen ist ein Vorteil, aber keine Voraussetzung. Es geht nicht darum, selbst Code zu schreiben oder Systemarchitekturen zu beurteilen. Es geht darum, die Brücke zwischen dem, was das Unternehmen braucht, und dem, was die IT baut, stabil zu halten.

In der Praxis übernehmen diese Rolle oft Abteilungsleitende, erfahrene Teamleitende oder Personen aus dem mittleren Management, die nah genug am operativen Geschäft sind, um den Bedarf zu kennen, aber gleichzeitig genug strategischen Überblick haben, um Prioritäten zu setzen. Entscheidend ist, dass die Person von der Geschäftsleitung mit ausreichend Entscheidungskompetenz ausgestattet wird. Ein Product Owner, der jede Entscheidung erst genehmigen lassen muss, ist kein Product Owner – sondern ein Briefträger.

Genauso wichtig ist, dass die Person ausreichend Zeit für die Rolle bekommt. Product Ownership funktioniert nicht nebenbei, zwischen Tagesgeschäft und E-Mail-Flut. Es braucht nicht Vollzeit, aber es braucht verlässlich reservierte Kapazität. In den meisten KMU-Projekten sind das drei bis fünf Stunden pro Woche. Das klingt nach viel, ist aber ein Bruchteil dessen, was ein gescheitertes oder nachgebessertes Projekt am Ende kostet.

Die häufigsten Fehler – und wie man sie vermeidet

Die Rolle nicht explizit vergeben. Der häufigste Fehler ist, die Verantwortung gar nicht erst zuzuweisen. Alle nehmen an, jemand anders kümmert sich darum. In der Realität kümmert sich dann niemand. Die Lösung ist einfach: Zu Beginn jedes IT-Projekts wird eine Person benannt, die die fachliche Verantwortung trägt. Das muss kein formeller Titel sein. Es muss klar sein, dass diese Person Entscheidungen trifft und Ansprechpartner für die IT ist.

Die falsche Person wählen. Nicht jeder, der das Tagesgeschäft kennt, ist automatisch geeignet. Eine Person, die sich in Details verliert und keine Prioritäten setzen kann, wird das Projekt nicht voranbringen. Genauso wenig wie eine Person, die so weit vom operativen Geschäft entfernt ist, dass sie die konkreten Bedürfnisse der Nutzer nicht kennt. Die richtige Balance zwischen Überblick und Praxisnähe ist entscheidend.

Keine Entscheidungskompetenz geben. Wenn der Product Owner jede Entscheidung erst mit drei Hierarchieebenen abstimmen muss, verliert die Rolle ihren Wert. Die Person braucht ein klar definiertes Mandat: Welche Entscheidungen darf sie allein treffen? Ab welcher Tragweite muss sie eskalieren? Ohne diese Klarheit wird die Rolle zum Flaschenhals statt zum Beschleuniger.

Product Ownership mit Projektmanagement verwechseln. Ein Projektmanager steuert Zeitpläne, Budgets und Ressourcen. Ein Product Owner steuert Inhalte, Prioritäten und Qualität. Beides ist wichtig, aber es sind unterschiedliche Aufgaben. In kleineren Projekten kann eine Person beides übernehmen, solange beide Aspekte bewusst abgedeckt werden.

Der Unterschied, den es macht

Unternehmen, die die fachliche Verantwortung für IT-Projekte klar zuweisen, erleben in der Regel drei Dinge. Erstens: Die Projekte werden schneller umgesetzt, weil Entscheidungen nicht wochenlang in der Schwebe hängen. Zweitens: Das Ergebnis passt besser zum tatsächlichen Bedarf, weil der Kurs laufend korrigiert wird. Drittens: Die Zusammenarbeit zwischen Business und IT verbessert sich grundlegend, weil es eine Person gibt, die beide Sprachen spricht.

Das sind keine revolutionären Erkenntnisse. Aber es sind Erkenntnisse, die in der täglichen Projektpraxis erstaunlich oft ignoriert werden. Weil es bequemer ist, die Verantwortung zu verteilen. Weil niemand die zusätzliche Aufgabe übernehmen will. Weil das Thema Product Ownership nach agiler Methodik klingt und man doch eigentlich gar nicht agil arbeitet.

Die Wahrheit ist: Es spielt keine Rolle, welche Methodik ein Unternehmen verwendet. Es spielt eine Rolle, ob jemand die fachliche Verantwortung für das übernimmt, was gebaut wird. Wenn ja, steigen die Chancen auf ein erfolgreiches Projekt massiv. Wenn nein, steigen die Chancen auf ein teures Nachbesserungsprojekt.

Und die gute Nachricht: Es braucht dafür keinen zertifizierten Product Owner, kein Framework und kein teures Training. Es braucht eine Person mit Geschäftsverständnis, Entscheidungsfreude und ein paar Stunden pro Woche. Das ist eine überschaubare Investition für einen Unterschied, der über Erfolg oder Scheitern eines Projekts entscheiden kann.