Experten vs. Entscheider – Der gemeinsame Weg zum Ziel
Ein großes IT-Projekt zur Einführung einer neuen Cloud-Plattform sollte in sechs Monaten live gehen. Das Management drängte auf schnelle Ergebnisse und fixierte sich auf den Go-Live-Termin. Die Entwickler und Cloud-Architekten hingegen warnten früh: Ohne solide Architektur könnte die Plattform unter Last einknicken. Doch das Management setzte sich durch – mit fatalen Folgen. Pünktlich zum Stichtag ging die Plattform live, doch wenige Wochen später brach sie unter der Last zusammen. Die Rettungsaktion fraß Zeit, Budget und Nerven. Ein Einzelfall? Leider nicht. Denn in IT-Projekten prallen oft zwei Welten aufeinander.
Es braucht Experten mit tiefgehendem technischem Wissen und Entscheider, die den wirtschaftlichen und strategischen Überblick behalten. Beide Gruppen verfolgen dasselbe Ziel – ein erfolgreiches Projekt – aber ihre Perspektiven, Prioritäten und Kommunikationsweisen könnten kaum unterschiedlicher sein. Dieses Spannungsfeld ist eine der größten Herausforderungen in der IT. Technologie ist selten das Problem, vielmehr scheitern Projekte oft an zwischenmenschlichen und organisatorischen Faktoren.
In diesem Artikel beleuchte ich die typischen Konflikte zwischen Experten und Entscheidern, analysiere ihre Ursachen und stelle Best Practices vor, um diese Differenzen zu überwinden.
Experten und Entscheider: Zwei Perspektiven, ein Ziel
Die Perspektive der Experten
Stell Dir vor, Du bist Entwickler und arbeitest an einem hochkomplexen Software-Projekt. Du weißt, dass die richtige Architektur und saubere Code-Strukturen entscheidend sind, um später Skalierbarkeit, Wartbarkeit und Performance sicherzustellen. Doch plötzlich kommt der Projektmanager und sagt: "Wir müssen das Produkt in zwei Monaten auf den Markt bringen, auch wenn die Architektur noch nicht vollständig durchdacht ist. Das wird schon irgendwie passen!"
Das ist der Moment, in dem Du wahrscheinlich die Luft anhältst und innerlich denkst: "Das kann doch einfach nicht sein. Hört der nicht zu oder will er das nicht verstehen? Das wird nicht gut gehen." Es ist ein bisschen wie bei einem Ingenieur für Flugzeuge – die Gesamtlösung muss funktionieren: Wenn das Flugzeug zwar flugfähig ist, aber noch keine Räder zum Starten oder Landen hat, wird es schiefgehen.
Die in diesem Artikel betrachteten IT-Experten sind oft Entwickler, Architekten oder IT-Spezialisten, die ein tiefes technologisches Verständnis mitbringen. Ihr Fokus liegt auf Code-Qualität, Performance, Skalierbarkeit und technischen Best Practices. Sie denken in langfristigen Lösungen und sind oft skeptisch gegenüber kurzfristigen Workarounds oder Business-Entscheidungen, die technische Komplexität ignorieren.
Die Perspektive der Entscheider
Auf der anderen Seite sitzt der Entscheider –der, der das Gesamtbild im Blick hat und das Projekt im Hinblick auf Budget und Zeitrahmen steuert. Für ihn ist es weniger wichtig, ob der Code glänzt oder die Lösung auch in zehn Jahren noch funktioniert, sondern ob die Lösung fristgerecht auf dem Markt ist und der Return on Investment stimmt. Es ist der Moment, in dem der Entscheider seine Vision von Erfolg im Kopf hat: "Wenn wir das nicht in sechs Monaten auf den Markt bringen, macht es der Wettbewerb." Daher geht es dem Entscheider oft nicht schnell genug – und nicht selten übt er Druck auf das Expertenteam aus.
Um bei unserem Flugzeug-Beispiel zu bleiben: Es ist wie bei einem Flugzeug-Designer, der unter hohem Zeitdruck ein neues Modell entwickelt, dabei jedoch keine Gelegenheit hat, jedes kleine Detail oder die Feinabstimmung der Technik zu überprüfen. Das Wichtigste ist, dass das Flugzeug am Ende das Ziel erreicht, auch wenn die Triebwerke nicht rund laufen, die Aerodynamik nicht optimal ist und das Flugverhalten wacklig scheint.
Entscheider, oft in Management- oder Produktrollen, müssen wirtschaftliche und strategische Interessen vertreten. Ihr Ziel ist es, Projekte im Rahmen von Budget, Zeit und Unternehmenszielen zu realisieren. Sie suchen pragmatische Lösungen, die einen schnellen Mehrwert bieten, und haben nicht immer das technische Detailwissen, um alle Konsequenzen bestimmter Entscheidungen zu überblicken.
Typische Konflikte
- Technische Perfektion vs. Business-Pragmatismus: Experten wollen eine optimale, langfristig tragfähige Lösung, während Entscheider eher nach schnellen Ergebnissen suchen.
- Kommunikationslücken: Technische Details werden nicht verständlich vermittelt, während Business-Anforderungen für Entwickler oft unklar bleiben.
- Prioritäten und Zeitdruck: Experten benötigen Zeit für gründliche Analysen und saubere Implementierungen, Entscheider müssen schnelle Entscheidungen treffen.
Warum Technologie selten das Hauptproblem ist
Stellen wir uns vor, ein Projekt startet in einer Situation, die viele von uns kennen: Es geht los mit jeder Menge Meetings und alles läuft mehr oder weniger nach Plan. Doch dann kommt der Moment der Wahrheit: Der Code ist nicht so robust wie gewünscht, das System läuft langsamer als erwartet und plötzlich haben wir mit "Spaghetti-Code" zu kämpfen.
In einem großen Projekt sind es nicht nur die technischen Tools oder die Architektur, die bestimmen, ob es ein Erfolg wird. In meinen Jahren in der IT habe ich selten erlebt, dass ein Projekt an der Technologie selbst gescheitert ist. Schaut man sich den Chaos-Report der Standish Group an, so scheitert seit Jahrzehnten die Mehrzahl der IT-Projekte [1]. Das liegt laut Studie insbesondere unter anderem an genutzter Methodik, fehlender Einbindung der Fachseite, zu großen Teilschritten im Projekt, zu viel Bürokratie und Verwaltung und zu wenig Entscheidungen auf den richtigen Ebenen. Eine Untersuchung aus 2020 von McKinsey ergänzt zudem die durch IT-Entscheidern oftmals unterschätzte Komplexität von IT-Projekten, was zu deutlich höheren Kosten und längeren Projektlaufzeiten führt [2]. Selten jedoch scheitern IT-Projekte an der Eignung oder Art der eingesetzten Technologie.
Viel häufiger sind es vor allem menschliche Faktoren:
- Fehlendes Vertrauen: Experten fühlen sich übergangen, Entscheider fühlen sich blockiert.
- Mangelnde Transparenz: Entscheidungen werden getroffen, ohne alle relevanten Informationen zu berücksichtigen.
- Unterschiedliche Sprache: Experten sprechen in technischen Details, Entscheider in Business-KPIs.
Erfolgreiche IT-Projekte sind deshalb nicht nur ein technologisches, sondern vor allem ein organisatorisches und kulturelles Thema.
Best Practices für eine bessere Zusammenarbeit zwischen Entscheidern und Experten
Im Folgenden finden sich einige Best Practices in Bezug auf die Projektzusammenarbeit, die nach meiner Erfahrung zu mehr Erfolg in IT-Projekten führen können:
IT-Projekt: Gemeinsame Zieldefinition
Einer der häufigsten Fehler: keine gemeinsame Zieldefinition. Kein gemeinsames Einschwören auf ein größeres Bild und die Rahmenbedingungen, in die es eingebettet ist, inklusive der verschiedenen Verantwortlichkeiten. Das führt zu Missverständnissen, falschen Erwartungen und einer Menge zusätzlichem Aufwand später im Projekt. Daher lohnt sich am Anfang: ein gut vorbereitetes Kickoff-Meeting, in welchem Erwartungen übereinandergelegt werden, ein gemeinsames Ziel inklusive Rahmenbedingungen vereinbart wird und klare Rollen, Ablaufpläne und Zeiten festgelegt werden.
Themen, welche dort zwingend betrachtet werden sollten:
- Vorstellung, Erwartungen und Expertise aller Projektteilnehmer
- Projektziele (technisch, fachlich, wirtschaftlich etc.) & Umfang
- Zeitplan & Meilensteine
- Rollen & Verantwortlichkeiten
- Risiken & Herausforderungen
Übersetzungsarbeit im IT-Projekt: Technische Themen verständlich machen
Die Kunst der "Übersetzungsarbeit" ist, Technische Details verständlich zu machen und eine Sprache zu finden, die nicht nur das Tech-Team beherrscht, sondern auch Entscheider verstehen müssen. Das Ding ist: Beide müssen die Sprache des anderen lernen, ein bisschen so, als würde man einem Kind beibringen, wie man ein Flugzeug baut, ohne dass es weiß, was ein Schraubenschlüssel ist.
Hier einige Ideen aus der Praxis, die helfen können:
- Tech-Teams sollten
- sich in Geschäftsprozesse einarbeiten, um zu verstehen, warum gewisse Anforderungen bestehen (z. B. Kunden- und Vertriebsprozesse, Finanzen, Compliance & Sicherheit). Dabei helfen Shadowing-Projekte (z. B. für ein paar Stunden oder Tage "über die Schulter der Kollegin schauen"), 1-zu-1-Austausche zwischen verschiedenen Abteilungen, bei denen statt Wissen Einsicht in den Arbeitsalltag gegeben wird oder auch gemeinsame Anforderungsbeschreibungen aus verschiedenen Perspektiven.
- Entscheidern helfen, grundlegende Tech-Konzepte zu verstehen (z. B. durch kurze Workshops oder Info-Sessions mit visuellen Darstellungen und Demos, Verwenden von Analogien, Umformulieren von technischen Begriffen in Alltagssprache).
- Ihre Ergebnisse in Diskussionen in Geschäftswerten wiedergeben (z. B. "Kostenreduktion um X%").
- Entscheider sollten
- sich Zeit nehmen, technologische Grundlagen zu verstehen – zumindest auf einer konzeptionellen Ebene, um sinnvolle Diskussionen, Risiken und Entscheidungen zulassen und nachvollziehen zu können.
- Expertenmeinungen aktiv einholen bzw. einfordern, insbesondere wenn Risiken aufgezeigt werden.
- Mindestens einen technischen Stakeholder auf Expertenseite als Pendant haben, um die richtigen Entscheidungen treffen und absichern zu können.
Organisatorisch kann die Einführung von Übersetzungsrollen und Brückenbauern wie "Technical Product Manager" oder "Solution Architects" Sinn machen, die beide Welten verstehen und vermitteln können.
Agile Methoden als Brücke zwischen Experten und Entscheidern
Stell Dir vor, Du bist in einem klassischen Projektmanagement-Meeting und versuchst, ein Problem zu lösen, das noch nicht einmal klar definiert ist. Irgendwann fragst Du Dich: "Das haben wir doch schon hundertmal besprochen, oder?" Agile Methoden können hier den Unterschied machen. Sie bieten eine Plattform, auf der sich Experten und Entscheider regelmäßig austauschen können. Es ist wie ein ständiger Dialog zwischen einem Musiker und einem Komponisten, der sicherstellt, dass alle Teile des Projekts im Einklang sind. Wichtig dabei: Es gibt nicht nur das eine oder das andere, was funktioniert. Jedes Unternehmen, jedes Team, muss für sich den richtigen Ansatz und eine wirksame Methodik entwickeln, die mit der eigenen Kultur, den Projekten, dem Know-how und dem Mindset sinnstiftend ist. Nur weil man jetzt agil ist, heißt es noch lange nicht, dass alles wunderbar funktionieren wird.
Eine der wichtigsten Best Practices für eine effektive Zusammenarbeit zwischen Experten und Entscheidern ist es, regelmäßige, kurze Treffen während des Projekts zu vereinbaren, um den Fortschritt des Projekts zu überprüfen und mögliche Probleme frühzeitig zu erkennen. Diese Treffen sollten nicht nur zur Statusabgleichung dienen, sondern auch als Austauschplattform, um sicherzustellen, dass beide Seiten die gleichen Ziele verfolgen.
Beispiel aus der Praxis: In unserem Unternehmen wurde jahrelang klassisch im Wasserfallmodell gearbeitet – und das funktionierte hervorragend für Projekte mit glasklar formulierten Anforderungen, die sich nicht ändern. Schwieriger ist die Umsetzung in Projekten, in denen sich die Anforderungen über den Projektablauf verändern und die Spezifikation erst auf dem Weg entsteht – gefragt z. B. insbesondere bei der Neuentwicklung von Produkten unter hohem Zeitdruck. Hier sind ständige Erweiterungen, neue Learnings, Change Requests und stetige Verbesserungen an der Tagesordnung. In einem solchen Falle eignen sich Scrum oder andere agile Methoden, die eine neue Denkweise bringen: die Interaktion der verschiedenen, am Projekt beteiligten Personen, steht im Mittelpunkt. Bei der Entwicklung einer SaaS-Lösung für AR-Wissensdokumentation kombinierten wir bewährte Praktiken beider Modelle und kamen so zu einer für uns sehr gut funktionierenden Lösung. Kurze regelmäßige Abstimmungsmeetings zur Klärung von Fragen, Sprints nach Scrum-Methodik und eine transparente und flexible Dokumentation und Anforderungsbeschreibung beschleunigten die Zusammenarbeit des Teams maßgeblich.
IT-Projekt: Frühzeitig Risiken identifizieren und ansprechen
Sowohl für Entscheider als auch für Experten ist es entscheidend, Risiken frühzeitig zu identifizieren und anzusprechen. Das bedeutet, dass Experten nicht nur ihre Bedenken bezüglich der Technik äußern, sondern auch transparent auf mögliche Probleme hinweisen müssen, die sich in der Zukunft zeigen könnten. Ebenso sollten Entscheider bereit sein, mögliche Probleme aus der Geschäftsperspektive zu benennen und Lösungen zu priorisieren. Und das von beiden Seiten so ehrlich und respektvoll wie möglich – ohne das Gesicht verlieren zu müssen.
Ein funktionierendes System für kontinuierliches Feedback ist von entscheidender Bedeutung für die Zusammenarbeit zwischen Experten und Entscheidern. Während Entwickler sich in der Regel auf technische Details konzentrieren, müssen Entscheider sicherstellen, dass das Feedback sowohl in technischer als auch in wirtschaftlicher Hinsicht relevant ist.
Wie kann das konkret aussehen?
- Permanente Identifikation und Bewertung von Risiken über den gesamten Projektablauf in einer Risikomatrix (Dimensionen: Eintrittswahrscheinlichkeit, Auswirkung, Priorisierung) [3]
- Maßnahmenplanung zur Vermeidung und Minderung von Risiken bzw. für den Notfall (inklusive Verantwortlichkeiten)
- Kommunikation mit involvierten Stakeholdern
Beispiel aus der Praxis: In einem großen Software-Projekt zur Einführung einer neuen Software wurde ein Risiko nicht ernst genommen, welches die Skalierbarkeit der Anwendung betraf. Der Entwickler wies darauf hin, dass die Datenbankarchitektur bei steigender Nutzerzahl Probleme verursachen würde. Der Entscheider dachte jedoch, dass die Leistung erst bei einer späteren Ausbaustufe ein Problem werden würde und ignorierte den Hinweis. Fazit: Drei Monate nach dem Go-Live war das System bei den ersten hundert Nutzern instabil. Hier hätte ein gemeinsames Risikomanagement, das von Anfang an klare Kommunikationswege und Verantwortlichkeiten definiert, möglicherweise geholfen, dieses Problem zu vermeiden.
IT-Projekt: Kreativität fördern, miteinander sprechen und Raum für innovative Lösungen schaffen
In einem von mir begleiteten Projekt zur Einführung einer neuen Web-Applikation gab es eine Debatte über die Architektur. Das Management bevorzugte einen monolithischen Ansatz, da er eine schnellere Markteinführung ermöglichte. Die Entwickler und Solution-Architekten hingegen plädierten für Microservices, da diese langfristig flexibler und skalierbarer sind – allerdings mit mehr Initial-Aufwand verbunden waren. Letztendlich entschied sich das Management für den Monolithen, doch das Tech-Team schlug noch während des Entscheidungsmeetings einen Kompromiss vor: Kritische Kernfunktionen blieben monolithisch, während weniger zentrale Komponenten als Microservices umgesetzt wurden. Dadurch konnte das Produkt zügig starten, ohne die Skalierbarkeit völlig zu vernachlässigen. Nach der Einführung zeigte sich, dass die monolithischen Teile schwer anpassbar waren, weshalb das Management schließlich die schrittweise Umstellung auf Microservices genehmigte. Das Projekt bewies, dass erfolgreiche Zusammenarbeit auf Offenheit, gegenseitigem Verständnis und Flexibilität basiert – statt auf starren Entscheidungen. Das Projekt wurde im Unternehmen als kurz- sowie langfristiger Erfolg angesehen und führte zu deutlich mehr Vertrauen zwischen den beteiligten Teams.
Die Zusammenarbeit zwischen Experten und Entscheidern kann dann besonders erfolgreich sein, wenn es beiden Seiten ermöglicht wird, kreativ zu denken und innovative Lösungen zu entwickeln. Das bedeutet nicht, dass man ständig die "beste" Lösung finden muss, sondern vielmehr, dass man Raum für neue Ideen lässt und den Dialog zwischen den kreativen Denkweisen fördert. Auch gemeinsame Teamevents, die den Zusammenhalt stärken, sollten dabei in Betracht gezogen werden. Denn wer einmal zusammen ein Floß gebaut, eine Wurst gegrillt oder Beachvolleyball gespielt hat, baut eine andere Basis für die Zusammenarbeit.
Zusammenfassung der Best Practices
Gemeinsame Zieldefinition
- Klare und realistische Projektziele formulieren, die sowohl technische als auch wirtschaftliche Anforderungen berücksichtigen
- Alle Beteiligten frühzeitig einbinden, um Missverständnisse zu vermeiden
Übersetzungsarbeit: Technische Themen verständlich machen
- Entwickler sollten lernen, ihre Lösungen in Geschäftswerten zu erklären (z. B. "Diese Architektur reduziert Wartungskosten um 30%")
- Entscheider sollten ein Grundverständnis für technische Konzepte entwickeln, um fundierte Entscheidungen treffen zu können
Transparente Entscheidungsprozesse
- Entscheidungen sollten nicht einseitig getroffen, sondern durch Austausch zwischen beiden Seiten fundiert werden
- Risiken, Trade-offs und langfristige Folgen von Entscheidungen klar kommunizieren
Vertrauen und Empathie stärken
- Regelmäßige Workshops und gemeinsame Meetings helfen, gegenseitiges Verständnis aufzubauen
- Respekt und Wertschätzung für beide Rollen fördern, anstatt eine "Wir-gegen-die"-Mentalität entstehen zu lassen
- In kreativen Raum vertrauen und Initiativen fördern
Agile Methoden als Brücke zwischen Experten und Entscheidern
- Iterative Entwicklungsprozesse helfen, schrittweise Feedback einzuholen, Risiken zu identifizieren und Fehlentwicklungen frühzeitig zu erkennen
- Stand-up-Meetings, Sprint Reviews und Retrospektiven ermöglichen eine kontinuierliche Kommunikation zwischen technischen und nicht-technischen Stakeholdern
- Agile Rollen wie der Product Owner helfen, Business-Ziele und technische Realitäten miteinander zu verknüpfen
Entscheider auf den diesjährigen IT-Tagen
Spannende Vorträge und Workshops zu Entscheider-Themen erwarten Euch auch auf den IT-Tagen, der Jahreskonferenz von Informatik Aktuell. Die IT-Konferenz findet jedes Jahr im Dezember in Frankfurt statt – dieses Jahr vom 08.-11.12.
Fazit: Mensch, Technologie und Prozess im Zusammendenken
Erfolgreiche IT-Projekte entstehen, wenn Experten und Entscheider als Partner arbeiten und nicht als zwei Fronten, die gegeneinander kämpfen. Es geht darum, die richtige Balance zwischen Technologie und Prozess zu finden, damit das Team gemeinsam an einem Strang zieht. Wenn wir diese Prinzipien beherzigen, können wir nicht nur bessere Ergebnisse erzielen, sondern auch eine nachhaltige Zusammenarbeit aufbauen, die den Projekterfolg langfristig sichert und die Menschen selbst nachhaltig stärkt.
Meine wichtigsten Learnings:
- Technische Exzellenz und Business-Prioritäten sind kein Widerspruch – wenn beide Seiten offen kommunizieren und gemeinsam zielorientiert wirken
- Transparenz und gegenseitiges Verständnis sind entscheidend – nur so können fundierte Entscheidungen getroffen werden
- Prozesse müssen Menschen unterstützen, nicht behindern – eine gute Balance zwischen Flexibilität und Struktur ist entscheidend
- Agile Methoden helfen, Kommunikation und Zusammenarbeit zu verbessern – indem sie iterative Entwicklung und enge Abstimmung ermöglichen
- Gegenseitiger Respekt ist die Basis erfolgreicher IT-Projekte – Experten und Entscheider sind aufeinander angewiesen und sollten sich auch so behandeln
- Erfolgreiche Zusammenarbeit wird durch kreatives Denken und Innovation gefördert – Beide Seiten sollten frei im Finden der bestmöglichen Lösung auf dem gemeinsamen Weg zum Ziel sein
Wenn wir Mensch, Technologie und Prozess als Einheit betrachten, entstehen nicht nur bessere IT-Projekte, sondern auch eine stärkere Zusammenarbeit, die langfristigen Erfolg sichert und dabei auch noch Spaß macht.
- The Standish Group: Chaos Report 2020
- McKinsey: Managing large technology programs in the digital era
- Nohl, Thiemecke: Systematik zur Durchführung von Gefährdungsanalysen. Hrsg.: Bundesanstalt für Arbeitsschutz
