Interne Stakeholder einbinden: So verhindern Sie Blockaden im Projekt

Ich habe in den letzten Jahren dutzende Webprojekte für mittelständische B2B-Unternehmen begleitet. Die Technik war dabei selten das Problem. Next.js läuft. Sanity liefert. Tailwind macht, was es soll. Was Projekte wirklich zum Stillstand bringt, sind Menschen. Genauer: interne Stakeholder, die nicht richtig eingebunden werden.

Das klingt hart. Ist aber die Realität. In fast jedem Projekt gibt es diesen Moment, in dem alles steht. Nicht weil der Server ausfällt oder ein API-Endpunkt nicht antwortet. Sondern weil irgendjemand im dritten Stock noch nicht sein Feedback gegeben hat. Oder weil der Geschäftsführer in der letzten Präsentation alles umwerfen wollte, was in drei Monaten erarbeitet wurde.

Wenn Sie dieses Muster kennen, sind Sie hier richtig.

Das klassische Problem beginnt schon beim Kickoff. Der Projektleiter lädt zum ersten Workshop ein und plötzlich sitzen zwölf Leute am Tisch. Marketing will die neue Kampagne auf der Startseite. Vertrieb braucht einen Produktkonfigurator. HR möchte eine Karriereseite, die "modern" aussieht. Die IT-Abteilung hat Sicherheitsbedenken. Und der Geschäftsführer findet, die Website müsse "mehr wie Apple" wirken.

Jeder hat recht. Aus seiner Perspektive. Aber niemand hat das Mandat, Prioritäten zu setzen. Das Ergebnis ist ein Anforderungskatalog, der so umfangreich ist, dass er in keinem Budget und keinem Zeitplan Platz findet. Und wenn dann die ersten Entwürfe kommen, beginnt das eigentliche Drama: Jeder gibt Feedback, aber niemand entscheidet.

Ich habe Projekte erlebt, in denen die Startseite achtmal überarbeitet wurde. Nicht weil das Design schlecht war. Sondern weil in jeder Feedbackrunde ein neuer Stakeholder auftauchte, der bisher nicht gehört wurde und jetzt "auch noch kurz drüberschauen" wollte. Dieses "kurz drüberschauen" kostet in der Regel zwei bis vier Wochen. Pro Person.

HiPPO steht für Highest Paid Person's Opinion. Es beschreibt ein Phänomen, das in mittelständischen Unternehmen besonders ausgeprägt ist: Die Meinung des Geschäftsführers oder Inhabers überstimmt alles. Egal, was die Daten sagen. Egal, was die Nutzerforschung ergibt. Wenn der Chef findet, dass das Logo größer sein muss, wird das Logo größer.

Das Problem dabei ist nicht die Hierarchie an sich. Natürlich darf und soll die Geschäftsführung bei strategischen Entscheidungen das letzte Wort haben. Das Problem entsteht, wenn diese Entscheidungsmacht auf operative Details angewendet wird. Wenn der Geschäftsführer über die Farbe eines Buttons diskutiert, während die Informationsarchitektur noch nicht steht, läuft etwas fundamental schief.

Wir hatten einen Kunden, bei dem der Inhaber sechs Wochen vor dem geplanten Launch die komplette Navigation ändern wollte. Nicht weil sie nicht funktionierte. Sondern weil er auf einer Messe eine Website gesehen hatte, die ihm besser gefiel. Sechs Wochen Arbeit eines fünfköpfigen Teams, potenziell umsonst. Weil niemand im Vorfeld definiert hatte, wer zu welchem Zeitpunkt welche Entscheidungen treffen darf.

Die RACI-Matrix ist ein Werkzeug aus dem Projektmanagement, das festlegt, wer für eine Aufgabe verantwortlich ist (Responsible), wer die Entscheidung trifft (Accountable), wer konsultiert wird (Consulted) und wer informiert wird (Informed). Das klingt nach Konzernbürokratie. Ist es nicht. Es ist die einfachste Methode, Chaos zu verhindern.

In der Praxis bedeutet das: Bevor Sie auch nur einen Pixel designen oder eine Zeile Code schreiben, definieren Sie für jede Projektphase und jede zentrale Entscheidung, wer welche Rolle hat. Wer entscheidet über die Informationsarchitektur? Wer gibt das Design frei? Wer bestimmt die Inhalte der Startseite? Wer hat Veto-Recht — und wann verfällt es?

Der letzte Punkt ist entscheidend. Veto-Rechte brauchen Verfallsdaten. Wenn der Vertriebsleiter bis Kalenderwoche 12 kein Feedback zur Produktseite gegeben hat, gilt der aktuelle Stand als freigegeben. Punkt. Ohne diese Regel werden Projekte zu Geiseln von vollen Terminkalendern.

Ich empfehle, die RACI-Matrix im Kickoff gemeinsam zu erarbeiten und von allen Beteiligten unterschreiben zu lassen. Ja, physisch unterschreiben. Das mag altmodisch wirken, aber es erzeugt Verbindlichkeit. Wenn drei Monate später jemand kommt und sagt "Das habe ich so nie abgesegnet", können Sie das Dokument auf den Tisch legen.

Die meisten Feedbackprozesse in Webprojekten sind kaputt. Jemand schickt einen Link per E-Mail, bittet um "kurzes Feedback" und bekommt drei Wochen später eine PowerPoint-Präsentation mit 47 Annotationen, die sich teilweise widersprechen. Oder es kommt gar nichts, und das Projekt steht still, weil auf eine Freigabe gewartet wird, die nie erteilt wurde.

Funktionierende Feedbackrunden haben drei Eigenschaften: Sie sind zeitlich begrenzt, inhaltlich fokussiert und ergebnisorientiert.

Zeitlich begrenzt heißt: Feedback ist innerhalb von fünf Werktagen einzureichen. Wer bis dahin nicht reagiert, akzeptiert den aktuellen Stand. Das muss vorher kommuniziert und vereinbart werden. Aber es muss gelten. Ohne Ausnahmen. Auch nicht für die Geschäftsführung.

Inhaltlich fokussiert bedeutet: Jede Feedbackrunde hat eine klare Fragestellung. Nicht "Wie finden Sie die neue Website?", sondern "Bildet die Navigation die Kernprozesse unserer Zielgruppe ab?" oder "Sind die Produktinformationen auf dieser Seite vollständig und korrekt?". Je präziser die Frage, desto brauchbarer die Antwort.

Ergebnisorientiert heißt: Am Ende einer Feedbackrunde steht eine Entscheidung. Nicht "wir schauen uns das nochmal an" oder "darüber müssen wir intern noch sprechen". Sondern: freigegeben, abgelehnt mit konkreten Änderungswünschen, oder Eskalation an die nächste Ebene. Drei Optionen, keine vierte.

Ein häufiger Fehler: Alle Stakeholder werden von Anfang an in alles einbezogen. Das klingt demokratisch, ist aber ineffizient und führt zu genau den Blockaden, die man vermeiden will. Verschiedene Abteilungen haben zu verschiedenen Zeitpunkten relevanten Input.

Die IT-Abteilung gehört ganz an den Anfang. Bevor Sie über Design oder Inhalte nachdenken, müssen die technischen Rahmenbedingungen geklärt sein. Welche Systeme müssen angebunden werden? Gibt es ein bestehendes CRM, ein ERP, ein PIM? Welche Authentifizierungslösung wird benötigt — etwa Keycloak für einen geschlossenen Kundenbereich? Wo wird gehostet — Cloud oder eigene Infrastruktur wie Hetzner mit Coolify und Docker?

Wenn diese Fragen nicht in den ersten zwei Wochen geklärt sind, werden sie in Woche zwanzig zum Showstopper. Ich habe Projekte erlebt, in denen kurz vor dem Launch herauskam, dass die IT ein veraltetes Active Directory betreibt, das mit keiner modernen SSO-Lösung kompatibel ist. Das hätte man im Kickoff in 30 Minuten klären können.

Marketing kommt in der Konzeptphase dazu. Wenn die technischen Rahmenbedingungen stehen, brauchen Sie den Input des Marketings für die Informationsarchitektur, die Content-Strategie und das Branding. Welche Botschaften sollen transportiert werden? Welche Kampagnen laufen parallel? Welche SEO-Ziele gibt es?

Wichtig dabei: Marketing sollte die Content-Strategie verantworten, nicht das Design. Zu oft erlebe ich, dass die Marketingabteilung zum internen Design-Review wird und über Schriftgrößen und Weißraum diskutiert, statt über Botschaften und Nutzerführung. Das ist nicht ihre Kernkompetenz und führt zu Designentscheidungen, die weder datengetrieben noch nutzerzentriert sind.

Der Vertrieb hat wertvolles Wissen über Kundenbedürfnisse und Einwände. Dieses Wissen brauchen Sie für die Konzeption der Produktseiten, der Case Studies und der Lead-Generierung. Aber der Vertrieb muss nicht über die Farbpalette abstimmen. Holen Sie den Vertrieb für zwei bis drei fokussierte Workshops in der Konzeptphase ins Boot. Lassen Sie die Kolleginnen und Kollegen erzählen, welche Fragen Kunden am häufigsten stellen, welche Einwände kommen, welche Informationen auf der Website fehlen. Das ist Gold wert. Aber danach braucht der Vertrieb nur noch informiert zu werden, nicht konsultiert.

Die Geschäftsführung braucht zwei Touchpoints. Am Anfang: Freigabe der strategischen Ausrichtung, des Budgets und der Kernbotschaften. Und vor dem Launch: eine Präsentation des fertigen Ergebnisses. Dazwischen sollte die Geschäftsführung bewusst herausgehalten werden. Nicht aus Respektlosigkeit, sondern weil operative Eingriffe auf höchster Ebene die teuersten Änderungen verursachen.

Das muss man der Geschäftsführung auch genau so kommunizieren. Die meisten Geschäftsführer, die ich kenne, sind dankbar, wenn man ihnen sagt: "Sie müssen sich um die Details nicht kümmern. Wir präsentieren Ihnen in acht Wochen das Ergebnis." Das spart ihnen Zeit und dem Projekt Nerven.

Es gibt eine weit verbreitete Überzeugung in vielen Unternehmen: Wenn wir alle abholen, fühlt sich niemand übergangen, und das Ergebnis wird besser. Das Gegenteil ist der Fall.

Wenn jeder mitreden darf, redet niemand Klartext. Entscheidungen werden verwässert, bis sie niemanden mehr wehtun — und auch niemandem mehr nutzen. Die Startseite wird zum Kompromiss aus zwölf Abteilungswünschen und spricht am Ende keine einzige Zielgruppe an. Das Navigationssystem wird so tief, weil jede Abteilung ihren eigenen Bereich fordert, dass kein Nutzer mehr findet, was er sucht.

Ich sage meinen Kunden oft einen Satz, der zunächst provoziert: "Ihre Website ist kein Organigramm." Die Struktur einer Website sollte sich an den Bedürfnissen der Nutzer orientieren, nicht an der internen Organisationsstruktur des Unternehmens. Aber genau das passiert, wenn jede Abteilung gleichberechtigt mitentscheidet.

Die Homepage ist besonders umkämpftes Territorium. Jede Abteilung will dort präsent sein. Marketing will den neuesten Content, Vertrieb die Top-Produkte, HR die offenen Stellen, die Geschäftsführung ein Statement zur Nachhaltigkeit. Das Ergebnis ist eine überladene Seite, die versucht, es allen recht zu machen und dabei allen schadet. Die Absprungrate steigt, die Conversion sinkt, und niemand versteht, warum.

In der Softwareentwicklung gibt es die Rolle des Product Owners. Eine Person, die die Vision des Produkts verantwortet, Anforderungen priorisiert und Entscheidungen trifft. Diese Rolle fehlt in den meisten Webprojekten mittelständischer Unternehmen komplett.

Stattdessen wird das Projekt "nebenbei" von jemandem aus dem Marketing betreut, der gleichzeitig noch drei Kampagnen, den Messeauftritt und den Newsletter verantwortet. Diese Person hat weder die Zeit noch die Autorität, echte Entscheidungen zu treffen. Wenn es Konflikte gibt — und es gibt immer Konflikte — eskaliert alles zur Geschäftsführung. Die hat keine Zeit, beschäftigt sich zwei Wochen nicht damit, und das Projekt steht still.

Die Lösung ist einfach, aber unbequem: Benennen Sie einen dedizierten Product Owner für das Webprojekt. Diese Person braucht mindestens 50 Prozent ihrer Arbeitszeit für das Projekt. Sie braucht die Autorität, operative Entscheidungen zu treffen, ohne jedes Mal die Geschäftsführung fragen zu müssen. Und sie braucht das Vertrauen aller Abteilungen.

Ja, das kostet. Eine Person für sechs Monate zu 50 Prozent aus dem Tagesgeschäft herauszuziehen, ist ein Investment. Aber die Alternative — ein Projekt, das sich über 18 Monate zieht, weil niemand entscheidet — kostet mehr. Deutlich mehr.

Review-Sessions sind der Moment, in dem Stakeholder den aktuellen Stand des Projekts sehen. Richtig aufgesetzt sind sie ein mächtiges Werkzeug, um Alignment herzustellen und Blockaden frühzeitig zu erkennen. Falsch aufgesetzt werden sie zur Bühne für Endlosdiskussionen.

Eine gute Review-Session dauert maximal 60 Minuten. Sie hat eine klare Agenda, die vorab verschickt wird. Sie beginnt mit einer kurzen Einordnung: Wo stehen wir im Projekt? Was wurde seit der letzten Review umgesetzt? Was sind die nächsten Schritte? Dann folgt die Präsentation der Ergebnisse — live im Browser, nicht in PowerPoint-Slides. Stakeholder müssen die Website im echten Kontext sehen, nicht als statische Mockups.

Entscheidend ist die Moderation. Feedback muss kategorisiert werden: Ist es ein Bug? Eine Änderung am Inhalt? Ein Designwunsch? Oder eine strategische Richtungsänderung? Jede Kategorie hat einen anderen Prozess. Bugs werden sofort aufgenommen. Inhaltsänderungen gehen an den Content-Verantwortlichen. Designwünsche werden geprüft und priorisiert. Strategische Richtungsänderungen erfordern eine separate Diskussion mit dem Product Owner und gegebenenfalls der Geschäftsführung.

Was nicht passieren darf: Dass in einer Review-Session eine strategische Grundsatzentscheidung gefällt wird, die den bisherigen Projektplan über den Haufen wirft. Dafür gibt es Change Requests. Formalisiert, mit Aufwandsschätzung und Auswirkungsanalyse. Nicht als spontaner Einwurf zwischen Folie acht und neun.

Lassen Sie mich ein konkretes Beispiel erzählen. Ein mittelständisches Maschinenbauunternehmen mit 400 Mitarbeitern wollte seinen Webauftritt neu gestalten. Das Projekt startete vielversprechend: klarer Zeitplan, definiertes Budget, motiviertes Team. Dann kam die Startseite.

Fünf Abteilungen meldeten Ansprüche an. Marketing wollte einen Hero-Bereich mit der aktuellen Kampagne. Vertrieb bestand auf einem Produktüberblick mit direkten Kontaktmöglichkeiten. HR brauchte eine prominente Verlinkung zu den offenen Stellen, weil der Fachkräftemangel drückte. Die Geschäftsführung wollte ein Statement zur Digitalisierungsstrategie platzieren. Und der Bereich Service forderte einen schnellen Zugang zum Kundenportal.

Alle Wünsche gleichzeitig auf eine Startseite zu packen, hätte eine unlesbare, überladene Seite ergeben. Wir haben stattdessen mit dem Product Owner eine datenbasierte Entscheidung getroffen. Wir analysierten die bestehende Website: 68 Prozent der Besucher kamen über Produktsuchen. 22 Prozent waren Bestandskunden, die das Portal suchten. Der Rest verteilte sich auf Karriere und allgemeine Informationen.

Die Startseite wurde entsprechend priorisiert: Produktzugang und Kundenportal-Login dominierten. Marketing bekam einen rotierenden Bereich unterhalb des Folds. HR erhielt eine dezente Verlinkung in der Navigation. Das Statement der Geschäftsführung wanderte auf die Über-uns-Seite, wo es hingehört. Nicht jeder war begeistert. Aber jeder verstand die Argumentation. Weil sie auf Daten basierte, nicht auf Meinungen.

Der größte Fehler, den ich bei der Stakeholder-Einbindung sehe, ist der Versuch, es allen recht zu machen. Harmonie ist kein Projektziel. Fortschritt ist ein Projektziel. Und Fortschritt erfordert manchmal unbequeme Entscheidungen.

Was Sie brauchen, sind Strukturen. Klare Rollen und Verantwortlichkeiten, dokumentiert in einer RACI-Matrix. Definierte Feedback-Fenster mit Verfallsdaten. Ein Product Owner mit echtem Mandat. Review-Sessions mit Agenda und Moderation. Und den Mut, Nein zu sagen, wenn ein Wunsch das Projekt gefährdet.

Als Agentur übernehmen wir diese Moderation oft selbst. Nicht weil unsere Kunden das nicht könnten, sondern weil es intern manchmal leichter fällt, wenn ein Externer die unbequemen Wahrheiten ausspricht. "Die Geschäftsführung sollte bei der Buttonfarbe nicht mitreden" klingt aus dem Mund des eigenen Marketingteams nach Insubordination. Aus dem Mund der beauftragten Agentur klingt es nach professioneller Empfehlung.

Aus unseren Projekten hat sich ein Ablauf herauskristallisiert, der die meisten Stakeholder-Probleme im Keim erstickt. In Woche eins und zwei findet der Kickoff statt, inklusive Stakeholder-Mapping und RACI-Definition. Alle relevanten Personen kommen einmal zusammen, lernen das Projektteam kennen und verstehen ihre Rolle. Danach arbeiten wir in Zwei-Wochen-Sprints mit dem Product Owner und dem Kernteam.

Alle vier Wochen gibt es eine Review-Session für den erweiterten Stakeholder-Kreis. Diese Sessions sind gut vorbereitet, zeitlich begrenzt und enden mit dokumentierten Entscheidungen. Zwischen den Sessions gibt es keine Ad-hoc-Feedbackschleifen. Wenn jemandem etwas auffällt, wird es für die nächste Review notiert — nicht sofort als dringend eskaliert.

Vier Wochen vor dem Launch gibt es eine finale Abnahmerunde. Hier sieht die Geschäftsführung das Ergebnis. Zu diesem Zeitpunkt sind nur noch minimale Anpassungen möglich — keine strukturellen Änderungen. Das wird vorher kommuniziert. Wer sich daran nicht hält, gefährdet den Zeitplan, und die Konsequenzen sind transparent.

Klingt streng? Ist es. Aber diese Strenge ist Respekt. Respekt vor der Zeit aller Beteiligten. Respekt vor dem Budget. Und Respekt vor dem Ergebnis, das am Ende stehen soll: eine Website, die funktioniert. Für die Nutzer, nicht für die internen Befindlichkeiten.

Webprojekte im Mittelstand scheitern nicht an React oder an der Server-Konfiguration. Sie scheitern an der Frage, wer wann was entscheiden darf. Beantworten Sie diese Frage am Anfang des Projekts — schriftlich, verbindlich, mit Konsequenzen. Dann haben Sie die wichtigste Voraussetzung für ein erfolgreiches Projekt geschaffen. Alles andere ist Handwerk.