IT-Projekte sind Technokratien. Die Ziele von Projekten müssen effektiv und zielorientiert durchgeführt und zu Ende gebracht werden. Leitende Personen legitimieren sich durch Wissen und Expertise.

Alle ihre Handlungen sollten auf technischem und wissenschaftlichem Wissen aufbauen und sich an den Projektanforderungen orientieren. Die Bedeutung des Teams, demokratischer Willensbildung oder von Diskussionen rückt in den Hintergrund, da die Experten sowieso am besten wissen, was genau zu tun ist. Man fährt am besten, wenn man einfach nur umsetzt, was die sich ausgedacht haben.

Schlimme Vorstellung?

Irgendwie schon.

Gibt’s in Wirklichkeit nicht!

Doch — allzu oft.

Muss das sein?

…

Nein natürlich nicht.

Der Imperativ des letzten Wortes

Aber es ist nicht einfach, mit solchen technokratischen Anwandlungen umzugehen. Das Know-how in einem Projekt-Team ist niemals gleich verteilt. Man braucht erfahrene Architekten und Projektleiter im Team. Doch deren Verantwortung sollte es nicht nur sein, gute Ideen und Konzepte zu entwickeln und voranzutreiben.

Ebenso wichtig ist es, die guten Ideen so zu kommunizieren, dass das restliche Team sie nachvollziehen, eigenständig umsetzen und weiterentwickeln kann. Eine gute Idee ist nur so gut, wie ich sie Anderen verständlich vermitteln kann.

Die Aufgabe des Architekten ist es, wichtige technische Entscheidungen im Projekt zu treffen und diese auch durchzusetzen. Dabei kann ein guter Architekt sein Team von seinen Ideen begeistern, sie gemeinsam mit seinem Team diskutieren und weiterentwickeln.

Andere Architekten setzen ihre Ideen mit dem Imperativ des letzten Wortes durch – „Macht das so, ich erkläre euch später, warum das so gemacht werden muss„. Man kann sein Team kaum besser demotivieren.

Auch für Architekten selbst wird letzterer Ansatz selten zu einem langanhaltenden Arbeitserlebnis führen, das frei von Verdruss ist.

Wenn ich nicht dafür sorge, dass meine Ideen und Konzepte vom Team verstanden werden, muss ich sie ständig neu erklären. „Das Team ist echt dusselig, jedes Mal muss ich mein Konzept von vorne für die durchkauen„. Hier könnte man auch die Vermutung anstellen, dass der Architekt jedesmal aufs Neue versagt, wenn er es nicht schafft, mit seinen tollen Ideen bleibenden Eindruck und Verständnis beim Team zu hinterlassen.

Erfolgsrezept? Mehr Überzeugungsleistung!

Gute Ideen werden von den Leuten angenommen. Oft genug ist es so einfach. Steigt der Aufwand an notwendiger Überzeugungsleistung, so ist das möglicherweise ein Hinweis darauf, dass der eingeschlagene Weg noch nicht der optimale ist. Entweder müssen dann Wissenslücken geschlossen oder gemeinsam mit dem Team eine geeignetere Lösung gefunden werden.

Und wenn es mal nicht so einfach ist, sollte man sich als Architekt immer vor Augen führen, dass man außer dem Team niemanden sonst hat, der die Arbeit erledigt.

Realistisch betrachtet gibt es keine Alternative dazu, dem Team eine Lösung an die Hand zu geben, mit der es gut zurechtkommt und die es auch eigenhändig umsetzen kann. Ein Architekt, der mit seinem Team auf Augenhöhe arbeiten will, muss hier vermitteln, verhandeln und zuhören.

Der Architekt ist verantwortlich für die Erstellung und Umsetzung der Software-Architektur. Dazu braucht er das Team. Im Verlauf größerer Projekte wird ein Architekt auf viele externe Widerstände stoßen. Er wird sich das Leben sehr viel einfacher machen – und den Projekterfolg wahrscheinlicher, wenn er es schafft, das Team von seiner Sache zu überzeugen.