Dependency Mapping
Dependency Mapping ist eine einstündige Team-Session, die jedes System und jedes Team auflistet, das ein Projekt berührt, dazu die Risiken, die aus diesen Abhängigkeiten entstehen, und wie mit jedem Risiko umgegangen wird. Anschließend werden regelmäßige Abstimmungen mit den jeweiligen Verantwortlichen eingerichtet. Die hier beschriebene Version folgt dem Atlassian Team Playbook und ergibt ein dreiteiliges Arbeitsblatt: betroffene Systeme, Risiken und Gegenmaßnahmen sowie Feedbackschleifen.
Moderationsablauf
- 1
Rahmen setzen: Erkläre die drei Abschnitte des Arbeitsblatts und das Ziel der Session.
5 Min. - 2
Betroffene Systeme: vor- und nachgelagerte Systeme mit verantwortlicher Person, Art der Auswirkung und Beschreibung auflisten.
20 Min. - 3
Stilles Risiko-Brainstorming, ein Risiko pro Zettel.
5 Min. - 4
Risiken teilen und diskutieren; zu jedem die Höhe der Auswirkung, die Gegenmaßnahme und die verantwortliche Person festhalten.
15 Min. - 5
Steuerungsplan: Stakeholder, Review-Rhythmus und Maßnahmen für jede Abhängigkeit. Vereinbart, wer die Map teilt und wann sie das nächste Mal überprüft wird.
15 Min.
Tipps
Fasse „System“ weit: Andere Teams, Dienstleister, Freigabeprozesse und gemeinsam genutzte Daten zählen genauso wie Software.
Frag ausdrücklich nach den nachgelagerten Auswirkungen, denn Teams listen viel bereitwilliger auf, was sie von anderen brauchen, als was sie bei anderen kaputt machen werden.
Gib jeder Abhängigkeit eine namentlich benannte Person als Verantwortliche; einen Teamnamen kann man nicht anrufen.
Halte die Timeboxes ein und überlass die detaillierte Ausarbeitung der Gegenmaßnahmen im Nachgang den Verantwortlichen.
Typische Stolperfallen
Nur vorgelagerte Abhängigkeiten auflisten. Das Team sichert die eigene Lieferung ab und übersieht die Teams, deren Arbeit es gleich stören wird und die es dann im Produktivbetrieb erfahren.
Ein Team statt einer Person als verantwortlich benennen. Gerät die Abhängigkeit in Verzug, gibt es niemand Bestimmtes, den man ansprechen kann, und die Abstimmung findet nie statt.
Jedes Risiko als hoch einstufen. Das Arbeitsblatt hilft dann niemandem mehr zu entscheiden, wohin die Aufmerksamkeit gehen soll.
Abbilden, ohne dass die Verantwortlichen der Abhängigkeiten das Ergebnis je sehen. Die Annahmen des Teams über andere Teams bleiben ungeprüft und sind oft falsch.
Die Map als Kick-off-Artefakt behandeln. Abhängigkeiten verschieben sich im Projektverlauf, und eine nicht überprüfte Map verdeckt die neuen.
Variationen
Remote: Füllt ein geteiltes digitales Arbeitsblatt aus, während eine Person ihren Bildschirm teilt, und nutzt verdeckte Notizen für die stille Risikorunde. Große Programme: Lass zuerst jeden Workstream seine eigenen Abhängigkeiten abbilden, führe dann die Arbeitsblätter zusammen und sucht nach Systemen, die mehr als einmal vorkommen. Visuelle Version: Zeichne das Projekt in die Mitte eines Whiteboards, mit vorgelagerten Systemen links und nachgelagerten rechts, bevor ihr die Inhalte in die Tabelle übertragt. Erweiterte Dokumentation: Ergänze Spalten über die Vorlage hinaus, wenn Stakeholder mehr Kontext brauchen, um einen Eintrag zu verstehen.
Einsatzbereiche
Wann einsetzen
Ein Projekt startet, das Arbeit, Daten oder Freigaben von Teams außerhalb des eigenen braucht
Eine Änderung wird ein System verändern, auf dem andere Teams aufbauen, und sie wurden noch nicht informiert
Frühere Projekte wurden durch den Zeitplan eines anderen Teams oder eine Überraschung von einem Dienstleister verzögert
Mehrere Teams planen denselben Zeitraum und müssen sehen, wo ihre Arbeit kollidiert
Der Umfang eines Projekts hat sich geändert, und seine ursprünglichen Annahmen über andere Teams gelten womöglich nicht mehr
Wann nicht einsetzen
Das Projekt liegt vollständig innerhalb eines Teams, ohne externe Systeme. Ein Premortem deckt seine Risiken besser ab
Du musst Interesse und Einfluss von Personen verstehen und nicht technische oder lieferbezogene Verknüpfungen. Nutze eine Stakeholder Map
Die Frage ist, wer welche Aufgabe übernimmt. Eine RACI Matrix beantwortet das direkt
Das Projekt ist so früh, dass der Umfang nicht definiert ist. Schreib zuerst ein Project Poster oder einen Projektauftrag, damit es etwas gibt, von dem aus sich Abhängigkeiten abbilden lassen
Niemand wird die Nachverfolgung verantworten. Eine Map ohne regelmäßige Abstimmungen ist binnen Wochen veraltet und wiegt in falscher Sicherheit
Ähnliche Methoden
Häufig gestellte Fragen
Was ist Dependency Mapping?▾
Dependency Mapping ist eine Team-Session, die die Systeme und Teams ermittelt, von denen ein Projekt abhängt oder die es betrifft, dazu die Risiken, die aus diesen Verknüpfungen entstehen, und wie sie gesteuert werden. In der Version des Atlassian Team Playbook dauert sie etwa eine Stunde und ergibt ein Arbeitsblatt mit drei Abschnitten: betroffene Systeme, Risiken und Gegenmaßnahmen sowie Feedbackschleifen.
Was ist der Unterschied zwischen vorgelagerten und nachgelagerten Abhängigkeiten?▾
Vorgelagerte Abhängigkeiten (upstream) sind Dinge, die dein Projekt von anderen braucht, etwa eine API, einen Datensatz oder eine Freigabe. Nachgelagerte Abhängigkeiten (downstream) sind die Systeme und Teams, die von dem betroffen sind, was dein Projekt verändert. Eine brauchbare Map deckt beide Richtungen ab.
Wie lange dauert Dependency Mapping, und wer sollte teilnehmen?▾
Das Play ist auf 60 Minuten für 2 bis 12 Personen angesetzt. Hol Teammitglieder dazu, die die technischen und organisatorischen Verknüpfungen im Detail kennen, und verschicke das Arbeitsblatt vorab, damit die Session mit Ideen auf dem Tisch beginnt. Die Verantwortlichen der Abhängigkeiten aus anderen Teams prüfen das Ergebnis im Anschluss.
Worin unterscheidet sich Dependency Mapping von einem Premortem?▾
Ein Premortem stellt sich vor, das Projekt sei gescheitert, und sammelt jede mögliche Ursache, intern wie extern. Dependency Mapping betrachtet nur die Verknüpfungen zu anderen Systemen und Teams, erfasst sie systematisch und ergänzt einen Review-Rhythmus mit deren Verantwortlichen. Beim Kick-off passen beide gut zusammen.
Wie oft sollte die Dependency Map aktualisiert werden?▾
Legt den Rhythmus in der Session pro Abhängigkeit fest: wöchentlich für volatile Abhängigkeiten mit hoher Auswirkung, monatlich oder quartalsweise für stabile. Nehmt euch die ganze Map außerdem immer dann wieder vor, wenn sich der Umfang ändert oder ein neues Team hinzukommt.
Plane deinen nächsten Workshop mit KI
Workshop Weaver kombiniert Methoden wie Dependency Mapping zu einer vollständigen, zeitlich geplanten Agenda. In Minuten.
Kostenlos testenMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Atlassian Team Playbook.