SW-Engineering

IT-Projekte sind ein Desaster. Wer die “Scene” kennt, kennt auch Bilder wie diese auf der linken Seite. Dieses Bild stammt von den Seiten Herrn Meisl. Das Schlimme daran ist, das es stimmt. Wer tiefe Einsichten in das IT-Geschäft hat, also ganz unten im operativen Bereich arbeitet und gearbeitet hat und auch die Sicht von ganz oben kennt, der weiß um diese Dinge. Ich vermute nur, das es nicht allzuviel von diesem Menschen gibt, sonst müsste die IT-Welt eigentlich anders sein. Auf der anderen Seite stellt sich die Frage, ob man die Probleme tatsächlich lösen möchte. Schließlich sichert die Komplexität der IT und das Chaos Arbeitsplätze !

Die steigende Varietät von komplexen Systemen und Technologien, hier speziell IT-Systeme, fordern immer höhere Projektmanagement- und Teamkommunikationsfähigkeiten. Dieser Artikel beschäftigt sich mit den Schwierigkeiten, die sich aus der Praxis ergeben und zeigt auf, das wir vor einem Paradigmenwechsel stehen, der erforderlich ist, um künftig erfolgreich Projekte abzuwickeln.

Industriealisierbarkeit von Wissensarbeit

Heute möchte man komplexe Projekte strukturiert, am Liebsten nach Standardprozessen und Vorgehensweisen, abwickeln. Der Wunsch dahinter ist, diese Projekte kontrolliert zu planen. Mir stellt sich oft die Frage, ob man hier nicht zwanghaft versucht, die Automatisierung von Produktionsprozessen aus der Industriaisierung auf die Automatisierung von Entwicklungsprozessen in der Informationsgesellschaft zu übertragen. Ich stelle mir immer öfter die Frage, ob dies überhaupt möglich ist? Die Automatisierung von Fertigungsprozessen ist einfach etwas anderes, als die Automatisierung von Entwicklungsprozessen, die durch Wissensarbeiter abgearbeitet werden. Wir haben es hier nicht nur mit hochkomplexen inhaltlichen Sachverhalten zu tun, sondern auch die Arbeit selbst, die “Wissensarbeit” ist hochkomplex. Es ist einfach ein Unterschied, ob ich im Fertigungsprozess einen Arbeitsschritt vollziehe, wie z.B. das Kontrollieren und Seuern eines Lackierroboters, oder ob ich im Softwareentwicklungsprozess einen Arbeitsschritt vollziehe, wie das Aufnehmen komplexer Anforderungen. Hier spielen u.a. Sprache, Kommunikationsfähigkeit, Unternehmenspolitik, komplexe fachabteilungsübergreifende Prozesse, Ziele und Werte meines Gegenübers eine entscheidende Rolle (!). Ich bin mir sicher, das herkömmliche Projektstrukturen ausgedient haben und durch einen Paradigmenwechsel langfristig abgelöst werden.

Projektkommunikation und Struktur

Ich habe IT-Projekte erlebt, in den man mit weniger Teammitgliedern mehr erreicht hat, als in Projekten mit mehr Teammitgliedern bei gleicher Produktkomplexität. Ich habe “aufgeblasene Projekte” erlebt, bei den es mehr “Häuptlinge” als “Indianer” gab, die weniger geleistet haben, aber das 10fache gekostet haben. Projekte haben ja ihren Sinn. Aus der Linie, aus der Hierarchie herausgelöst, sind komplexe Aufgaben ja nur als Projektform realisierbar. Meine Erfahrung einer idealen Größe eines Projektteams, welche komplexe Aufgabenstellungen zu lösen hat, liegt bei 6-9 Mitgliedern. Diese Teamgröße ergibt sich aus einer simplen Formel, nämlich der Anzahl von p Kommunikationsstränge bei n Teammitgliedern, die sich aus der Formel p = n*(n-1)/2 Kommunikationsstränge ergeben. Hier haben wir es mit einer ganz einfachen Sache zu tun, je mehr Leute im Projekt, desto mehr Abstimmungsbedarf. Das ist einleuchtend, aber und zwar ein GROSSES ABER: vielen Projektmanagern scheint die Auswirkung des klitzekleinen, unscheinbaren mathematischen Quadrates nicht klar zu sein. Geprägt von linearen und trivialisierten denken, ist hier eher folgende Denkweise anzutreffen: Wenn wir die Entwicklerressourcen verdoppeln, dann sind wir in der Hälfte der Zeit fertig.

Projektkommunikation

Projektstruktur und Komplexität

Diese 6-9 Experten können eine gewissen Komplexität bearbeiten. Dies funktioniert ganz gut. Ist die zu bearbeitende Komplexität größer als die 6-9 Mitglieder bearbeiten können, dann machen wir häufig einen entscheidenden Fehler. Wir organisieren Teilprojekte, die zusammengefasst werden und organisieren diese hierarchisch! Meiner Meinung nach liegt hier der entscheidende Punkt. Man verlangt dann von einem Teilprojektleiter, das er die Komplexität des Teilprojektes seiner 6-9 Mitarbeitern so verdichten und abstrahieren kann, das er dies an den übergeordneten Projektleiter kommunizieren kann. Angenommen wir haben nur ein kleines Projekt, welches aus 2 Teilprojekten besteht, 6-9 Teammitgliedern pro Teilprojekt, je einen Teilprojektleiter pro Team und einen Gesamtprojektleiter. Dann fließt die gesamte Varietät von 12 bis 18 Menschen verdichtet über nur 2 Kommunikationsstränge nach oben. Meine Erfahrung: schon das funktioniert nicht. Ich selbst habe erlebt, das zwei solcher Teilprojekte auf einem Raum von 60 Quadratmetern Softwaremodule redundant programmiert haben. Künftig werden deshalb größere Projektstrukturen kybernetisch organisiert werden müssen, sodaß zwei Teilprojekte nicht hierarchisch vernetzt werden sondern kybernetisch, z.B. anhand von drei- oder vierdimensionalen Strukturen. (Siehe auch Stafford Beer1 oder den Hyperkubus.

Hyperkubus

Eine weitere Veränderung kann man vornehmen, wie die Informationen zwischen den Teilprojekten ausgetauscht werden (zeitlich, räumlich, organisiert). Interessant wäre hier eine Struktur die sich selbst erzeugt bzw. reproduziert und dabei die Anzahl der Projektmitglieder vergrößert, gemäß einer Kybernetik 2. Ordnung.

Paradigmenwechsel

Die sich erhöhende Komplexität und die steigende Geschwindigkeit am Markt, erfordert diesen Paradigmenwechsel. Kleinere Unternehmen können damit problemlos umgehen. Konzerne werden damit ihre Probleme haben. Derzeit versuchen die Großen die Kleinen zu schlucken. Aufgrund ihrer Flinkheit aber, lassen sich manche Kleine nicht fressen. Diese kleinen “ebays, Amazons und Googles” werden schnell groß. Und: Wenn sich nicht vergessen und verlernt haben, warum sie nicht gefressen wurden, nämlich weil Sie flink waren, dann haben Sie eine große Chance diese Eigenschaft beizubehalten. Diese Unternehmen sind dann groß und flink. Eine andere Perspektive wäre die Anwendung der Kybernetik auf einen Konzern, um ihn gegen schnelle Marktveränderungen resistent zu machen.

IT-Offshoring und IT-Outsourcing

Hinter obigen Punkten ist deshalb zu bedenken, ob man es mit industrialisierbaren Wissensprodukten hat oder nicht. Häufig wird versucht, die Herstellung nicht oder schwer industrialisierbarer Wissensprodukte z.B. nach Indien durch Offshoring auszulagern. Die Folge: unterm’ Strich höhere Kosten durch entsprechenden Management- und Kommunikationsoverhead. Indische Briefkastenfirmen könnten ein Globalisierungseffekt sein (!)

Universalist und Generalist vs. Spezialist

Gutausgebildete Generalisten mit Tiefgang und hohen Kommunikationsfähigkeiten werden künftig benötigt, um Schnittstellenpositionen zu besetzten, die Teilprojekte miteinander vernetzen. Spezialisten sind bei komplexen Produkten notwendig, diese müssen aber auch permanent ihr Spezialistenwissen anpassen bei den marktbedingten kurzen Produktlebenszyklen. Wer auf Spezialistentum “hängenbleibt” kann schnell den Zug verpassen und abgehängt werden. Somit müssen auch Spezialisten “über den Tellerrand” hinausschauen. Letztlich ist die Spezialisierung aus der Sicht eines Generalisten eine Trivialisierung, da ein Spezialist den Fokus verengt.

Zusammenfassung

Ich glaube wir gehen einer spannenden Zeit entgegen und befinden uns bereits in der Phase eines Umbruchs zu neuen Paradigmen. Schaut man sich virtuelle fraktale Organisationsformen an, wie z.B. einige äußerst erfolgreiche OpenSource-Gemeinden, dann muss man sich fragen, wie ein Haufen chaotischer virtuell miteinander vernetzter Menschen in der Lage sind professionell qualitativ hochwertige Software zu entwickeln. Für Großkonzerne ist und wird es eine Herausforderung bleiben, solche innovativen Strukturen zu adaptieren.

Links: