Intranet-Projektumsetzung: agil, Wasserfall und MVP
Die Einführung eines Intranets ist selten nur ein technisches Projekt. Teams müssen Umfang, Entscheidungswege, Inhaltsmigration, Integrationen, Tests und den eigentlichen Launch planen. Deshalb ist die Wahl zwischen agilem Vorgehen und Wasserfall wichtig, sollte aber nie die Diskussion über Risiken, Phasen und den ersten echten Nutzen für Mitarbeitende ersetzen.
Ein guter Umsetzungsansatz hilft, eine nützliche erste Version zu veröffentlichen, ohne so zu tun, als ließe sich alles am Anfang vorhersagen. In der Praxis funktioniert oft ein hybrides Modell: zuerst klare Grenzen und verpflichtende Anforderungen, danach kurze Iterationen rund um die Arbeitsabläufe der Mitarbeitenden.
In diesem Artikel:
- Was entscheiden Sie wirklich zwischen agil und Wasserfall?
- Welcher Ansatz passt zu Ihren Einschränkungen?
- Was gehört in ein Intranet-MVP?
- Wie lässt sich die Einführung phasenweise planen?
- Welche Gates sollten den Launch blockieren?
- Wie sammelt man Feedback nach dem Start?
- Wie vermeidet man Scope Creep?
- Womit sollte der Umsetzungsplan beginnen?
Was entscheiden Sie wirklich zwischen agil und Wasserfall?
Agil und Wasserfall beschreiben die Arbeitsweise, aber nicht automatisch die Release-Strategie. Agil bedeutet nicht, dass jedes Sprint-Ergebnis sofort produktiv gehen muss. Wasserfall bedeutet nicht, dass das gesamte Intranet mit allen Funktionen an einem einzigen Tag starten muss.
Trennen Sie im Intranet-Projekt drei Entscheidungen:
| Entscheidung | Frage | Beispiel |
|---|---|---|
| Arbeitsmethode | Wie plant, baut und akzeptiert das Team Arbeit? | Sprints mit Nutzertests oder ein sequenzieller Plan mit formalen Abnahmen. |
| Release-Strategie | Wann erreichen Funktionen die Mitarbeitenden? | Ein Launch für die ganze Organisation oder Phasen nach Abteilungen, Ländern oder Funktionen. |
| MVP-Umfang | Was muss fertig sein, damit die erste Gruppe sinnvoll arbeiten kann? | Startseite, Nachrichten, Dokumentenbibliothek, Suche und grundlegende Redaktionsrollen. |
Agil ist besonders hilfreich, wenn noch unklar ist, wie Mitarbeitende Informationen suchen, welche Begriffe sie verstehen oder welche Wege wirklich wichtig sind. Kurze Zyklen ermöglichen Tests von Navigation, Startseite, Formularen und Veröffentlichungsprozessen.
Wasserfall kann passen, wenn Anforderungen stabil sind und Freigaben in einer festen Reihenfolge durch Security, Legal, IT und Einkauf laufen müssen. Auch dann sind frühe Tests mit Mitarbeitenden sinnvoll, denn eine genehmigte Spezifikation beweist nicht, dass das Intranet einfach zu nutzen ist.
Welcher Ansatz passt zu Ihren Einschränkungen?
Wählen Sie den Ansatz nach Unsicherheit und Entscheidungskapazität, nicht nach dem Etikett, das Stakeholder bevorzugen.
Beantworten Sie vor dem Plan diese Fragen:
- Sind die Anforderungen stabil oder noch Hypothesen über das Verhalten von Mitarbeitenden?
- Gibt es ein festes Launch-Datum und welches Geschäftsereignis steht dahinter?
- Können repräsentative Mitarbeitende Zwischenstände testen?
- Darf ein Product Owner regelmäßig Prioritäten und Umfang entscheiden?
- Welche Freigaben müssen nacheinander erfolgen?
- Welche Abhängigkeiten liegen außerhalb der Kontrolle des Projektteams, etwa SSO, HR-Daten, Integrationsrechte oder Testumgebungen?
Wenn vieles unsicher ist, starten Sie mit einem hybriden Modell. Legen Sie Budget, Sicherheitsgrenzen, Abhängigkeiten und Release-Gates fest. Bauen und prüfen Sie danach die wichtigsten Aufgaben der Mitarbeitenden in kurzen Iterationen.
Bei einem festen Launch-Datum muss früh klar sein, welcher Umfang beweglich ist. Zusätzliche Workflows, Personalisierung oder sekundäre Inhaltsbereiche können warten. Sicherheit, Barrierefreiheit und Betrieb für die erste Nutzergruppe sollten dagegen Launch-Bedingungen bleiben.
Was gehört in ein Intranet-MVP?
Ein Intranet-MVP ist die kleinste nutzbare Version, die einer klar definierten Mitarbeitergruppe hilft, wichtige Aufgaben zu erledigen und Belege für das nächste Release liefert. Es ist nicht die Liste aller Funktionen, die die Organisation irgendwann haben möchte.
Ein gutes MVP beschreibt:
- die erste Zielgruppe, zum Beispiel ein Land, eine Abteilung oder die Zentrale,
- die Aufgaben, die diese Gruppe am ersten Tag erledigen muss,
- Inhalte und Inhaltseigentümer für diese Aufgaben,
- minimale redaktionelle Rollen und den Veröffentlichungsprozess,
- Anmeldung und grundlegende Berechtigungen,
- Akzeptanzkriterien und den Weg zur Problemmeldung.
Ein erstes Release kann Nachrichten, eine Richtlinienbibliothek, Suche, Bereichsseiten und zentrale HR-Inhalte enthalten. Vollständige Personalisierung, komplexe Kommunikationskampagnen oder alle Integrationen können später folgen.
Entscheidend ist, dass Mitarbeitende echte Arbeit erledigen können. Wenn das Intranet nur fertig aussieht, aber keine freigegebenen Inhalte, keine funktionierenden Berechtigungen und keinen Support-Prozess hat, ist das MVP nicht startbereit.
Wie lässt sich die Einführung phasenweise planen?
Phasen sollten Risiken reduzieren und verwertbares Feedback erzeugen. Teilen Sie das Projekt nicht nur nach technischen Modulen, wenn Mitarbeitende mit dem Ergebnis noch nichts anfangen können.
Ein praktischer Ablauf kann so aussehen:
- Discovery und Grundentscheidungen. Probleme der Mitarbeitenden, Intranet Owner, verpflichtende Anforderungen und externe Abhängigkeiten festlegen.
- MVP und Informationsarchitektur. Navigation, erste Inhaltstypen, Redaktionsrollen und Grundlayout bauen.
- Inhalte und Migration. Inhalte für das erste Release auswählen, Eigentümer klären, Dubletten entfernen und wichtige Seiten freigeben.
- Integrationen und Zugriff. SSO, Datenquellen, Berechtigungen und Sicherheitstests konfigurieren.
- Pilot. Das Intranet einer begrenzten Gruppe geben, Probleme sammeln und prüfen, ob Aufgaben lösbar sind.
- Launch und Stabilisierung. Für die ausgewählte Gruppe oder Organisation starten, Support beobachten und kritische Hindernisse beheben.
- Weitere Releases. Funktionen anhand von Belegen hinzufügen, nicht nur anhand einer Wunschliste.
Jede Phase braucht einen Owner, ein Ergebnis, Akzeptanzkriterien und eine Entscheidung, was passiert, wenn etwas nicht bereit ist.
Welche Gates sollten den Launch blockieren?
Release-Gates sind nötig, weil ein Intranet viele Teile der Organisation berührt. Der Start sollte nicht nur davon abhängen, ob der Build erfolgreich war.
Prüfen Sie vor dem Launch mindestens:
- Anmeldung und Abmeldung für repräsentative Nutzergruppen,
- Rollen und Berechtigungen für vertrauliche Inhalte,
- Suche nach den wichtigsten Dokumenten,
- Barrierefreiheit und mobile Nutzung zentraler Seiten,
- Qualität und Aktualität der Startinhalte,
- Inhaltseigentümer und Veröffentlichungsregeln,
- Support-Prozess und Verantwortlichkeiten,
- Backup, Monitoring und Notfallplan,
- wer Launch oder Rollback freigeben darf.
Nicht jedes Problem muss das Release blockieren. Ein Tippfehler auf einer Nebenunterseite kann in die Nacharbeitsliste. Ein Berechtigungsfehler, fehlender Support-Prozess oder unauffindbare Pflichtinformationen sollten den Start für die betroffene Gruppe stoppen.
Wie sammelt man Feedback nach dem Start?
Fragen Sie nach dem Launch nicht nur, ob den Mitarbeitenden das Intranet gefällt. Fragen Sie, ob sie konkrete Aufgaben erledigen können.
Kombinieren Sie mehrere Quellen:
- Supportfälle und ihre Ursachen,
- Suchanfragen ohne Ergebnis,
- Klickpfade zu wichtigen Aufgaben,
- Fragen an Redaktion und HR,
- kurze Gespräche mit Mitarbeitenden,
- Beobachtungen aus Pilot und ersten Produktionswochen.
Machen Sie aus Beobachtungen kleine Entscheidungen. Wenn Mitarbeitende die Urlaubsrichtlinie nicht finden, kann das Problem am Namen, an der Position im Menü, an der Suche oder an fehlenden aktuellen Inhalten liegen. Jede Hypothese führt zu einer anderen Änderung.
Führen Sie eine gemeinsame Arbeitsliste für Fehler, Nutzerbedürfnisse und technische Aufgaben. So entwickelt das Team nicht neue Funktionen auf Kosten der Stabilität und verschiebt Wartung nicht so lange, bis sie das nächste Release blockiert.
Wie vermeidet man Scope Creep?
Scope Creep beginnt oft mit guten Absichten. Jede Abteilung hat wichtige Anforderungen, und das Intranet wirkt wie der Ort, an dem man sie lösen kann. Ohne Regeln wird das erste Release zu groß.
Drei Fragen helfen:
- Braucht die erste Nutzergruppe diese Funktion für die Startaufgaben?
- Blockiert das Fehlen der Funktion den Launch oder reduziert es nur Komfort?
- Haben wir Eigentümer, Prozess und Daten, um die Funktion nach dem Launch zu betreiben?
Verschieben Sie Funktionen bewusst. Notieren Sie Grund, Rückkehrbedingung und Entscheidungsowner. Das ist besser als ein allgemeines „später“, das nach einigen Wochen zu Streit über Erwartungen wird.
Ein MVP sollte klein, aber für sein Ziel vollständig sein. Wenn Sie etwas aus dem Launch entfernen, prüfen Sie, ob der verbleibende Umfang den Mitarbeitenden weiterhin einen funktionierenden Weg bietet.
Womit sollte der Umsetzungsplan beginnen?
Beginnen Sie mit der ersten Nutzergruppe und ihren wichtigsten Aufgaben. Benennen Sie danach verpflichtende Anforderungen, externe Abhängigkeiten, Entscheidungsowner und Release-Gates.
Erst dann wählen Sie die Arbeitsmethode. Agil, Wasserfall oder Hybrid sollten das Projektrisiko unterstützen, nicht Selbstzweck sein.
Wenn Sie eine Open-Intranet-Einführung planen, sprechen Sie mit Droptica über MVP-Grenzen, Abhängigkeiten und Launch-Gates. Klären Sie zuerst, wem das erste Release dient, was diese Mitarbeitenden tun können müssen und welche Belege zeigen, dass das Intranet startbereit ist.
