Haben Sie einmal einen vorsichtig formulierten und höflichen Verbesserungsvorschlag gemacht und wurden dann nachsichtig belächelt: „Das funktioniert bei uns sowieso nicht.  Vergiss einfach alles, was sie dir auf der Uni beigebracht haben.“. In diesem Artikel von der freiberuflichen Managementtrainerin Andrea Hermann lesen Sie, warum Organisationen oft Vorschlägen gegenüber verschlossen sind und was man als Einzelner dagegen tun kann. Aus der Zeitschrift des Departements Betriebswirtschaftslehre der Universität Bern. (PDF, 5 Seiten, 368 kB)

Kostenlose Zusendung per E-Mail:   ► Alle Dokumente anzeigen 

Grobe Voransicht des Dokuments: 'Das funktioniert bei uns nicht! - Wie Sie Widerstände überwinden!' (Teil 3):

oder Arbeitsprozesse hinzu. Versuchen Sie nicht, andere dazu zu bringen, sich an das von Ihnen definierte Vorgehen zu halten. Ja, seien Sie sogar vorsichtig damit zu erwähnen, dass Sie etwas Neues ausprobieren. Wenn die anderen nicht von selbst bemerken, dass nun plötzlich etwas besser ist, dann war Ihre Idee vielleicht doch nicht so genial.
Ich sehe zwei Möglichkeiten, um eine Methode zu verwenden und empfehle die zweite. Sie können die Methode erstens nach Lehrbuch verwenden, einschließlich aller damit verbundener Vorlagen, Notationen, Regeln und spezieller Werkzeuge. Es dürfte schwer sein, die Kollegen dazu zu bringen, sich an die UML-Notation zu halten und manchmal dürfen Sie aus Sicherheitsgründen auch keine Open Source Tools auf Ihrem Rechner installieren, abgesehen davon dass Sie für Ihre subversive Verbesserung auch kein offizielles Budget für ein UML-Werkzeug erhalten.
Zweitens können Sie die Methode als mentales Modell verwenden. Mentale Modelle dienen dazu, etwas Komplexes zu strukturieren, systematisch zu arbeiten, Erwartungen zu steuern und konsistent mit allen Beteiligten zu kommunizieren. Solche mentalen Modelle sind im Software Engineering der Projektplan oder das Vorgehensmodell, die Geschäftsprozessmodelle, die Software-Architektur und viele mehr. Bei der Teamarbeit ist es wichtig, dass alle Beteiligten dasselbe mentale Modell teilen, damit ihre Arbeitsergebnisse zusammenpassen. Wenn Ihr Team noch kein mentales Modell verwendet, dann bieten die Software Engineering Methoden Ihnen eine große Auswahl. Wenn Sie eines gut auswählen und damit Ihre Arbeit, Kommunikation und Dokumente strukturieren, werden die anderen diese Struktur gerne übernehmen. Die Menschen mögen zwar keine Veränderungen, aber Sie mögen gerne ordentliches Vorgehen. Ist es beispielsweise Ihre Aufgabe, die Software-Anforderungen zu ermitteln, unterstützt Sie eine Methode sehr dabei, die wirklich wichtigen Fragen in einer sinnvollen Reihenfolge zu stellen und zu wissen, wann Sie alle nötigen Informationen gesammelt haben. Ihre Besprechungen erfolgen so systematisch und ergebnisorientiert und wirken professionell. Sie müssen weder fragen "Bitte erzählen Sie mir alles, was Ihnen einfällt" noch "Ich hatte neulich noch eine Frage vergessen…". Wenn Sie beispielsweise Anforderungen als Use Cases erfassen, können Sie die Use Case Liste an vielen Stellen verwenden: im Lastenheft, auf Präsentationsfolien, um Meeting-Tagesordnungen und –Protokolle zu strukturieren. Kurz und gut: Anstatt zu erwarten, dass alle anderen die Methode verwenden, setzen Sie sie zunächst selbst ein, um Ihre Arbeit besser zu strukturieren. Nach außen hin müssen Ihre Ergebnisse die in der Firma übliche Struktur aufweisen, nur im Detail sind sie nun besser. Gibt es beispielsweise eine verpflichtende Vorlage für Lastenhefte, dann befüllen Sie diese.
Wenn die anderen sehen, wie gut die Methode (hier, in dieser Firma, in diesem Projekt, mit dieser Technologie!) funktioniert, dann wollen sie das auch haben. Das Gute wird sich durchsetzen!
Subversive Prozessverbesserung, Schritt 3: Verführung
Sie haben Ihre Arbeit verbessert, eventuell die Methode noch angepasst. Ihre Arbeit geht flott von der Hand. Dann werden die Kollegen und vielleicht der Chef aufmerksam: "Oh, das sieht aber gut aus!" "Wie hast du das gemacht?" "Kann ich das auch verwenden?" "Wo kann ich etwas darüber lesen?" "Könntest du das im nächsten Team-Meeting vorstellen?"
Wenn dies nicht von allein geschieht, dann müssen Sie ein wenig nachhelfen, aber subtil. Übertreiben Sie nicht. Ihre wunderschönen Modelle und Pläne müssen auf Ihren Präsentationsfolien gut zur Geltung kommen und für sich selbst sprechen. Verführen Sie die anderen dazu, sich Ihnen anzuschließen.
Zum Weiterlesen
Wenn Sie diese Themen näher interessieren, empfehle ich folgende Literatur: Die Fachliteratur zum Change Management behandelt die Frage, warum sich Menschen gegen Veränderungen sträuben und wie man Veränderungen trotzdem durchführen kann. Üblicherweise geht es hierbei um offiziell geplante und durchgeführte, meist tief greifende Änderungen. Manchmal werden Veränderungen und Verbesserungen auch absichtlich sabotiert. Lesen Sie hierzu:
o Dion Kotteman, Jeroen Gietema: Das kleine Handbuch für den Projektsaboteur. Verlag: Wiley-VCH Verlag, 2010
o Johann Rost, Robert L. Glass: The Dark Side of Software Engineering: Evil on Computing Projects. John Wiley & Sons, 2011 Mein Blog über "Human Factors in Software Engineering" behandelt regelmäßige Themen zum Auseinanderklaffen von Theorie und Praxis. http://andreaherrmann.twoday.net

Dieser Artikel wurde zuerst veröffentlicht in:

Herrmann A (2013) Das funktioniert bei uns nicht - Wirklich? BeWL. Zeitschrift des Departments Betriebswirtschaftslehre

Grobe Voransicht des Dokuments: 'Das funktioniert bei uns nicht! - Wie Sie Widerstände überwinden!':  Teil 1, Teil 2, Teil 3, Teil 4