Wie lässt sich die gesamte Kommunikation eines Projektteams zentral organisieren?

Ein Projektentscheid wird im Meeting getroffen, im Chat präzisiert und später per E-Mail bestätigt. Einige Wochen danach ist unklar, welche Vereinbarung tatsächlich gilt. Noch schwieriger wird es, wenn niemand mehr weiss, wer die Umsetzung übernehmen sollte. Solche Situationen entstehen nicht zwingend durch mangelnde Disziplin, sondern häufig durch eine Kommunikation ohne verbindlichen gemeinsamen Informationsstand.

Die gesamte Projektkommunikation zentral zu organisieren bedeutet nicht, sämtliche Gespräche in ein einziges Werkzeug zu verlagern. Entscheidend ist, dass relevante Informationen, Beschlüsse, Aufgaben und Änderungen an einem definierten Ort verbindlich dokumentiert werden. E-Mail, Chat und Meetings können weiterhin ihre jeweiligen Funktionen erfüllen.

Für Projektleitende in der Schweiz ist diese Unterscheidung besonders relevant, wenn interne Teams, externe Dienstleister und Kunden über verschiedene Standorte und Sprachgrenzen hinweg zusammenarbeiten. Eine funktionierende Kommunikationsstruktur muss deshalb nicht nur Informationen zugänglich machen, sondern auch Verantwortlichkeiten, Entscheidungen und deren Begründungen erhalten.

Warum gehen Projektinformationen zwischen E-Mail, Chat und Meetings verloren?

Projektinformationen gehen verloren, wenn Entscheidungen, Begründungen und Zuständigkeiten über mehrere Kommunikationskanäle verteilt bleiben, ohne an einem verbindlichen Ort zusammengeführt zu werden. Häufig existieren die Informationen weiterhin, lassen sich aber nicht mehr zuverlässig rekonstruieren. Besonders problematisch ist, wenn zwar ein Beschluss auffindbar bleibt, die verantwortliche Person jedoch unbekannt ist.

Der typische Informationsverlust entsteht schrittweise. In einer Besprechung einigen sich Beteiligte auf eine neue Lieferfrist. Anschliessend diskutieren zwei Personen im Chat über technische Voraussetzungen. Die Projektleitung informiert den Kunden per E-Mail über das Ergebnis. Jeder Kanal enthält einen Ausschnitt, aber keiner dokumentiert die vollständige Entscheidung.

Bei späteren Rückfragen muss das Team unterschiedliche Nachrichten, Sitzungsnotizen und Dateiversionen vergleichen. Dabei kann eine wichtige Einschränkung übersehen werden, obwohl sie ursprünglich korrekt kommuniziert wurde.

Es lohnt sich, zwei Arten von Informationsverlust zu unterscheiden. Beim inhaltlichen Informationsverlust fehlen entscheidende Angaben zum vereinbarten Vorgehen. Beim Verantwortlichkeitsverlust lässt sich nicht mehr feststellen, wer einen Beschluss freigegeben oder eine Aufgabe übernommen hat.

Gerade an den Schnittstellen zwischen mehreren Unternehmen kann die zweite Form weitreichende Folgen haben. Wenn eine Lieferung aussteht, reicht es nicht zu wissen, dass sie besprochen wurde. Es muss auch erkennbar sein, wer die Lieferung schuldet, wer sie abnimmt und welche Frist vereinbart wurde.

Ein hypothetisches Beispiel aus einem mehrsprachigen Schweizer Projektteam verdeutlicht das Risiko: Die deutschsprachige Projektleitung bespricht eine Änderung mit einem französischsprachigen Kunden. Ein englischsprachiger Entwicklungspartner erhält anschliessend lediglich eine kurze Chat-Nachricht. Ohne gemeinsames Entscheidungsprotokoll können unterschiedliche Vorstellungen über Umfang und Termin bestehen bleiben.

Ein einfacher Selbsttest macht die Schwachstelle sichtbar: Wähle drei ältere Projektentscheidungen aus und rekonstruiere jeweils das Ergebnis, die Begründung und die zuständige Person. Halte fest, wie viele Kanäle und Dokumente dafür durchsucht werden müssen. Die Zahl ist kein allgemein gültiger Qualitätsmassstab, zeigt im eigenen Teamvergleich aber, wie aufwendig der Informationszugriff geworden ist.

Entscheidend ist nicht, jedes Gespräch dauerhaft aufzubewahren. Wesentlich ist, die verbindlichen Ergebnisse aus diesen Gesprächen herauszulösen und an einem gemeinsamen Ort verfügbar zu machen. Dafür braucht es klare Kommunikationsregeln.

Wie definiert man Kommunikationsregeln, damit jeder Kanal eine klare Funktion hat?

Kommunikationsregeln funktionieren, wenn für jeden Kanal verbindlich festgelegt ist, welche Informationen dort bearbeitet werden dürfen, welche Ergebnisse zentral dokumentiert werden müssen und wer diese Übertragung übernimmt. Zusätzlich braucht das Team klare Antworterwartungen und einen Umgang mit Ausnahmen. Erst dadurch wird aus einer informellen Gewohnheit eine verlässliche Projektvereinbarung.

Die wichtigste Grundlage ist eine Kanalmatrix. Sie beschreibt nicht nur erlaubte Verwendungszwecke, sondern auch Informationen, für die ein Kanal ausdrücklich nicht als verbindliche Ablage gilt.

Ein mögliches Regelwerk sieht folgendermassen aus:

Das zugrunde liegende Prinzip lautet Single Source of Truth: Das Projekttool gilt als massgebliche Quelle für den aktuellen Projektstand. Andere Kanäle dürfen weiterhin Diskussionen enthalten. Eine Änderung des verbindlichen Projektstands muss jedoch im festgelegten System dokumentiert und, falls nötig, freigegeben werden.

Wichtig ist dabei die Trennung zwischen dem Ort der Kommunikation und der Gültigkeit einer Vereinbarung. Eine telefonische Kundenbestätigung kann beispielsweise vertraglich relevant sein, auch wenn sie noch nicht ins Projekttool übertragen wurde. Die interne Dokumentationsregel ersetzt keine vertraglichen oder gesetzlichen Formvorschriften.

Besondere Aufmerksamkeit verdienen Ausnahmen. Wird eine Entscheidung telefonisch oder während eines informellen Gesprächs getroffen, muss eine zuvor benannte Person den Beschluss dokumentieren. Das Team sollte festlegen, wie schnell dies erfolgt und wer die Richtigkeit bestätigt. Als interne Praxis kann beispielsweise vereinbart werden, die Dokumentation spätestens am folgenden Arbeitstag abzuschliessen.

Ebenso wichtig sind Verhaltensregeln. Nicht jede Chat-Nachricht darf eine sofortige Reaktion verlangen. Das Team sollte zwischen normalen Rückfragen, zeitkritischen Blockaden und tatsächlichen Notfällen unterscheiden. Nur für letztere ist ein ausdrücklicher Eskalationsweg sinnvoll.

Die Regeln sollten kurz genug sein, um im Alltag tatsächlich angewendet zu werden. Erst danach lohnt sich die detaillierte Entscheidung, welche Informationen im Chat, per E-Mail oder unmittelbar im Projekttool bearbeitet werden.

Chat, E-Mail oder Projekttool: Welcher Kanal eignet sich für welche Information?

Der geeignete Kommunikationskanal hängt vor allem von drei Kriterien ab: der Lebensdauer einer Information, ihrer Zielgruppe und dem Bedarf an späterer Nachvollziehbarkeit. Kurzfristige Abstimmungen gehören meist in den Chat, formelle externe Mitteilungen häufig in die E-Mail und dauerhaft projektrelevante Informationen in das Projekttool. Entscheidend ist der Zweck, nicht die vermeintliche Wichtigkeit eines Werkzeugs.

Eine praktische Entscheidungshilfe beginnt mit der Frage, wie lange eine Information benötigt wird. Eine kurze Rückfrage zur heutigen Besprechungszeit ist anders zu behandeln als eine geänderte Abnahmefrist, auf die das Team noch Monate später zurückgreifen muss.

Danach folgt die Zielgruppe: Betrifft die Information nur zwei Personen in einer laufenden Abstimmung oder muss sie für eine bestimmte Rolle auch nach einem Personalwechsel zugänglich bleiben?

Das dritte Kriterium ist der Revisionsbedarf. Muss später überprüft werden können, wer eine Änderung freigegeben hat, reicht ein flüchtiger Chat-Verlauf als alleinige Projektdokumentation in der Regel nicht aus.

Ein häufiger Fehlschluss besteht darin, E-Mail grundsätzlich als offiziellen Speicherort zu betrachten. Sie kann für bestimmte Mitteilungen und Nachweise erforderlich sein, ist aber als alleinige Übersicht über Aufgaben und laufende Projektänderungen unpraktisch. Persönliche Postfächer erzeugen parallele Informationsbestände, die nicht automatisch allen Beteiligten zugänglich sind.

Auch der Chat hat eine klare Grenze. Sobald eine Nachricht eine neue Aufgabe, einen geänderten Termin oder eine Kostenentscheidung enthält, braucht es einen Übergang in den verbindlichen Projektstand. Idealerweise ergänzt die dokumentierende Person zugleich den Kontext und verknüpft den ursprünglichen Gesprächsverlauf, soweit Datenschutz und Zugriffsrechte dies erlauben.

In regulierten Schweizer Unternehmen muss zusätzlich geprüft werden, welche Kommunikation besonderen Dokumentations- oder Aufbewahrungspflichten unterliegt. Für bestimmte Geschäftsunterlagen erläutert das SECO im offiziellen KMU-Portal zur elektronischen Aufbewahrung der Geschäftsbücher die Anforderungen nach Obligationenrecht und Geschäftsbücherverordnung.

Nach Artikel 958f OR gelten für die dort bezeichneten Geschäftsunterlagen grundsätzlich zehn Jahre Aufbewahrungsfrist. Daraus folgt jedoch keine allgemeine zehnjährige Aufbewahrungspflicht für sämtliche Projekt-Chats, E-Mails oder Sitzungsnotizen. Auch eine gewöhnliche Speicherung im Projekttool erfüllt nicht automatisch die Anforderungen an die rechtskonforme Archivierung.

Die Kanalwahl legt damit fest, wo eine Information entsteht und wo sie verbindlich weitergeführt wird. Ob ein Projektentscheid später verständlich bleibt, hängt allerdings zusätzlich von der Qualität seiner Dokumentation ab.

Welche Kommunikationsfehler machen Projektentscheide später nicht mehr nachvollziehbar?

Projektentscheide werden schwer nachvollziehbar, wenn ihre Begründung fehlt, sie ausschliesslich in persönlichen Kommunikationskanälen liegen, mehrere widersprüchliche Versionen existieren oder mündliche Änderungen nicht dokumentiert werden. In allen vier Fällen kann das Team den tatsächlichen Entscheidungsstand verlieren, obwohl einzelne Nachrichten und Dateien weiterhin vorhanden sind.

Die Fehler lassen sich anhand charakteristischer Anzeichen erkennen:

• Entscheidung ohne Begründung: Der Beschluss ist gespeichert, aber niemand kann erklären, warum eine Alternative verworfen wurde.
• Entscheidung im privaten Kanal: Eine wichtige Zusage liegt ausschliesslich in einer Direktnachricht oder einem nicht mehr zugänglichen Chat.
• Konkurrierende Versionen: Zwei Dokumente beanspruchen gleichzeitig, den aktuellen Projektstand wiederzugeben.
• Undokumentierte mündliche Änderung: Beteiligte arbeiten nach einer neuen Absprache, während der zentrale Projekteintag unverändert bleibt.

Besonders folgenreich ist die Verwechslung zwischen dem Ergebnis und seiner Begründung. Ein Eintrag wie «Variante B freigegeben» beschreibt zwar, was entschieden wurde, liefert aber keinen Hinweis darauf, weshalb Variante A nicht infrage kam.

Bei einem späteren Personalwechsel kann das dazu führen, dass bereits abgeschlossene Diskussionen erneut geführt werden. Eine brauchbare Entscheidungsdokumentation enthält deshalb mindestens den Beschluss, seinen wesentlichen Grund, das Datum, die zuständige Entscheidungsrolle und die betroffenen Projektvorgänge.

Ein weiteres Risiko ist die stille Aktualisierung. Beispielsweise wird in einem Telefonat vereinbart, die Prüfung einer Lieferung zu verschieben. Die Beteiligten handeln entsprechend, doch im Projekttool bleibt der ursprüngliche Termin stehen. Der dokumentierte Stand ist nun nicht mehr mit der tatsächlich praktizierten Vereinbarung identisch.

Dagegen hilft eine Regel, nach der jede wesentliche Änderung den zentralen Projekteintag aktualisieren muss. Falls die Änderung eine formelle Freigabe erfordert, wird sie erst nach dieser Freigabe als verbindlicher Projektstand übernommen.

Bei Projekten mit mehreren Auftragnehmern können widersprüchliche Dokumentationsstände auch vertragliche Streitigkeiten erschweren. Eine nachvollziehbare Projekthistorie kann helfen, Absprachen und Verantwortlichkeiten zu belegen. Sie ersetzt jedoch weder die Prüfung der einschlägigen Verträge noch gesetzlich erforderliche Nachweise.

Es lohnt sich, diese Fehler nicht erst bei einem Konflikt zu untersuchen. Wenn sie wiederholt auftreten, deutet dies darauf hin, dass die vorhandene Kommunikationsstruktur überprüft werden sollte.

Wann sollte ein Team seine Projektkommunikation neu strukturieren?

Ein Team sollte seine Projektkommunikation neu strukturieren, wenn wiederholt Informationen gesucht werden müssen, Zuständigkeiten unklar bleiben oder mehrere Kommunikationswege widersprüchliche Projektstände erzeugen. Besonders sinnvoll ist eine Überprüfung bei starkem Teamwachstum, zusätzlichen Projekten, neuen Kundenanforderungen oder personellen Wechseln. Entscheidend sind erkennbare Schwierigkeiten im Arbeitsalltag, nicht die Anzahl verwendeter Tools allein.

Bestimmte Veränderungen erhöhen den Koordinationsbedarf. Wächst ein kleines Projektteam deutlich, reichen persönliche Absprachen häufig nicht mehr aus. Kommt ein zweites Projekt hinzu, müssen Aufgaben und Nachrichten eindeutig zugeordnet werden. Verlangt ein Kunde eigene Berichtswege, entsteht eine zusätzliche Schnittstelle zwischen interner Steuerung und externer Kommunikation.

Ein besonders dringender Anlass ist der Weggang einer Schlüsselperson ohne vollständige Informationsübergabe. In diesem Fall sollten laufende Entscheidungen, Aufgaben und offene Freigaben zuerst gesichert werden, bevor die Struktur umfassend verändert wird.

Ein kurzer Diagnose-Check hilft bei der Einschätzung. Achte beispielsweise auf folgende Symptome:

• Bereits beantwortete Projektfragen werden regelmässig erneut gestellt.
• Besprechungen dienen überwiegend dazu, unterschiedliche Informationsstände abzugleichen.
• Die aktuelle Fassung wichtiger Dokumente lässt sich nicht eindeutig bestimmen.
• Aufgaben werden mehrfach nachgefragt, weil ihre Zuständigkeit nicht ersichtlich ist.

Wenn zwei oder mehr dieser Symptome über mehrere Wochen bestehen, ist eine gezielte Strukturanalyse sinnvoll. Diese Schwelle ist eine praktische Orientierung, kein wissenschaftlich validierter Grenzwert. Sie hilft lediglich, wiederkehrende Probleme von einzelnen Ausnahmen zu unterscheiden.

Ein vorschneller Werkzeugwechsel behebt die Ursachen selten allein. Werden im bisherigen System Entscheidungen nicht dokumentiert, kann dasselbe Verhalten in einer neuen Anwendung auftreten. Deshalb sollte die Reihenfolge lauten: zuerst Kommunikations- und Verantwortlichkeitsregeln überarbeiten, dann die technische Unterstützung beurteilen.

Für die Umstellung empfiehlt sich ein abgegrenztes Pilotprojekt. Dort werden die neuen Regeln zunächst erprobt, Zuständigkeiten überprüft und notwendige Anpassungen vorgenommen. Anschliessend legt die Projektleitung einen klaren Stichtag fest.

Eine mögliche Übergangsregel lautet: Ab dem festgelegten Datum werden alle neuen Projektergebnisse ausschliesslich im neuen verbindlichen System dokumentiert. Bestehende Unterlagen bleiben während einer definierten Übergangsphase lesbar; erforderliche offene Vorgänge werden gezielt übernommen. Eine unkontrollierte parallele Pflege beider Systeme sollte vermieden werden.

Nach einer erfolgreichen Umstellung rückt eine weitere Frage in den Mittelpunkt: Wie müssen Projektinformationen aufgebaut sein, damit Änderungen nicht nur gespeichert, sondern auch unmittelbar erkennbar werden?

Wie organisiert man Projektinformationen, damit Änderungen sofort nachvollziehbar sind?

Projektinformationen bleiben nachvollziehbar, wenn Aufgaben, Dokumente, Entscheidungen und Änderungen miteinander verknüpft werden. Jeder relevante Vorgang sollte seinen aktuellen Status, eine verantwortliche Person und eine verständliche Änderungshistorie enthalten. Zusätzlich müssen betroffene Beteiligte über wesentliche Anpassungen informiert werden. Eine gespeicherte Änderung allein bedeutet noch nicht, dass sie im Team angekommen ist.

Ein hilfreiches Organisationsprinzip lautet: Die Information folgt der Aufgabe. Statt Projektunterlagen ausschliesslich nach Monaten oder allgemeinen Themen zu sortieren, werden sie direkt dem betreffenden Vorgang zugeordnet.

Bei einer geänderten Kundenanforderung sollte deshalb die entsprechende Aufgabe sowohl die aktuelle Spezifikation als auch die dokumentierte Entscheidung, ihre Begründung und die relevanten Freigaben enthalten. Wer den Vorgang öffnet, muss nicht zuerst mehrere Ordner oder Nachrichtenverläufe durchsuchen.

Eine brauchbare Änderungshistorie beantwortet vier Fragen:

• Was wurde geändert?
• Wer hat die Änderung vorgenommen oder freigegeben?
• Wann ist sie erfolgt?
• Warum war sie notwendig?

Technische Versionsverwaltungen können einen Teil dieser Informationen erfassen. Laut der Microsoft-Dokumentation zur SharePoint-Versionshistorie lassen sich in SharePoint und OneDrive frühere Versionen von Dateien oder Elementen einsehen und wiederherstellen. Bei unterstützten Dokumenten ist auch ein Versionsvergleich möglich.

SharePoint und OneDrive frühere Versionen von Dateien oder Elementen einsehen und wiederherstellen. Sie halten jedoch nicht automatisch fest, weshalb eine Projektentscheidung getroffen wurde. Diese fachliche Begründung gehört weiterhin in die Entscheidungsdokumentation. Ebenso wenig bedeutet eine technische Versionshistorie automatisch, dass sämtliche Anforderungen an eine rechtskonforme Archivierung erfüllt sind.

Neben der Ablage braucht es ein Benachrichtigungskonzept. Eine neue Fälligkeit sollte beispielsweise der zuständigen Person zugeordnet werden. Änderungen mit Auswirkungen auf andere Arbeitspakete müssen auch für deren Verantwortliche sichtbar werden.

Dabei ist zwischen zwei Zuständen zu unterscheiden: Eine Information ist dokumentiert und eine Information wurde den relevanten Personen zugänglich gemacht beziehungsweise mitgeteilt. Beide Anforderungen sollten überprüfbar sein, ohne dass jede geringfügige Änderung eine Benachrichtigung an das gesamte Team auslöst.

Eine minimale Eingangsprüfung kann vier Pflichtangaben vorsehen: eindeutiger Vorgang, aktueller Entscheidungs- oder Aufgabenstand, verantwortliche Person und Datum. Bei relevanten Änderungen kommen die Begründung und erforderliche Freigaben hinzu.

Diese Struktur hat eine klare Grenze: Kein System kann Informationen rekonstruieren, die nie dokumentiert wurden. Deshalb bleibt die konsequente Übertragung von Ergebnissen aus Meetings, Chats und Telefonaten unverzichtbar.

Damit diese Informationen zuverlässig verfügbar und angemessen geschützt bleiben, muss die technische Projektlösung allerdings auch zu den Sicherheits- und Datenschutzanforderungen des Unternehmens passen.

Cloud oder On-Premise: Welche Projektlösung passt zu sensiblen Unternehmensdaten?

Ob eine Cloud- oder On-Premise-Lösung besser geeignet ist, hängt von der Sensibilität der Projektdaten, den regulatorischen Anforderungen, den verfügbaren IT-Ressourcen und den vertraglichen Bedingungen ab. Für Schweizer Unternehmen können sowohl eine sorgfältig geprüfte Cloud-Lösung als auch ein eigener Betrieb infrage kommen. Der Serverstandort allein entscheidet weder über Sicherheit noch über Datenschutzkonformität.

Die Auswahl sollte anhand von vier überprüfbaren Kriterien erfolgen: Datenlokalisierung, Zugriffskontrolle, Ausfallsicherheit und Datenportabilität.

Bei der Datenlokalisierung geht es darum, wo Daten gespeichert und bearbeitet werden, welche Dienstleister Zugriff erhalten können und welchen rechtlichen Rahmenbedingungen die Bearbeitung unterliegt. Dabei sind auch Supportzugriffe und mögliche Unterauftragsbearbeiter zu berücksichtigen.

Die Zugriffskontrolle umfasst beispielsweise rollenbasierte Berechtigungen, geeignete Authentisierung und die Möglichkeit, Zugriffe beim Ausscheiden von Mitarbeitenden zuverlässig zu entziehen.

Für die Ausfallsicherheit zählen unter anderem definierte Wiederherstellungsverfahren, überprüfbare Datensicherungen und ein angemessener Notfallplan. Beim Ausstiegsszenario muss geklärt sein, wie Projektdaten samt relevanter Historie exportiert und in einem anderen System weiterverwendet werden können.

Die Unterschiede zwischen den Betriebsmodellen lassen sich folgendermassen einordnen:

Für den Datenschutz in der Schweiz ist insbesondere das Bundesgesetz über den Datenschutz relevant, soweit Personendaten bearbeitet werden. Gemäss den Informationen des EDÖB zur Auftragsdatenbearbeitung bleibt der Verantwortliche auch bei einer Auslagerung der Bearbeitung von Personendaten für den Datenschutz verantwortlich.

Das Unternehmen muss den Auftragsbearbeiter deshalb sorgfältig auswählen und die notwendigen vertraglichen und organisatorischen Massnahmen treffen. Bei Bekanntgaben von Personendaten ins Ausland sind die einschlägigen gesetzlichen Voraussetzungen gesondert zu prüfen.

Eine Speicherung auf Schweizer Servern kann bestimmte Anforderungen erleichtern, gewährleistet aber für sich genommen keine vollständige Rechtskonformität. Umgekehrt besteht für Unternehmensdaten nicht generell eine Pflicht zur Speicherung ausschliesslich in der Schweiz. Branchenspezifische Vorschriften oder Geheimhaltungspflichten können strengere Anforderungen begründen.

Auch die Kosten sollten über mehrere Jahre betrachtet werden. Beim Eigenbetrieb sind insbesondere Wartung, Sicherheitsaktualisierungen, Datensicherung und Personalaufwand einzubeziehen. Bei Cloud-Lösungen gehören wiederkehrende Gebühren, Integrationen, Vertragsabhängigkeiten und mögliche Migrationskosten zur Gesamtbetrachtung.

Als praktische Orientierung können Unternehmen mit besonders sensiblen Daten oder hohen Compliance-Anforderungen zunächst einen geeigneten Eigenbetrieb und sorgfältig geprüfte Schweizer Cloud-Angebote vergleichen. Für verteilte Projektteams mit überschaubaren Anforderungen kann ein verwalteter Cloud-Dienst organisatorische Vorteile bieten, sofern Datenschutz und Betriebssicherheit angemessen geregelt sind.

Die passende Plattform schafft eine Grundlage für sichere und zugängliche Informationen. Ob die Zusammenarbeit tatsächlich funktioniert, entscheidet sich anschliessend daran, wie eindeutig Aufgaben, Entscheidungsbefugnisse und Übergaben geregelt sind.

Wie gelingt eine klare Aufgabenverteilung bei mehreren Beteiligten im selben Projekt?

Eine klare Aufgabenverteilung gelingt, wenn jede Aufgabe einen eindeutigen Verantwortlichen, definierte ausführende Personen und transparente Übergabebedingungen erhält. Die Zuständigkeiten müssen für interne Mitarbeitende, Kunden und externe Partner im gemeinsamen Projektstand erkennbar sein. Regelmässige Überprüfungen verhindern, dass sich Verantwortlichkeiten im Verlauf des Projekts unbemerkt verschieben.

Bei komplexen Projekten reicht es nicht aus, Aufgaben mehreren Beteiligten zuzuweisen und auf eine gemeinsame Bearbeitung zu vertrauen. Es muss feststehen, wer die Arbeiten ausführt, wer das Ergebnis verantwortet, wer bei Bedarf konsultiert wird und wer über Fortschritte oder Entscheidungen informiert werden muss.

Eine verbreitete Methode ist das RACI-Modell. Es unterscheidet vier Rollen:

• Responsible: Personen, die die Aufgabe operativ ausführen.
• Accountable: Die Person mit der abschliessenden Verantwortung beziehungsweise Freigabekompetenz.
• Consulted: Personen, deren fachlicher Beitrag eingeholt werden muss.
• Informed: Personen, die über das Ergebnis informiert werden sollen.

Für eine eindeutige Zuordnung ist es sinnvoll, pro Aufgabe genau eine Accountable-Person festzulegen. Gleichzeitig können mehrere Mitarbeitende an der Ausführung beteiligt sein. Dadurch wird vermieden, dass sich entweder alle für die abschliessende Freigabe zuständig fühlen oder niemand diese Verantwortung übernimmt.

RACI ist von DACI zu unterscheiden. DACI richtet sich stärker auf die Organisation von Entscheidungen und verwendet die Rollen Driver, Approver, Contributors und Informed. Der Driver koordiniert den Entscheidungsprozess, während der Approver die endgültige Entscheidung trifft.

Im DACI-Entscheidungsrahmen im Atlassian Team Playbook wird empfohlen, Entscheidungen nach ihrer Verabschiedung zusammen mit dem Kontext zu dokumentieren. Damit erhalten auch später hinzukommende Projektbeteiligte eine Grundlage, um die Entstehung eines Beschlusses zu verstehen.

Die Wahl zwischen RACI und DACI hängt davon ab, ob vor allem die operative Aufgabenverteilung oder ein komplexer Entscheidungsprozess geklärt werden soll. Beide Ansätze können sich ergänzen, sollten aber nicht als identische Methoden behandelt werden.

Besonders wichtig sind Übergaben zwischen Organisationen. Wenn ein externer Partner eine technische Lieferung erstellt und ein interner Fachbereich sie prüft, müssen Liefergegenstand, Termin, empfangende Person und Abnahmekriterien eindeutig festgelegt sein.

Ein Eintrag wie «Partner liefert Unterlagen» bleibt unvollständig. Aussagekräftiger ist eine Aufgabe, die den konkreten Liefergegenstand, die verantwortliche Person, den vereinbarten Termin und den anschliessenden Prüfschritt nennt.

Die zentrale Projektkommunikation unterstützt diese Struktur: Jede Aufgabe besitzt im Projekttool eine eindeutige Kennung, einen aktuellen Status, eine zuständige Person und Verknüpfungen zu relevanten Entscheidungen. Änderungen werden direkt am Vorgang dokumentiert, statt ausschliesslich per Chat an einzelne Beteiligte weitergegeben zu werden.

Im Projektverlauf müssen Verantwortlichkeiten überprüft werden. Neue Anforderungen, zusätzliche Beteiligte oder verschobene Termine können dazu führen, dass ursprünglich sinnvolle Zuweisungen nicht mehr zur tatsächlichen Arbeitssituation passen.

Ein kurzer regelmässiger Aufgabenreview sollte deshalb zeigen, welche Vorgänge ohne aktuelle Zuständigkeit sind, wo Aufgaben blockiert bleiben und welche Personen zu viele parallele Verpflichtungen tragen. Änderungen an der Aufgabenverteilung werden im verbindlichen Projektstand festgehalten.

Als nächster konkreter Schritt eignet sich ein Pilot mit einem laufenden Projekt: Lege für sämtliche offenen Aufgaben eine Accountable-Person fest, dokumentiere die wichtigsten Entscheidungen am jeweiligen Vorgang und überprüfe nach einer vereinbarten Testphase, ob Zuständigkeiten und Projektstände ohne zusätzliche Rückfragen erkennbar sind. So wird aus zentraler Kommunikation eine überprüfbare Arbeitsweise.