Entwicklungsprojekte in Unternehmen: Eine Frage agiler Führung

Manche Projekte klappen einigermaßen gut, andere ziehen sich wie Kaugummi und man hat ständig das Gefühl: „Bald versandet’s.“ Wo liegt der Unterschied? Auf die Frage gibt es wahrscheinlich nicht nur eine Antwort. Aber zumindest einem Faktor kommen wir auf die Spur, wenn wir fragen: „Wer macht’s?“

Zwei Arten von Projektdynamik

 

Ich begleite bisweilen als externer Berater Projekte der Organisationsentwicklung in Unternehmen und zunehmend auch Verwaltungen. Meist sind es Projekte der Softwareeinführung (DMS/ECM/EIM), die aber keine reine IT-Projekte sind. Denn es geht nicht nur (oder gar nicht mal in erster Linie) um die Einführung von Tools, sondern um ganz neue Formen der Zusammenarbeit der Mitarbeiter.

Der Auftrag solcher Projekte ist also widersprüchlich: von der Unternehmensführung oft rein technische Innovation formuliert und gemeint, treibt diese weiter zu einer sozialen Innovation – anderen Haltungen und Arbeitsweisen und Kommunikationsweisen von Menschen. Es gibt eine agile Lehrmeinung für solche Situationen: „Culture follows structure.“ Also in etwa: „Führe neue Prozesse ein, dann wird sich auch die Unternehmenskultur ändern.“/1/ Aber warum klappt das manchmal und manchmal nicht?

Ich habe Projekte, die gut funktionieren. Und bei anderen Projekten will nichts recht klappen. Wobei der Hauptunterschied zu den gut laufenden Projekten ist: Es will keine richtige Energie aufkommen. Alles schleppt sich, alles ist zäh, es gibt keine sprühenden Ideen, aus (gemeinten) Kreativ-Workshops werden klassische „Besprechungen“ – und irgendwann ist aus dem Projekt die Luft raus.
Wie kommt es zu dem Unterschied? Vor langwierigen Erklärungen will ich als Beispiel ein gut laufendes und ziemlich typisches Projekt bringen.

Jelena nimmt das Heft in die Hand

 

Die Papier und Filter Deutschland GmbH hat DMS eingeführt. Die IT hat ein Produkt gekauft (schon vor drei Jahren), installiert und bislang in drei Abteilungen eingeführt. Jetzt soll ein weiteres Teilprojekt gestartet werden: das Qualitätsmanagement hat gemeinsame Prozesse mit allen drei Pilotabteilungen, in denen QM-Dokumente abgestimmt und verteilt werden. Diese Prozesse sollen ins DMS integriert werden, damit auch die Dokumente im DMS den Anforderungen der Qualitätssicherung genügen.

Die stellvertretende Leiterin des QM, nennen wir sie Jelena, soll sich darum kümmern. Jelena prüft die Lage. Sie schaut, welche Dokumente sich im DMS befinden. Sie stellt fest: fast überhaupt keine. Die drei Abteilungen nutzen das DMS quasi nicht. Sie arbeiten weiter in der gewohnten Windows-Umgebung, weil sie das DMS ungewohnt und umständlich finden und keinen Nutzen für sich sehen. Jelena findet, die Abstimmung nicht existierender Dokumente mit dem QM sei wenig reizvoll.

Sie wendet sich an die DMS-Projektleitung in der IT. Ob man wisse, dass das DMS nicht genutzt werde? Ja, das sei wohl so. Lange Erklärungen über die Mitarbeiter der drei Abteilungen und dass sie so träge und widerständig seien und ihre Führungskräfte sowieso nicht motivierend. So sei es eben. Da könne man auch nichts machen. Irgendwann würde sich was ändern, wenn jüngere Mitarbeiter in die Abteilungen kämen, die mehr IT-affin seien.
Also in 20 Jahren?, denkt sich Jelena. Sie hat jetzt drei Möglichkeiten:

• Das Projekt ablehnen.
• So tun als ob: Irgendein Papier verfassen über QM und DMS und in drei Besprechungen präsentieren und absegnen lassen. Und dann verschwindet es in der Versenkung, in der schon das DMS-Projekt liegt.
• Sich den Schuh anziehen und schauen, warum die Voraussetzung für das eigene Projekt – nämlich das DMS – nicht klappt.

Jelena entscheidet sich für die 3. Sie wird aktiv. Sie besorgt sich einen externen Berater, der sich mit solchen Fällen gescheiterter DMS-Einführung auskennt. Ihre Wahl fällt auf mich. Budget hat sie noch keines, also vereinbaren wir eine kostenlose Vorberatung in Form eines Erkundungsworkshops. Da wollen wir ausloten, inwieweit wir den Widerstand im Projekt in Unterstützung verwandeln können.
Jelena lädt dazu die Führungskräfte der drei Pilotabteilungen ein (nur zwei von ihnen kommen dann tatsächlich) und die offizielle Projektleitung aus der IT. Sie informiert vorab den COO der P&F Deutschland GmbH, damit er sich nicht übergangen fühlt. Auf dem Workshop gelingt es uns gemeinsam, dass die zwei anwesenden Pilotabteilungen anfangen, den Nutzen des Projekts für sich selbst zu erkennen: eine der Führungskräfte ist auf einmal Feuer und Flamme, die andere wagt es zumindest, ihre Skepsis ein wenig abzulegen.

Jetzt ist Jelena nicht mehr zu bremsen. Sie wird persönlich vorstellig bei COO und CEO und holt sich die Erlaubnis, mit einer neuen Projektvision und agiler Methode das Projekt neu aufzusetzen („abzurunden“, sagt Jelena, denn sie will keine Schuldzuweisungen an die Verantwortlichen der ersten gescheiterten Projektphase). Sie bekommt die Genehmigung zum Experimentieren. Bei der Gelegenheit besorgt sie sich auch ein Budget. 50.000 € - nicht sehr üppig, um 500 Arbeitsplätze ganz neu aufzusetzen. Aber um anzufangen und erste größere Erfolge zu erzielen und den Führungskräften klar zu machen, dass das Neue sich lohnt – dazu reicht es allemal. Und dann werden wir weitersehen.

Das „Wer“ ist entscheidend

 

Wie kann man diese Erfahrung mit „Jelenas Projekt“ interpretieren? Wie kann man die Erfahrung nutzbar machen für andere Projekte?

Gerhard Wohland hat auf dem Freiräume-Camp im April dieses Jahres in Hannover von Erfahrungen berichtet, die denen Jelenas ähneln. Erfahrung Nr. 1: In klassischen, statischen, verkrusteten Organisationen (er nannte die Telekom als Beispiel) bilden sich an verschiedenen Stellen „Höchstleistungsinseln“, die neue moderne Methoden einführen – und dabei unter dem Radar der höheren Hierarchie durchfliegen. Erfahrung Nr. 2: Das Gemeinsame dieser Höchstleistungsinseln bestehe darin, dass sie von „Meistern“ geleitet würden. Wobei er „Meister“ ganz klassisch als Handwerksmeister versteht – jemand, der weiß, wo er hinlangen muss, um ein Ergebnis zu erreichen.

Die wichtigste Frage, wenn Probleme in komplexen Situationen gelöst werden, sei nicht das „Wie“ (also die Frage nach dem Prozess oder der „best practice“), sondern nach dem „Wer“: Wer rmit welchen Fähigkeiten und Werkzeugen hat sich des Problems angenommen?

Das hat mir die Einordnung von Jelenas Projekt in meine Erfahrungslandschaft erleichtert. Jelena ist eine „Meisterin“ in zweierlei Hinsicht:

• Sie kann strukturieren, und zwar auf einer klaren Basis der Geschäftslogik (sonst könnte sie den Vertretern des Software-Lieferanten, die immer ihre Datenbanklogik in den Vordergrund spielen wollen, nicht Paroli bieten. Was sie aber tut.
• Sie kann führen. Also Visionen entwickeln und empathisch vertreten – und zwar sowohl gegenüber den Pilotabteilungen und deren „Silovertretern“ wie gegenüber der oberen Hierarchie (deren Einverständnis sie ständig einholt, damit sie sich nicht übergangen fühlen und aus Angst vor Kontrollverlust das Projekt plattmachen).

Jelena hat in einem agilen Sinne die Führung der P&F Deutschland übernommen – zumindest in dem einen, aber sehr wichtigen Schlüsselfeld. Führung im Sinne von Rolle, also im tatsächlichen Sinne – nicht im Sinne von formeller Stellung (das sind weiterhin CEO und COO, die aber ganz andere Steckenpferde pflegen).

Das bedeutet für ähnliche Projekte in nicht-agilen Organisationen: schaue als externer Berater, ob das Projekt, das du vielleicht begleiten sollst, eine „Meisterin“ oder einen „Meister“ als Projektleiter oder Product Owner hat. Wenn ja, hat das Projekt gute Chancen. Wenn nein, dann prüfe, ob du eine Meisterin oder einen Meister ins Projekt reinholen kannst – ob es so jemanden gibt in der Organisation. Wenn auch das nicht – dann lass die Finger vom Projekt.

Anmerkungen

 

• /1/ So z. B. Craig Larman, der das sogar bescheiden als „Larman's Laws of Organizational Behavior“ bezeichnet. Vgl. http://www.craiglarman.com/wiki/index.php?title=Larman's_Laws_of_Organizational_Behavior