
er Erfolg in einem Softwareprojekt wird von verschiedenen Beteiligten (Stakeholdern) anhand sehr unterschiedlicher Faktoren bewertet. Während für die Projektleiter auf Entwickler- und Kundenseite ein vollständiger und pünktlicher Roll-out wesentlich ist, zählt für den Auftraggeber die Aussicht auf Effizienz in der Wertschöpfung sowie eine kurze und reibungslose Umstellungs- und Einführungsphase. In zahlreichen Projekten durfte ich lernen, wie zentral dabei ein kleiner, simpler Faktor sein kann und wie groß die Auswirkungen sind, wenn diesem zu wenig Aufmerksamkeit geschenkt wird: Die Akzeptanz der Mitarbeiter auf Kundenseite.
Ein entscheidender Faktor
Zugegebenermaßen habe ich selbst einige mehr oder weniger schwerwiegende Fehler gemacht diesbezüglich. Als Junior-Berater dachte ich, dass mit gut vorbereiteten Workshops, sauberen Dokus und verständlichen Konzepten einer erfolgreichen Konzeptionsphase nichts im Weg steht. Und mit genügend Puffer, gesundem Pragmatismus, um Scope-Creeping vorzubeugen, sowie einer mit dem Kunden abgesprochenen Schulungs- und Testingphase sollte einem erfolgreichen Go-Live nichts im Weg stehen. Oder? Weit gefehlt!
Stakeholder, die nicht am Projekterfolg interessiert sind
Ich erinnere mich an einen Konzept-Workshop, in dem ein Finanzchef eines KMU mit rund 140 Mitarbeitern saß, der auf jede Frage skeptisch bis ablehnend geantwortet und sichtlich kein Interesse hatte, sein Wissen zu teilen. Was ich zu spät realisiert hatte: Ich war derjenige, der von seinem Chef ohne sein Einverständnis beauftragt wurde, sein über Jahre hinweg in unzähligen Überstunden entwickeltes Excel-Tool abzulösen. Das ist natürlich schmerzhaft und undankbar. Aber gerade dieses Tool war für den Chef der Firma ein Grund, eine neue Software für die Finanzplanung anzuschaffen, denn außer dem Finanzchef verstand das Excel niemand mehr.
In dieser Haltung der mangelden Kooperationsbereitsschaft gab mir dieser Finanzchef nur die nötigsten Informationen. Und auch nur die, welche ich selber aktiv angefragt hatte. Es mag eine böse Unterstellung sein, aber womöglich dachte er, dass eine Software, die unvollständig ist und laufend nachgeberssert werden muss, dem Chef aufzeigen würde, dass die Idee, diese neue Software anzuschaffen, schlecht und sein bisheriges Excel-Tool viel besser war.
Skeptiker zu Komplizen machen
Heute weiß ich, dass die Einbindung der wichtisten Wissensträgern und Stakeholdern zentral ist. Und die richtige Motivation ist dabei – wie überall im Leben – von entscheidender Bedeutung. Dem Finanzchef konnte ich, als ich die Situation endlich verstanden hatte, problemlos ins Projekt miteinbinden, indem ich ihm für das komplexe Excel-Tool meine Wertschätzung ausgedrückt und ihm erklärt hatte, dass er damit sozusagen den Prototyp für die neue Software entwickelt hat. Dadurch konnten wir ihn abholen, weil er fortan nicht mehr der “Verlierer” war, dessen Eigenentwicklung erbarmungslos ersetzt wurde. Vielmehr setzten wir seiner Excel-Lösung die Krone auf, in dem wir sie als Grundlage einer professionellen Neuentwicklung verwenden. Plötzlich wurde er zum feurigen Befürworter der neuen Software und hat von sich aus sogar alle Makel seines Excel-Tools offengelegt, damit diese im neuen System verbessert werden kann.
Diesen Finanzchef wurde – einzig durch meine Anerkennung seiner Arbeit und Person und dadurch, dass ich auf seine Bedürfnisse eingegangen bin – von meinem größten Skeptiker zu meinem treusten Komplizen, der das neue System als “sein Baby” angesehen, überall angpreist hat und mich sogar in Schutz genommen hat, als es nach der Einführung noch zu vereinzelten Fehlermeldungen gekommen war. Nicht auszudenken, wie er sich verhalten hätte, wäre er bei der zu diesem Zeitpunkt noch verärgert gewesen.
Die richtig Motivation von Stakeholdern ist entscheidend – und Chefsache!
Das ist nur eines von zahlreichen Beispielen. Nicht selten befürchten Mitarbeiter in Workshops sogar um ihre Jobs. Nicht nur, dass sie Angst haben, durch professionelle Systeme ersetzbarer zu werden – war die Komplexität dieses zentralen Excel-Files doch eine gewisse Absicherung für den Finanzchef. Viel häufiger habe ich erlebt, dass Mitarbeiter zu Beginn einer Konzeptionsphase noch sehr motiviert geholfen haben, die Prozesse aufzuzeigen, plötzlich aber ohne offensichtlichen Grund keine Motivation mehr spürbar war. Sie haben nämlich realisiert, dass die neue Software wesentliche Arbeitsschritte unnötig machen würde und sich die Frage gestellt, was sie dann noch zu tun hätten. Halfen sie womöglich gerade mit, ihren Job zu ersetzen?
Solche und viele andere Ängste, Bedürfnisse und Befindlichkeiten können in Softwareprojekten entscheidend sein. Destruktive Projektbeteiligte sind ein ernsthafter Risikofaktor und können ein Projekt sogar beerdigen. Unsere Projektleiter und Berater kennen sich damit aus und sprechen mögliche Schwierigkeiten immer an. Deshalb ist es wichtig, dass ein Projektleiter oder Vorgesetzter auf Kundenseite zur Verfügung steht, der in solchen Fällen helfen kann, die Situation richtig einzuschätzen und gemeinsam mit uns motivierend einzugreifen und Ängste zu nehmen.