Babylon ist überall

Wieder mal aneinander vorbei geredet? Das hatte ich mir anders vorgestellt? Passiert schon mal, passiert immer wieder und passiert oft in Projekten. In Projekten treffen thematisch bedingt Personen aufeinander, die sich sonst eher selten oder überhaupt nicht begegnen, die aber aus ihrer Arbeitsumgebung eine eigene Arbeitskultur und eine eigene Arbeitssprache mitbringen.

Üblicherweise ist es manchmal für Mitarbeiter bereits im normalen Arbeitsalltag schwierig, anderen Arbeitskollegen inhaltlich zu folgen, wenn diese nicht die unmittelbaren Prozessvorgänger oder -nachfolger sind. Je größer diese operative Distanz ist, desto unterschiedlicher sind oftmals die Inhalte zu gleichen Begriffen. So ist z.B. ein “Material” für den Meister in der Produktion etwas anderes als für den Administrator aus der IT oder eine “Ladung” ändert möglicherweise ihre Bedeutung wenn man sich mit einem Einkäufer oder mit einem Versandleiter unterhält. Die Betriebssprache unterscheidet sich von Abteilung zu Abteilung, das Sprachmuster im Vertrieb ist anders als in der IT, im Controlling anders als im Marketing.

Ungleich schwieriger ist es, wenn innerhalb eines Projekts die unterschiedlichen sprachlichen Inhalte aufeinandertreffen, denn in Projekten muss diese gemeinsame Projektsprache erst gefunden werden. Da die Sprachwelt zunächst mal nur in den Köpfen steckt und nicht offen kommuniziert wird, sind Missverständnisse zwangsläufig. Nun spielt es aber in Projekten eine elementare Rolle, welcher Inhalt mit Begriffen gemeint ist, da gemeinsame Ziele und Arbeitspakete etc. definiert und dokumentiert werden müssen. Darauf aufbauend werden Aufgaben verteilt, Meilensteine vereinbart und Projektmessgrößen definiert.

So war bspw. in einem Unternehmen der “Geschäftsprozess” so besetzt, dass er für alle Prozesse benutzt wurde, wobei allerdings weder eine Prozesshierarchie noch eine verbindliche Nomenklatur bzgl. Darstellung und Prozessmodell vorhanden war. Als dann angefangen wurde, eine systematische Prozesslandschaft zu entwickeln, wurde der Begriff Geschäftsprozess nicht mehr verwendet, sondern es wurden komplett neue Begriffe eingeführt. Dies hat sich später noch mal als vorteilhaft erwiesen, als bei der Einführung eines ERP-Systems vom Systemanbieter alle Aktionen im IT-System als Geschäftsprozess bezeichnet wurden.

Eine Hilfe sind in dieser Situation bestehende Normen und Richtlinien. In diesen sind viele Begriffe und deren Inhalte in langer Vorarbeit weitestgehend standardisiert worden. Deren Nutzung bietet sich daher an und sollte auch vorrangig sein. Aber auch hier ist es wie immer im Leben: Ein Inhalt, der außerhalb des Projektes gelebte Realität ist, wird kaum innerhalb eines Projekts geändert werden. Die Mitarbeiter werden nicht am Vormittag im Projekt eine andere Sprache sprechen als am Nachmittag in ihrer Abteilung.

Um spätere Missverständnisse trotzdem frühzeitig zu vermeiden, ist es sinnvoll, sehr früh in Projekten die prägnanten Projektbegriffe herauszufinden und inhaltlich eindeutig zu formulieren. Dabei sollte “soviel wie nötig” Vorrang haben vor “soviel wie möglich”. Entscheidend ist, dass sich alle Projektbeteiligten auf diesen Sprachgebrauch einigen und diesen auch benutzen. Denn allein die Festlegung reicht nicht. Die intensive Verwendung muss in der gesamten Projektkommunikation stattfinden. Das bezieht die Außendarstellung des Projekts eindeutig mit ein. Erst dadurch werden missverständliche Darstellungen im und über das Projekt weitestgehend verhindert.

Die meisten Projekte sind bereits fachlich komplex genug, ein babylonisches Sprachgewirr sollte daher nicht auch noch für Unruhe sorgen.

Schlagwörter: , , ,

Kommentare

  1. Max L. J. Wolf

    Hallo Herr Hänßgen,

    mit Ihrem Beitrag treffen Sie die Achillesverse der Projektarbeit. Mangelnde Kommunikation ist trotz hochgerüsteter Technik eine der Hauptursachen für das Scheitern gerade von personalintensiven Vor-haben. Dabei wäre es ganz einfach, hier voranzukommen. Es geht darum, die verschiedenen Sichten so zu koordinieren, dass für alle Beteiligten ein gemeinsames Verständnis entsteht. Im Wesentlichen gibt es heute klare Kommunikationsregeln wie „Aktives Zuhören“, die ich in meinem Buch „Projektmoderation“ herausgearbeitet habe. Dann könnten die Themen wesentlich mehr visualisiert werden, wie z. B. über die Meilenstein-/ Kosten-Trendanalyse, Mind Map, Balkenpläne, Simulationen oder Baumstrukturen für Anforderungen, Arbeitspakete oder für die Mannschaftsdarstellung. Auch ist gerade bei IT- und Or-ganisationsprojekten sinnvoll ein Glossar anzulegen und die verwendeten Begriffe festzulegen und zu standardisieren. Alle diese Gesichtspunkte sind seit NLP-Erscheinung bekannt, tun muss es die Projekt-leitung. Einsparungspotential durch weniger Kommunikationsschleifen von mindestens 30% der Zeit!

Leave a Reply

Ihre E-Mail-Adresse wird nicht veröffentlicht. Benötigte Felder sind markiert. *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>