Abhängigkeiten beschreiben Beziehungen zwischen Aufgaben, Projekten, Systemen oder Teams, bei denen der Fortschritt oder das Ergebnis eines Elements vom Vorhandensein oder der Fertigstellung eines anderen abhängt. Abhängigkeiten sind unvermeidlich in komplexen Projekten und Systemen: Workflow B kann nicht gebaut werden, bevor API-Plattform A fertig ist. Team C kann nicht mit der Integration beginnen, solange Team D das Datenbankschema noch nicht finalisiert hat. Wer Abhängigkeiten nicht explizit managt, wird von ihnen überrascht.
In Automatisierungsinfrastrukturen gibt es Abhängigkeiten auf zwei Ebenen: technische Abhängigkeiten (System A braucht Schnittstelle von System B) und projektbezogene Abhängigkeiten (Projekt C kann erst starten, wenn Projekt D geliefert hat). Beide müssen sichtbar gemacht, dokumentiert und aktiv im Projektplan berücksichtigt werden.
Abhängigkeitstypen
Technisch System-zu-System: Workflow A ruft API von System B auf. Wenn B ausfällt oder sich ändert, bricht A. Technische Abhängigkeiten sind in der Architektur sichtbar.
Prozessual Aufgabe vor Aufgabe: Schritt 2 kann erst beginnen, wenn Schritt 1 abgeschlossen ist. Sequenzielle Abhängigkeit. Im Projektplan als Predecessor-Beziehung dargestellt.
Ressourcen Geteilte Ressourcen: Projekt A und B brauchen denselben Senior-Engineer. Wenn A Priorität hat, verzögert sich B. Ressourcen-Abhängigkeit oft unsichtbar bis es brennt.
Extern Drittparteien: Lieferant muss API-Dokumentation liefern. Kundenfreigabe ausstehend. Behördliche Genehmigung. Externe Abhängigkeiten sind am schwersten zu steuern.
Abhängigkeiten managen
- Abhängigkeits-Register: Alle bekannten Abhängigkeiten dokumentieren: Was hängt von was ab? Wer ist verantwortlich? Was passiert wenn die Abhängigkeit nicht erfüllt wird?
- Kritischer Pfad: Die Kette von Abhängigkeiten, die die Gesamtprojektdauer bestimmt. Verzögerung auf dem kritischen Pfad verzögert das gesamte Projekt. Puffer außerhalb davon sind flexibel
- Frühzeitig sichtbar machen: Abhängigkeiten zu Beginn eines Projekts erheben, nicht wenn sie schon zur Blockade werden. Schriftlich dokumentiert, allen Beteiligten bekannt
- Pufferzeiten einplanen: Externe Abhängigkeiten haben unbekannte Verzögerungen. Puffer einplanen statt mit dem Optimalfall rechnen – besonders für Abhängigkeiten zu Dritten
- Parallelpfade suchen: Können Teile einer Aufgabe bereits begonnen werden, auch wenn die Abhängigkeit noch nicht vollständig erfüllt ist? Mockups statt echter API, bis die API fertig ist
Praxisbeispiel
Ein Automationsdienstleister plant ein 5-monatiges Automatisierungsprogramm mit 4 parallelen Projekten. Abhängigkeits-Analyse ergibt: Technisch: Alle 4 Projekte nutzen eine neue API-Plattform, die Projekt 1 in Monat 1–2 baut. → Projekte 2–4 können erst in Monat 3 starten. Ressourcen: Projekt 1 und 3 brauchen denselben Cloud-Architekten (1 Person). → Müssen sequenziell oder mit Teilzeit geplant werden. Extern: Projekt 4 wartet auf Datenschutz-Freigabe durch den DSB des Kunden. → Unsichere Wartezeit, 2-Wochen-Puffer eingeplant. Kritischer Pfad: Projekt 1 (API-Plattform) → Projekt 2 (Integration, nutzt API) → Projekt 4 (Dashboard, nutzt Integration). Verzögerung in Projekt 1 trifft Projekte 2 und 4. Management-Entscheidung: Projekt 1 bekommt den Cloud-Architekten zu 100 Prozent in Monat 1, danach wechselt er zu Projekt 3. Ergebnis: Alle 4 Projekte Go-Live innerhalb des 5-Monats-Fensters.
