Intranets sind keine IT-Projekte – aber was sind die denn dann?

Veröffentlicht am Mai 11, 2014 by Stephan Schillerwein

Es gab eine Zeit, in der es allgemein akzeptiert war, dass es sich bei einem Intranet um ein IT-Projekt handelt. Intranet Manager vom Gegenteil zu überzeugen erforderte damals umfangreiche Argumentationen. Bei Vertretern von IT-Abteilungen fruchteten selbst diese meist wenig.
Mittlerweile hat sich das Blatt glücklicherweise gewendet und man kann sich stets eines eifrig nickenden Publikums sicher sein, wenn man den Satz „ein Intranet ist kein IT-Vorhaben“ in seine Präsentation einbaut.
Eine positive Entwicklung!

Halt, fehlt hier nicht etwas Entscheidendes?

Wie aber wird das entstehende Vakuum nun gefüllt? Interessanterweise folgt nämlich auf diese Feststellung – was das Intranet nicht ist – in der Regel keine Erklärung, um was für eine Art Projekt es sich denn dann handelt.
Ich möchte das nicht falsch verstanden wissen: es geht mir (wieder einmal) nicht um theoretische Definitionen. Ganz im Gegenteil, es stellen sich mir zwei ganz konkrete, praktische und aus meiner Sicht für den Erfolg eines Intranet-Projekts hoch relevante Fragen aus dieser Feststellung:
 

• Führt die Erkenntnis, dass ein Intranet kein IT-Projekt ist – und man sollte das durchaus als eine fundamentale Veränderung mit erheblichen Auswirkungen ansehen – in der Praxis tatsächlich dazu, dass solche Projekte eine grundsätzlich andere Vorgehensweise aufweisen?
• Führt diese Erkenntnis auch dazu, dass verstärkt nicht-IT bezogene Konzepte und Umsetzungen in solchen Projekten angegangen werden?

Aufgrund meiner eigenen Beobachtungen und aus Gesprächen mit vielen Unternehmen lautet für mich die Antwort auf beide Fragen: nein, es hat sich praktisch nichts verändert!
 

Nach dem Paradigmenwechsel: alles beim Alten

Die neuen „Nicht-IT Intranet-Projekte“ haben nach wie vor einen einzigen Inhalt: das Realisieren eines IT-Instruments namens Intranet. Selbstverständlich werden „User“ und „Business“ dabei viel stärker einbezogen als früher, aber an dem Umstand, dass das Intranet aller Rhetorik zum Trotz in seinem Kern letztlich ein technisches Umsetzungsprojekt geblieben ist, hat sich wenig verändert.
Das offenbart sich unmissverständlich auch beim Blick in den Projektplan: nach Analyse, Strategie (soweit überhaupt vorhanden) und Konzeption folgt ein grosses Kästchen mit dem Titel „Technische Umsetzung“. Alle vorgehenden Schritte dienen dabei fast ausschliesslich diesem alles entscheidenden Arbeitspaket. Die Umsetzung ist es dann auch, die den ersehnten Launch herbeiführt. Andere „Lieferobjekte“ (also weitere konkrete Ergebnisse eines solchen Projekts) sucht man vergeblich.
Fassen wir zusammen: wir führen also Projekte durch, die Namen wie „Intranet-Relaunch“ haben, deren konzeptionelle Arbeitspakten weitestgehend der technischen Umsetzung eines Tools dienen, damit dieses IT-System dann gelauncht werden kann, um den User und das Business besser durch digitale Technologien zu unterstützen.
Ja, das hört sich für mich sehr nach einem „Nicht-IT Projekt“ an …
Der Grund warum ich diese Betrachtung absichtlich etwas überspitze ist ein sehr einfacher: solange wir nur bei der leeren Aussage bleiben, dass ein Intranet kein IT-Projekt ist, aber nicht dementsprechend handeln, werden die meisten Intranets nach wie vor an schier unüberwindbare Grenzen stossen.
 

Intranets sind Organisationsprojekte – und noch vieles andere mehr

Als ersten Schritt sollte auf die Erkenntnis, was Intranet-Projekte nicht sind, deshalb das Verständnis folgen, was sie denn nun wirklich sind. Und das ist in der Tat alles andere als einfach, denn ein Intranet – wenn es richtig verstanden wird – lässt sich aufgrund seiner Vielschichtigkeit nicht einfach in einer der konventionellen Schubladen einordnen. Kommunikationsprojekt? Ja, aber nur das greift viel zu kurz. Informationsmanagement Projekt? Auch, aber nicht nur. Die Liste liesse sich fortsetzen…
Organisationsprojekt trifft es aufgrund der Breite des Begriffs ganz gut. Aber auch hier fangen die Schwierigkeiten wieder an: wie viele Menschen denken dabei als erstes an Kostensenkungsmassnahmen, an „Process Reengineering“ oder eine der ungezählten anderen Initiativen, die sicher auch ihr Unternehmen schon durchgeführt hat und deren Auswirkungen sich – um es diplomatisch auszudrücken – meist in Grenzen hielten.
Ich gebe es unumwunden zu: ich kenne keinen Begriff, der es wirklich treffend und unmissverständlich beschreiben würde, was ein Intranet-Projekt denn nun wirklich ist. Aber wenn wir es wie folgt ausdrücken, kommt es dem ganzen doch recht nahe:

Intranets sind Organisationsprojekte zur Weiterentwicklung von kollaborativer Wissensarbeit

Der Perspektivenwechsel: erst das Problem, dann die Lösung

Dieses gemeinsame Verständnis ist jedoch kein Selbstzweck, sondern Fundament für den zweiten, viel wichtigeren Schritt: der Überarbeitung der Projekte und Projektvorgehensweisen mit denen wir Intranets adressieren (oder besser: mit denen wir kollaborative Wissensarbeit verbessern und im Zuge derer wir aller Wahrscheinlichkeit nach auch das bestehende Intranet ablösen oder weiterentwickeln).
Dazu sind zwei wesentliche Voraussetzungen zu erfüllen:

• Das Projekt muss zunächst unabhängig von einer konkreten Lösung (wie bspw. einem Intranet) untersuchen, was das Unternehmen und seine Mitarbeiter überhaupt brauchen. Wenn das Ergebnis ist, dass es unter anderem auch ein neues Intranet braucht: fein. Ansonsten widmen sie ihre Energie lieber den Dingen, die wirklich aktuell gebraucht werden.
• Das Projekt muss von vorneherein berücksichtigen, dass eine technische Umsetzung nur ein Umsetzungsbaustein von mehreren ist. Die „organisatorische Umsetzung“ und die „kulturelle Umsetzung“ (also die Herbeiführung von Veränderungen und Weiterentwicklungen auf nicht-technischer Ebene) sind mindestens als gleichwertige Schritte vorzusehen. Wenn die technische Umsetzung 80% des Budgets und der personellen Projektressourcen verschlingt, kann von gleichwertig sicher keine Rede sein.

Das Intranet ist das Mittel, nicht der Zweck

Bei der nur scheinbar trivialen Erkenntnis, dass ein Intranet kein IT-Projekt ist, geht es also letztlich darum, nicht nur technologie-fokussierte Vorgehensweisen abzulegen, sondern auch solche Vorgehen, die „Solutioneering“ betreiben (die also die Lösung selber als eigentlichen Zweck betrachten und somit keinen echten Bezug zu real existierenden Problemen und Potentialen aufweisen).
Für ein Intranet-Projekt bedeutet das ganz konkret zwei Veränderungen gegenüber bisherigen Vorgehensweisen:

1. Es braucht zwingend ein Vor-Projekt, in dem festgestellt werden kann, was überhaupt benötigt wird und wie somit auch die strategische Ausrichtung des Projekts gestaltet werden soll (vgl. Phase „Pre-Project“ in nachstehender Abbildung). Neben vielen anderen Dingen kommt dabei vielleicht auch zum Vorschein, dass ein „Intranet Redesign“ (o.ä.) gar nicht der Kern des Projekts sein sollte, sondern nur ein Bestandteil von mehreren (und man deshalb vielleicht auch einen anderen Namen für das Projekt benötigt).
2. Die Umsetzungsphase sollte von Anfang an neben einem Stream zur technischen Umsetzung und einem Stream zur inhaltlichen Umsetzung auch einen Stream zur organisatorischen Umsetzung enthalten (vgl. Phase 3 in nachstehender Abbildung). Dieser Umstand sollte sich natürlich auch in der Projektorganisation (z.B. ein eigenes Team/Teilprojekt für „Adoption, Change & Organisation), der Mittelverteilung und der Zeitplanung niederschlagen.

Projektstrukturplan für ein echtes „Nicht-IT Intranet-Projekt“

Bevor Sie sich also in das nächste Intranet-Projekt stürzen: überdenken Sie ihre Vorgehensweise und stellen Sie sicher, dass diese dem Umstand, dass Intranets in der Tat keine IT-Projekte sind, auch gebührend Rechnung trägt.