Huch, schon so spät? Hätten Sie mal was gesagt! Genau, manchmal muss ich wohl gebremst werden. Und ich verstehe, dass Sie nun endlich auch über das konkrete Vorgehen in Ihrem Projekt sprechen möchten. Doch leider ist deutlich einfacher zu sagen, was man in einem Intranet-Projekt nicht tun sollte, als vorzugeben, was unbedingt in jedem Intranet-Projekt vorkommen muss. Klar, es gibt ein paar Dinge, die trivial sind. Sie benötigen eine Software und alle Mitarbeiter brauchen Zugang. Sie müssen gewährleisten, dass das Ganze sicher ist. Es muss einfach sein, Informationen und Inhalte in das System einzuspielen. So weit, so selbstverständlich.

Was Sie aber garantiert nicht brauchen, ist eine minutiöse Planung des Projektablaufs mit umfangreichen Gantt-Charts und viel Determinismus. Das erlebe ich permanent – und es bringt fast immer sehr wenig bis gar nichts. Freunden Sie und Ihr Projektteam sich lieber mit einem iterativen Vorgehensmodell an. Ein Kunde sagte mal zu meinem Bruder: “Jetzt weiß isch, was Sie mit diesem ‘Agile’ meine: sisch dorschworschtele. Das mache mir hier in Projekte auch immer.”

Was soll ich dazu sagen? Das ist das natürliche Verhalten, das wir als Kinder an den Tag legen und das uns auch später oft den besten Weg weist. Lassen Sie sich nicht erzählen, alles sei planbar. Das ist Quatsch. Einige Sachen sind so simpel und schnell umgesetzt, dass Sie dafür gar keinen Plan brauchen. Andere Dinge sind so komplex, dass jeder Plan nur davon ablenkt, dass hinter der nächsten Ecke die nächste Überraschung wartet, auf die Sie reagieren müssen. 

Seien Sie mit dem Projektteam bereit, Änderungen umzusetzen und zu akzeptieren. Das ist ein wichtiger Schritt.

Ansonsten begegnet mir in großen Unternehmen immer wieder ein unbändiger Hang zur Theorie. Da werden Konzepte geschrieben, Ziele und Wünsche gesammelt und priorisiert. Es werden Anforderungen strukturiert und klassifiziert. Natürlich werden Pflichtenhefte und Projektpläne erstellt. 

Teilweise werden externe Agenturen beauftragt, um die Planung des Projekts zu moderieren und zu organisieren. Nur eine Sache bleibt fast immer außen vor: das tatsächliche Nutzen und Ausprobieren der Software-Systeme.

Das Problem des fehlenden Praxisbezugs ist so ausgeprägt, dass ich versucht bin, Ihnen zu empfehlen, lieber auf die Planung als auf das Testen der Software zu verzichten. Es ist ganz und gar nicht unüblich, dass ein Gremium von bis zu zwanzig Personen gemeinsam über die Anschaffung einer Intranet-Software berät und letztlich auch entscheidet. Und von diesen zwanzig Leuten haben fünfzehn die Software-Systeme, über die sie diskutieren, nicht ernsthaft geprüft. Die meisten haben sich nicht mal irgendwo eingeloggt.

Zugegeben: Viele Anbieter machen es einem nicht gerade leicht, die Software zu testen. Einige stellen gar keine Testumgebungen zur Verfügung, die Sie selbst produktiv nutzen können. Manchmal werden die Zugänge auch erst herausgegeben, nachdem Sie drei Handstände und zwei Hampelmänner geturnt haben. Aber hier geht es ja nicht darum, was andere machen oder wollen, sondern was für Ihr Intranet-Projekt gut ist. Und wenn eine Sache richtig gut ist, dann ist es die Nutzung der Software. Das kann ich auch einfach und eingängig erklären.

Die meisten Unternehmen erhoffen sich durch die Einführung eines Social Intranets Veränderungen im Verhalten der Mitarbeiter. Es geht um die Unternehmenskultur, um das Miteinander, um Transparenz und darum, dass wirklich jeder Bescheid weiß und sich zu Hause und angekommen fühlt. Wenn all das schon da wäre, bräuchten Sie den Aufwand für ein Intranet ja nicht zu betreiben. Etwas soll also anders werden. Aber was genau ist das? Tja, wenn das so klar wäre, hätte Ihre Organisation es bestimmt schon längst umgesetzt. Machen wir uns nichts vor: Die ganze Mannschaft weiß nicht so genau, was sich im Einzelnen ändern soll.

Wir freuen uns immer wieder, wenn Software uns auf subtile und sanfte Weise dabei hilft zu verstehen, wie man etwas anders machen kann. Sie können doch niemandem wirklich erklären, wie Video-Meetings die Zusammenarbeit verändern, wenn Sie bisher nur telefoniert haben.

Wenn in Ihrem Unternehmen also viele Menschen noch nie mit einem erfolgreichen, modernen Social Intranet gearbeitet haben – wie sollen diese Leute dann aufschreiben, wie so ein Intranet zu sein hat? Das wäre sinnlos.

Eine gewisse Gefahr besteht darin, dass einige wenige Personen sich in eine bestimmte Software verlieben und dann aus der Sache nicht mehr herauskommen. Sie kennen sich beispielsweise mit Word, Excel und PowerPoint aus und wollen künftig alle Projekte und beruflichen Lebenslagen mit diesen Software-Werkzeugen bearbeiten. Diese Situation hat den Vorteil, dass sie nichts Neues lernen müssen. Sie schauen die Welt einfach weiter durch ihre eigene Brille an. Und genau das tun Sie, wenn Sie in der reinen Theorie ein Intranet konzipieren und Anforderungen zusammentragen.

Wenn Sie also ein Intranet-Team losschicken, um eine Plattform auszusuchen und um zu evaluieren, was ein Intranet für Ihr Unternehmen erreichen soll, dann sorgen Sie auf jeden Fall dafür, dass das Team aktiv mit den Software-Systemen arbeitet. Nicht nur mit einem. Mit vielen. Und schließlich können Sie ja drei oder fünf Systeme auswählen, die wirklich gut, einfach und überzeugend sind. Mit denen arbeiten Sie dann weiter aktiv.

Bevor Ihr Gremium aus zwanzig Personen eine Entscheidung trifft, sollten all diese Leute wenigstens mal eine halbe Stunde in die letztendlich ausgewählte Software reingeschnuppert haben. Das erleben wir leider so gut wie nie, aber ich halte das für den richtigen und nachhaltigen Weg.

Es ist gar nicht so wichtig, dass Sie ein festes Korsett an Anforderungen definieren und die Tester und Entscheider diese Anforderungen stets präsent haben. Unterschiedliche Systeme setzen unterschiedliche Schwerpunkte. Sich auf diese einzulassen und herauszufinden, wie die entsprechenden Funktionen und Vorteile im eigenen Unternehmen Mehrwert stiften könnten, ist aus meiner Sicht deutlich wertvoller, auch wenn es sich zunächst nicht besonders systematisch und intuitiv anhören mag.

Die meisten Intranet-Teams legen deutlich zu viel Gewicht auf Anforderungslisten und (theoretische) Erfüllungsgrade. Richten Sie den Fokus stattdessen auf die tatsächliche Software-Nutzung! 

Wenn Sie in Ihrem Projekt den Praxisbezug hochschrauben können, ist schon viel gewonnen. Probieren Sie Dinge aus. “Worschteln” Sie sich durch. Lassen Sie sich auf die Spezialitäten der Software ein und versuchen Sie zu erspüren, ob zwischen der Lösung und den Bedürfnissen Ihres Unternehmens ein gemeinsamer Nenner entsteht.

Testen Sie Zusammenarbeits-Software nicht allein. Je mehr Personen beteiligt sind, desto realistischer ist der Test. 

Ich halte es für sehr sinnvoll, einfach mal ein Team oder eine kleine Abteilung mit zehn oder auch fünfzig Personen auf die Software anzusetzen, um sie auszuprobieren. So ein Test kann sich getrost über zwei, vier oder sechs Wochen erstrecken. (Die meisten Anbieter dürften dies kostenfrei ermöglichen.)