Abschied vom Silodenken: Erlaubnis zum Experimentieren

Projekte sind in unseren Organisation oft Gegenstand heftigen Gezerres und Geschiebes. Wer hat Recht mit seiner Meinung? Wer setzt sich durch mit seinen Interessen? So werden Projekte verzögert, und auch ihre Ergebnisqualität erreicht nicht das Optimum.
Die Ursache für Meinungsstreit liegt oft in Silodenken und Einzelkämpferkultur. Gelingt es, sich davon zu lösen, werden Projekte entspannter und die Ergebnisse besser.

Ein Projekt kommt ins Stocken

Auf einmal ist der Streit da. Bislang waren die gemeinsamen Sitzungen zwischen Steering Committee und Projektgruppe immer ganz harmonisch verlaufen. Das Lastenheft war schon verabschiedet. Und jetzt erfährt Herr Striebel, der Projektleiter, dass Frau Krumbiegel in einer Besprechung beim CIO „ganz nebenbei“ das ganze bisherige Projektergebnis für unzureichend erklärt hat. Herr Striebel war selbst nicht dabei, aber Frau Hahnenkamp hat es ihm brühwarm erzählt.

Was ist passiert?

Beim Projekt geht es um die Einführung einer neuen Dokumentenmanagement-Software (Stichwort „digital disruption“) in der Coramag AG, die Industriehallen erstellt, und Frau Krumbiegel ist die HR-Chefin. Die HR hat die Software AlonSa für die Gehaltsabrechnung im Einsatz. Und als deren Herstellervertreter vom DMS-Projekt bei der Coramag erfuhr, kam er ganz zufällig bei Frau Krumbiegel vorbei: sie hätten doch auch eine digitale Personalakte, und die sei doch viel mehr auf ihre Bedürfnisse als Personalerin zugeschnitten als jedes DMS. „DMS-Software ist viel zu unspezifisch“, erklärte der Vertreter, „die Hersteller haben keine Ahnung von Personalprozessen.“

Frau Krumbiegel war begeistert von der AlonSa-Lösung. Aber im DMS-Lastenheft stand etwas anderes drin. Also sah sie keine andere Möglichkeit, als die Notbremse zu ziehen und das DMS-Projekt beim CIO anzuschwärzen. Der stimmte ihr erstmal zu: die Bedürfnisse der HR dürfen beim Projekt keinesfalls übergangen werden!

Und die schon vereinbarten DMS-Präsentationen mit ausgewählten DMS-Herstellern wurden bis aufs Weitere verschoben.

„Ich glaube, ich habe Ihre Kompetenz überschätzt“

Herr Striebel als Projektleiter sah nun seine Felle davonschwimmen. Bei der Krisensitzung mit dem Steering Committee beharrte er darauf, sie hätten das Lastenheft verabschiedet und das könne man nicht einfach umwerfen. Außerdem werde nun die Grundphilosophie des Projekts „kein Flickenteppich!“ wieder völlig in Frage gestellt.

Aber Frau Krumbiegel schonte ihn nicht. Er hätte das Problem der Schnittstelle zwischen AlonSa und dem künftigen DMS überhaupt nicht genau geprüft. AlonSa sei eine Spitzenlösung für ihren Bereich. Sie sei dagegen, dass die DMS-Hersteller ihre Personalmodule überhaupt bei den Präsentationen zeigten: das sei verschwendete Zeit. Und ihre kleine Ansprache gipfelte dann im Satz: „Herr Striebel, ich glaube, ich habe Ihre Kompetenz als Projektleiter kräftig überschätzt.“

Jedes Mitglied der Projektgruppe versucht, sein Eigeninteresse zu sichern.

Machen wir an dieser Stelle einen Stopp. Klar ist, dass das Projekt in stürmisches Fahrwasser geraten ist, so dass vielleicht sogar sein Erfolg in Frage steht. Gibt es strukturelle Ursachen für diesen Konflikt? Welche andere Herangehensweise wäre „agil“?

Agil heißt: Differenzen fruchtbar machen

Auf der Ebene der Methoden bedeutet Agilität: Mut zum Experiment. Im konkreten Fall: Was würde dagegen sprechen, auch den AlonSa-Hersteller zu einer Präsentation vor der gesamten Projektgruppe einzuladen und speziell seinen Ansatz für eine EPersonalakte mit den Lösungen der DMS-Produkte zu vergleichen?

Vielleicht gibt es noch eine weitergehende Möglichkeit. Man lässt das beste DMS und AlonSa zwei Wochen lang nach festgelegtem Testplan von Mitarbeitern der Personalabteilung testen und auch von Mitarbeitern anderer Ämter, die auf Personaldaten nur zugreifen müssen.

Denn eigentlich müsste Herr Striebel sich ja freuen, wenn Frau Krumbiegel noch eine Alternativlösung in ihrem Bereich ausfindig gemacht hat. Das kann die Gesamtlösung nur verbessern. Und es spornt vielleicht den einen oder anderen DMS-Anbieter an, aus seinem System eine optimale Personallösung herauszukitzeln.

Agilität bedingt Kulturänderung

In diesem Sinne sind Differenzen sehr oft etwas Positives, weil sie eine Vielfältigkeit der Interessen und Sichtweisen darstellen, die den Ideen- und Lösungsraum erweitern. Um das aber nutzen zu können, bedarf es kultureller Änderungen:

1. Die Coramag AG hat eine ausgeprägte Einzelkämpferkultur bei ihren Führungskräften. Frau Krumbiegel und Herr Striebel haben nur eines gelernt: Sorg für dich selbst, sonst tut es keiner. Sie sehen den Projekterfolg nicht von der Warte des Gesamtunternehmens.
2. Einzelkämpferkulturen und Silodenken treffen sich oft. "Das ist meine Abteilung, die ich auf Vordermann bringe und von der ich Loyalität fordere", ist eine häufige Haltung bei mittleren Führungskräften in solchen Organisationen. 
3. Einzelkämpferkulturen gehen mit erhöhter Selbstbewertung (und Abwertung anderer) einher: „Ich bin toll (und ihr seid es nicht).“ Verhaltensweisen von anderen gelten immer durch deren persönliche Eigenschaften determiniert: wer Fehler macht, "ist nicht kompetent" usw.
4. Einzelkämpfer halten ihre Meinung immer für richtig. Es gilt nur, sie durchzusetzen, nicht sie zu überprüfen. Sie kämen gar nicht auf die Idee, zu experimentieren.
5. Zur Durchsetzung der sowieso wahren Meinung ist aber auch Strippenziehen erlaubt (mal eine kleine Bemerkung zum CIO).
6. Hinzu kommt eine Verwechslung von Bedarf und Lösungsvorschlag. Frau Krumbiegel hat bestimmte Bedarfe für sich und ihre Abteilung, versteift sich aber gleich auf eine bestimmte Lösung („ich will AlonSa!“). Die agile Methode der Userstorys, bei denen Projektbeteiligte ihre Bedarfe lösungsneutral aufschreiben, beugt dem vor. Ohne Userstorys ist kein Experimentieren möglich. So gleitet man dann schnell in endlose Diskussionsspiralen ab, welche Lösung denn nun ganz grundsätzlich die bessere ist. Denn objektive Kriterien sind nicht definiert.

Siehe auch zum Thema den Post "Messen statt Meinung" http://www.teamworkblog.de/2013/04/messen-statt-meinung-scrum-und-lean.html