Früher war klar, wie Kommunikation im Projekt lief. Einmal pro Woche Statusmeeting, dazu
ein Protokoll per Mail. Heute prasseln Informationen über Chat, Ticketsystem,
Video-Calls, Projektplattform und Präsentationen auf dich ein. Du sollst Entscheidungen
vorbereiten, Risiken einschätzen und Termine halten. Gleichzeitig bist du unsicher, ob
alle dasselbe Bild vor Augen haben. Genau an dieser Stelle lohnt sich ein nüchterner
Blick auf Kommunikationsmuster zwischen Finanz- und IT-Teams.
Statt sofort
ein neues Tool einzuführen, kannst du mit einer einfachen Beobachtung beginnen. Wo
entstehen die wichtigsten Entscheidungen. Im Jour fixe. Im Chat. Im stillen
Zweiergespräch zwischen Projektleitung und Fachbereich. Und an welcher Stelle werden
diese Entscheidungen dokumentiert. Oft klafft hier eine Lücke. Das Gespräch findet im
kleinen Kreis statt, die Folgen landen später als technische Anforderung im
Ticketsystem, während der Finanzbereich glaubt, es sei nur eine unverbindliche Idee
gewesen.
Um diese Lücke sichtbar zu machen, hilft eine kleine
Vergleichstabelle. In der ersten Spalte listest du typische Situationen: neue Kennzahl,
zusätzliche Datenquelle, Anpassung an regulatorische Vorgaben, Verschiebung eines
Meilensteins. In der zweiten Spalte notierst du, über welchen Kanal das Thema
üblicherweise startet. In der dritten, in welchem Format die Entscheidung am Ende
vorliegt. Häufig siehst du dann Muster wie: Start im Chat, Entscheidung im Meeting,
Dokumentation im Ticket. Oder: Start im Mail-Thread, Entscheidung im Lenkungskreis,
Dokumentation in einer Präsentation, die niemand wiederfindet.
Im Finanz- und
IT-Umfeld verstärken sich solche Muster schnell. Finanzteams formulieren gern in
Berichtslogik: Kennzahlen, Fristen, Auswirkungen auf Abschlüsse. IT-Teams denken in
Systemlogik: Releases, Abhängigkeiten, technische Schulden. Wenn beide Seiten ihre
Sprache unverändert in denselben Kanal kippen, entstehen Missverständnisse fast
automatisch. Der Satz wir brauchen diese Kennzahl ab dem nächsten Quartal kann für
Finanzseite eine fachliche Notwendigkeit bedeuten, für IT-Seite jedoch eine technische
Großbaustelle. Ohne gemeinsame Übersetzung landet beides als scheinbar gleichwertige
Anforderung im Backlog.
Ein pragmatischer Schritt besteht darin, bestimmte
Themenarten bewusst an bestimmte Formate zu binden. Zum Beispiel: fachliche Ideen dürfen
im Chat entstehen, Entscheidungen zu Systemänderungen fallen jedoch nur in Terminen mit
klarer Agenda und werden direkt in einem beschreibbaren Format festgehalten. Wichtig
ist, dass du diese Spielregeln nicht als starres Regelwerk verkaufst, sondern als
Versuch, Reibung zu reduzieren. Ergebnisse können sich unterscheiden, je nach Kultur und
Größe deiner Organisation. Entscheidend ist, dass du überhaupt sichtbar machst, wo
Kommunikation heute läuft und wo sie unterwegs ihre Form ändert.
Im nächsten Schritt geht es um Rollen. Früher gab es den Projektleiter, vielleicht noch
einen Fachvertreter. Heute triffst du auf Product Owner, Process Owner, Data Stewards,
Solution Architects. Alle kommunizieren, alle sammeln Informationen, alle fühlen sich
für etwas verantwortlich. Trotzdem bleiben wichtige Punkte liegen oder werden doppelt
diskutiert. Die Frage ist daher weniger, wer welchen Titel trägt, sondern wer welche
Kommunikationsaufgabe hat.
Du kannst dazu ein einfaches Raster nutzen. In der
ersten Spalte stehen wiederkehrende Kommunikationssituationen: Entscheidung vorbereiten,
Entscheidung herbeiführen, Entscheidung dokumentieren, Entscheidung nachhalten. In der
zweiten Spalte listest du die beteiligten Rollen. In der dritten markierst du, wer
primär zuständig ist, wer unterstützt und wer nur informiert wird. Dieses Raster ersetzt
kein Organigramm, aber es macht deutlich, warum manche Meetings überfüllt sind, während
an anderer Stelle wichtige Personen fehlen.
Ein Beispiel aus einem typischen
Reporting-Projekt. Die Finanzseite formuliert den Wunsch nach einer neuen Auswertung.
Die IT-Seite bewertet Aufwand und Risiken. Im Meeting sitzen CFO-Vertretung,
Projektleitung, Product Owner, Architekt, manchmal noch externe Partner. Am Ende scheint
Einigkeit zu bestehen, doch zwei Wochen später taucht der Punkt erneut auf. Diesmal mit
leicht veränderten Argumenten. Der Grund: Niemand fühlte sich zuständig, die
Entscheidung sauber zu dokumentieren und in die Arbeitsplanung zu übersetzen. Das
Protokoll blieb vage, das Ticket wurde unklar formuliert, der Kontext ging verloren.
In
solchen Situationen hilft eine bewusst zugewiesene Kommunikationsrolle. Jemand, der
nicht die fachliche oder technische Entscheidung trifft, sondern dafür sorgt, dass diese
Entscheidung nachvollziehbar festgehalten wird. Wer das sein sollte, hängt von deiner
Organisation ab. Wichtig ist nur, dass die Aufgabe sichtbar ist. Sonst landet sie
unausgesprochen bei der Person, die ohnehin schon am meisten redet. Und genau dort
entstehen Verzerrungen: bestimmte Argumente werden stärker gewichtet, andere
verschwinden zwischen den Zeilen.
Kommunikation zwischen Finanz- und IT-Teams
gewinnt, wenn du Rollen nicht nur nach fachlichen Kompetenzen, sondern auch nach
Kommunikationsaufgaben sortierst. Wer erklärt Entscheidungen nach oben. Wer übersetzt
sie für operative Teams. Wer achtet darauf, dass Annahmen zur Datenlage mit der Realität
in Systemen und Prozessen abgeglichen werden. Wenn du diese Fragen klarer beantwortest,
sinkt die Zahl der Missverständnisse deutlich. Nicht auf null, aber spürbar.
Schließlich geht es um Rhythmus. Früher gab es Monats- und Quartalszyklen, an denen sich
alles ausrichtete. Heute treffen Release-Pläne der IT auf Abschlusskalender der
Finanzseite, dazu kommen Ad-hoc-Anfragen aus Management und Fachbereichen. Wenn die
Kommunikationsrhythmen dieser Welten nicht zusammenpassen, wirken alle Beteiligten
gestresst, obwohl sie viel reden. Die Kunst besteht darin, wenige verlässliche Takte zu
etablieren, statt immer neue Ad-hoc-Runden zu eröffnen.
Ein Ansatz besteht
darin, Kommunikationsformate entlang dreier Zeithorizonte zu ordnen. Kurzfristig geht es
um operative Abstimmungen: Was passiert in den nächsten Tagen. Welche Änderungen
berühren den laufenden Abschluss. Welche Tickets sind kritisch. Mittelfristig dreht sich
alles um die nächsten Wochen und Monate: Welche Releases stehen an, welche Projekte
greifen ineinander, welche Ressourcen werden knapp. Langfristig schließlich geht es um
Grundsatzfragen: Architektur, Zielbild, Governance-Strukturen.
Für jeden
dieser Horizonte definierst du ein zentrales Format. Zum Beispiel ein kurzes,
fokussiertes Weekly zwischen Finanz- und IT-Vertretung für operative Punkte. Ein
monatliches Planungsgespräch für die mittlere Sicht. Und ein selteneres, dafür
gründlicher vorbereitetes Forum für langfristige Weichenstellungen. Wichtig ist, dass du
nicht einfach bestehende Meetings umbenennst, sondern klärst, welche Fragen in welchem
Format beantwortet werden. So vermeidest du, dass operative Details in strategischen
Runden dominieren oder umgekehrt.
Hilfreich ist auch hier eine kleine
Vergleichstabelle. In der ersten Spalte listest du deine aktuellen Meetings und
Kommunikationskanäle. In der zweiten hältst du fest, welchem Zeithorizont sie faktisch
dienen. In der dritten notierst du, welche Entscheidungen dort typischerweise fallen.
Häufig zeigt sich, dass viele Formate denselben Zweck erfüllen, während andere Lücken
offen bleiben. Genau dort kannst du ansetzen, statt überall gleichzeitig zu
optimieren.
Am Ende wirst du keine perfekte Kommunikationslandschaft
zeichnen. Zu viele Abhängigkeiten, zu viele spontane Anforderungen, zu viele
individuelle Stile. Aber du kannst Muster sichtbarer machen und damit bewusster
gestalten, wie Finanz- und IT-Teams miteinander sprechen. Kleine Änderungen, wie klare
Entscheidungsformate, definierte Kommunikationsrollen und abgestimmte Rhythmen, wirken
oft stärker als das nächste Tool. Ergebnisse können je nach Organisation unterschiedlich
ausfallen. Wichtig ist, dass du sie beobachtest, vergleichst und bereit bist, Formate
anzupassen, wenn sie ihren Zweck nicht mehr erfüllen.
