Jede große Unternehmung, jedes signifikante Wagnis und so gut wie jedes bahnbrechende Projekt wird von ihnen begleitet: den Bremsern, Zweiflern, Bedenkenträgern, Mahnern und Nachdenkern. Jeder, der in einem Unternehmen mit mehr als fünfzig Leuten arbeitet, kennt sie. Und sie werden Ihnen auch in einem Intranet-Projekt begegnen. Denn ein erfolgreiches Intranet verändert in einer Organisation ziemlich viele Dinge. Davor darf und muss man Respekt und manchmal vielleicht sogar Angst haben.

Die Rolle von Menschen, die solche Herausforderungen aktiv ansprechen, ist relevant und wichtig für ein Projekt. Es ist ein Wert für sich, dass Menschen sich trauen, Risiken anzusprechen und problematische Situationen aufzuzeigen.

Gleichzeitig müssen wir dafür sorgen, dass zarte Pflänzchen (und das sind Ideen und Innovationen am Anfang) Raum bekommen, um zu wachsen und zu gedeihen. Dazu gehören Iterationen und Fehler. Nichts, was revolutionär und wirklich neu ist, funktioniert auf Anhieb und mit perfekter Passung. Die meisten Lösungen müssen zurechtgeruckelt werden, damit sie sich gut in die Organisation einfügen.

Es ist schon lästig genug, wenn ich etwas ausprobiere, von dem ich denke, dass es unsere Welt verändern wird, und dann im Praxistest herausfinde, dass es nicht funktioniert. Das ist frustrierend. Wenn aus meinem Team dann jemand an der Seitenlinie steht und ruft: “Siehste! Habe ich doch gleich gesagt: Das funktioniert nicht. Wir sollten das komplett bleiben lassen!”, ist das weder hilfreich noch konstruktiv.

Wenn Sie Zweifler im Team identifizieren, sorgen Sie dafür, dass sie einen (digitalen) Diskussionsort haben, der vom gesamten Projektteam und auch von externen Stakeholdern des Projekts eingesehen werden kann.

An diesem transparenten Ort sammeln sich die Bedenken, Probleme und Risiken. Die Zweifler sind berechtigt, durch das ganze Unternehmen zu laufen und jedem zu erzählen, für wie problematisch sie diese Dinge halten und so Stimmung zu machen. Das mag den meisten Teams nicht gerade willkommen sein, weil es ja vom eigentlichen Projektplan ablenkt. Aber diese offene Kommunikation ist ein wirksames Ventil für die Probleme und ihre Treiber. Und es ist auch ein Weg, der dem Projektteam zeigt, wie fruchtbar der Boden ist, auf dem in der Organisation Probleme gedeihen können.

Nehmen wir mal an, wir würden gemeinsam ein Projekt durchführen wollen und in eine Testphase eintreten. Ihr Unternehmen ist konservativ und will daher die Intranet-Software in einer gesicherten Infrastruktur sehen. Allerdings hat Ihre IT-Abteilung keine Kapazitäten, um das Hosting und den Betrieb zu übernehmen. Daher ist geplant, dass wir die Plattform in unserem Rechenzentrum betreiben. Wie schön, es kann sofort losgehen! Denken Sie. Aber da kommen die Bedenkenträger. Ist das rechtlich okay? DSGVO und so? Entspricht das unserer Informationssicherheitsrichtlinie? Klappt das mit unseren Geräten? Ist die Bandbreite an unseren Standorten hoch genug? Und so weiter und so fort.

Wir wollen also alle diese Bedenken und Fragen sammeln und transparent verfügbar machen. Wir selbst nutzen dafür intern eine Wiki-Seite. Es kann aber auch eine Tabelle in der Google G Suite oder Office 365 oder einfach eine Seite in Ihrem bestehenden Intranet oder eine Datei auf einem Netzlaufwerk sein.

Einige dieser Probleme können Sie vielleicht nebenbei ausräumen, andere sind wiederum gar nicht auflösbar. Falls nun in den nächsten Wochen zig Personen wegen der Auslagerung der Daten auf Sie zukommen und die Bedenken verstärken, wissen Sie, dass Sie das Thema wohl mit in das Projekt aufnehmen müssen. Wenn stattdessen der Vorstand und der CIO zu Ihnen kommen, Ihnen auf die Schulter klopfen und die Cloud-first-Strategie loben, ist es vermutlich kein so gewichtiges Risiko für das Projekt.

Diese Herangehensweise ist auch für den Bedenkenträger fair, weil es seiner persönlichen Energie überlassen ist, wie viel Zeit und Muße er investiert, um die Sache quer durchs Unternehmen zu eskalieren. Eskaliert er erfolgreich, reagieren Sie. Lädt er einfach nur mal schnell seine Ideen bei Ihnen ab, sollten Sie das nicht zu Ihrer Hauptaufgabe machen.

Geben Sie Bedenkenträgern ein Ventil, um ihre Vorbehalte zu äußern, und dokumentieren Sie diese Vorbehalte für alle öffentlich über einen bestehenden Kanal.

Reagieren Sie aber nur auf die Themen, die Zug haben und mit Kraft von vielen Seiten aus im Projekt aufschlagen. Lassen Sie nicht zu, dass Zweifler und Bedenkenträger zum aktiven Teil der Intranet-Projektgruppe gemacht werden. Wer nichts ausprobieren will und wer Angst vorm Scheitern oder vor einer Blamage hat, ist ein schlechter Scout für die neuen Dinge, die Ihre Arbeitsabläufe verändern können.

Zweifler müssen Sie hören und berechtigte Zweifel behandeln und berücksichtigen. Aber Zweifler sind in aller Regel keine guten Treiber für Innovationen. Sie sollten nicht zum Kernteam für das neue Intranet gehören.