-- WEBONDISK OK --

11 Kontext zur IT-Systementwicklung

Michael war glücklich, etwas Beherrsch- und Verdaubares vorgelegt zu bekommen. Der One-Pager war etwas, das er auch während seiner Verhandlungen auf dem Radarschirm halten konnte. Insbesondere die Handlungsempfehlungen, was zu tun, und noch wichtiger, was nicht zu tun sei, gefielen ihm. Aber Michael wäre nicht Michael, wenn er sich damit zufrieden gegeben hätte. Man gab ihm den kleinen Finger – und er:
„Das ist gutes Material, damit kann ich arbeiten! Jetzt, wo ich darüber so nachdenke, kommt mir noch etwas in den Sinn: Ich werde ja nicht nur die Konditionen verhandeln, sondern auch die Projektplanung über den gesamten Lebenszyklus entwerfen. Ist es möglich, Ihre Ergebnisse für einzelne Projektphasen zu spezifizieren?”
Weiteres unbekanntes Terrain und auch vermintes Gelände
Frank spürte Panik aufsteigen. Er verstand nur zu genau, was Michael forderte. Genauso gut verstand er auch, dass das vermintes Gelände war: Jetzt wurde von ihm erwartet, dass er sich zwischen die Frontlinien zwischen den IT-Ingenieuren begab. Im Haus gab es langjährige und fast religiöse Auseinandersetzungen über die beste Entwicklungsmethodik zwischen den verschiedenen Fraktionen: Was war der richtige Weg, Systeme zu entwickeln? Welches Paradigma und welche Methodologie sollte verwendet werden? Zeloten auf allen Seiten bestimmten den Diskurs: Wasserfall oder agil, oder etwas dazwischen? In diesem Moment hatte er keine Option, außer zu sagen:
„Ich werde eine Verbindung zwischen den kulturellen Mustern und den Projektphasen herstellen. Dann werden Sie an einem adaptierten Plan arbeiten können, der erwartete kulturelle Friktionen von vornherein phasenspezifisch berücksichtigt. Sie werden verstehen, welche kulturellen Hindernisse Ihnen möglicherweise in bestimmten Phasen im Wege stehen. Und Sie werden verstehen, wie Sie diesem Problem durch eine angemessene Projektorganisation begegnen können.”
Frank bereute sein Versprechen, noch bevor er die Tür schließen konnte. Er würde jetzt mit zwei Monstern kämpfen müssen, und beide waren mächtig. Dabei konnte er wenig Hilfe von außen erwarten: Aus einem Artikel wusste er, dass es keinen Mangel an Literatur über multikulturelles Management gab. Aber weniger als zwei Prozent behandelten einen IT-Kontext. Das war nicht vielversprechend!
Er beschloss, Klaus zu besuchen, Direktor für IT-Standards, Methodologie und Qualitätssicherung. Er befürchtete, auf einen Fundamentalisten zu treffen, aber zu seiner Überraschung war Klaus ausgesprochen aufgeschlossen.
„Frank, Sie können dieses Thema mit unseren Ingenieuren jahrelang diskutieren und werden immer noch keine methodische Klarheit haben. Nicht nur, dass sie kein gemeinsames Verständnis von Systementwicklungsmethoden haben. Aber auch, dass die Pragmatiker und Fundamentalisten sich über methodische Schönheit streiten. Sie wollen da nicht reingezogen werden, glauben Sie mir!
Hier ist mein Rat: Lassen Sie sich nicht in Methodendiskussionen hineinziehen. Das wird Ihnen nicht helfen. Versuchen Sie, sich über diese Auseinandersetzungen zu erheben. Halten Sie sich vor Augen, dass alle Entwicklungsmethodologien eines gemeinsam haben: Alle müssen sie Aufgaben wie Planung, Analyse, Design, Entwicklung, Testen etc. erfüllen. Das machen sie zwar in unterschiedlicher Art und Weise und nach unterschiedlichen Paradigmen. Aber sie haben es immer noch zu tun! Also konzentrieren Sie sich nicht auf die Entwicklungsmethodologie, sondern auf die logischen Aufgaben, die abgearbeitet werden müssen. Ich weiß, dieser Vorschlag ist eine brutale Übersimplifizierung, und er kommt mir nur schwer über die Lippen. Aber Sie haben keine andere Chance.”
Frank fühlte sich erleichtert. Mit Klaus' Empfehlung im Hinterkopf konnte er die Komplexität dramatisch reduzieren. Sie würde ihm helfen, religiöse Diskussionen mit den Zeloten zu umgehen. Und sie passte sofort zu seiner mittlerweile großen Sammlung an Anekdoten. Er musste diese nur noch spezifischen Projektphasen zuordnen und die dort nachgewiesenen kulturellen Dimensionen summieren.
„Works-as-designed” ein Beispiel unter vielen
Zum Beispiel erinnerte er sich an den Bericht eines Managers, der verzweifelt versuchte, die Qualität seiner Anforderungsspezifikationen in der Analysephase zu verbessern. Diesem Manager war klar, dass sein Fachbereichsteam wenig Erfahrung in der Dokumentation von Anforderungen hatte. Zum einen zog er entsprechende Maßnahmen zur Qualitätssicherung ein. Zum anderen ging er davon aus, dass es, wie es in seiner Kultur üblich war, eine inhärente Qualitätssicherung seitens seines Lieferanten gab: Er erwartete, dass die indischen Designer, Architekten und Entwickler auf ihn sofort zurückkommen und die Qualität seiner Spezifikationen hinterfragen würden, sobald sie Inkonsistenzen und Fehler feststellten.
Aber dieses Feedback kam nie. Offensichtlich erschwerten es einige kulturelle Faktoren dem indischen Team, die Spezifikation zu kritisieren: hohe Power Distance, hoher Collectivism, niedrige Uncertainty Avoidance u.v.m. Niemand rief ihn an und sagte, das sei unzulänglich, damit könne man nicht arbeiten. Stattdessen versuchte die indische Seite verzweifelt, die formelle Spezifikation irgendwie umzusetzen. Da Fehler sich in den folgenden Projektphasen fortsetzten (und deren Beseitigung folgerichtig immer teurer geworden wäre), wurde am Ende ein Resultat geliefert, das zwar den formellen Anforderungen entsprach, aber nur in Teilen brauchbar war. Diese Missstände wurden teilweise erst in der Testphase erkannt und verursachten massive Kosten, was wiederum zu unerfreulichen Schuldzuweisungen führte. Aus anderen Anekdoten wusste Frank, dass dieses „Works-as-designed”-Phänomen kein Einzelfall war.
Kein Gießkannenprinzip!
Frank war zuversichtlich. Das Beispiel half ihm, die Dinge schärfer zu sehen. Er konnte nunmehr pragmatischen Rat geben: Während der Analysephase muss die Power Distance gesenkt werden; die indischen Kollegen mussten ermuntert werden, Widerspruch zu erheben, wann immer sie Bedenken hatten. Dies kann auf vielfältige Weise und mittels vieler Tools geschehen. Es erschien ihm adäquat, mit einer entsprechenden Projektorganisation zu beginnen, die den Teamgeist unterstützte und der kollektivistischen indischen Kultur gerecht wurde; die Kommunikationsbarrieren mussten gesenkt werden, Wege mussten verkürzt werden. Diese Maßnahmen sollten durch gezieltes kulturelles Training und Coaching auf beiden Seiten flankiert werden, um Bewusstsein zu schaffen. Es würde nicht reichen, oberflächliche Maßnahmen wie die Nutzung von Vornamen und das Abnehmen von Krawatten zu propagieren. Auch stand ihm ein Satz von weiteren nachhaltigen Maßnahmen zur Verfügung.
Frank fuhr fort, die Anekdoten aus Sicht der kulturellen Dimensionen bezogen auf einzelne Projektphasen zu sichten. Und es wurde klarer, welche Empfehlungen er aussprechen sollte. Allerdings konnte er keine phasentypischen Muster nachweisen. Trotzdem konnte er aufgabentypische Empfehlungen abgeben, z. B. im Hinblick auf Architekturen und Entwicklungsstandards: Die typische geringe „Uncertainty Avoidance” auf der indischen Seite würde Pragmatismus ermutigen, vielleicht sogar etwas zu viel. Es manifestierten sich Defizite hinsichtlich eines Bewusstseins für die Einhaltung von vereinbarten Standards, Struktur und Organisation. Frank schlussfolgerte daraus von Anfang an die Notwendigkeit, Governance und Qualitätssicherung über alle Projektphasen zu betonen.
Der hohe Kollektivismus auf der indischen Seite legte wiederum beziehungsbildende Maßnahmen nahe. Persönliche Begegnungen erschienen ihm zwingend erforderlich. Im Fazit ging er durch seinen kompletten Satz an Bewertungskriterien und zog die Schlussfolgerungen und operativen Maßnahmen. Die Hofstede-Dimensionen waren zwar mächtig, aber er konnte weitergehende praktikable Erkenntnisse aus den Dimensionen anderer Autoren gewinnen. Effektiv waren insbesondere vertrauensbildende, zeit- und realitätswahrnehmungsbezogene sowie Fragen der direkten Kommunikation und der Übermittlung negativer Nachrichten.

Weiterlesen und „IT-Servicemanagement digital“ 4 Wochen gratis testen:

  • IT-Servicemanagement nach ISO 20000, IT Governance und IT Compliance
  • Zugriff auf über 220 Fachbeiträge und 160 Arbeitshilfen
  • Onlinezugriff – überall verfügbar


Sie haben schon ein Abonnement oder testen bereits? Hier anmelden

Ihre Anfrage wird bearbeitet.
AuthError LoginModal