Configuration Drift: Warum Projekttools, Prozesse und reale Arbeitsweisen auseinanderlaufen.

Tools werden einmal konfiguriert. Arbeitsweisen entwickeln sich jede Woche weiter. Ohne Governance driften Konfiguration und Realität auseinander — und das ist kein Disziplinproblem der Nutzer, sondern ein Governance-Problem der Organisation.

Beobachtung

In Brownfield-Assessments — also bei der Übernahme laufender Projektumgebungen — wiederholt sich ein Befund: Die Jira-Konfiguration beschreibt das Projekt, wie es vor achtzehn Monaten geplant wurde. Seitdem hat das Programm neue Workstreams, einen anderen Release-Schnitt und zwei zusätzliche Lieferanten. Die Teams haben sich beholfen: Ein Feld für „Fachbereich“ trägt inzwischen Release-Namen, ein verpflichtender Workflow-Schritt wird routinemäßig mit einem Platzhalter durchlaufen, und die tatsächliche Steuerung läuft über eine Excel-Datei, die eine Person pflegt.

Bemerkenswert ist, wie dieser Zustand üblicherweise gedeutet wird: als Disziplinproblem. „Die Teams pflegen das Tool nicht.“ Die Beobachtung aus der Praxis spricht für das Gegenteil — die Teams arbeiten rational. Sie umgehen eine Konfiguration, die ihre reale Arbeit nicht mehr abbildet. Diese Einordnung beruht auf eigener Praxiserfahrung, nicht auf einer Studie.

Einordnung

Was der Drift kostet, lässt sich über seine sichtbarste Folge greifen: unzuverlässige Daten. Gartner beziffert die durchschnittlichen Kosten mangelhafter Datenqualität auf 12,9 Millionen US-Dollar pro Organisation und Jahr.¹ Zugleich messen laut Gartner rund 60 Prozent der Organisationen diese Kosten nicht systematisch.² Beide Zahlen beziehen sich auf Datenqualität insgesamt, nicht spezifisch auf Projekttools; die Übertragung auf Projektumgebungen — wo Statusberichte, Forecasts und Steering-Unterlagen direkt aus diesen Daten entstehen — ist eine eigene Einordnung. Sie erklärt allerdings, warum der Drift so lange unsichtbar bleibt: Was niemand misst, eskaliert niemand.

Dass eine einmal gewählte Konfiguration nicht unbegrenzt passt, ist auch im Projektmanagement-Standard angelegt. ISO 21502 und der PMBOK Guide behandeln Tailoring und Progressive Elaboration als fortlaufende Aufgabe: Der Steuerungsansatz wird an den Kontext angepasst — und der Kontext ändert sich.³ Das Cynefin-Framework von Snowden und Boone macht denselben Punkt für Entscheidungskontexte: Was in einem geordneten Umfeld richtig ist, wird im komplexen falsch — Phasenübergänge verlangen eine neue Einordnung.⁴ Und Shenhar und Dvir zeigen mit dem Diamond-Ansatz, dass Projekte über Neuheit, Technologie, Komplexität und Tempo variieren und deshalb unterschiedlich gesteuert werden müssen.⁵ Der Drift ist damit nicht nur ein Tool-Thema: Auch die Steuerungskonfiguration selbst — Gremien, Rollen, Reporting, Eskalationswege — kann formal bestehen bleiben und trotzdem nicht mehr zum Projekt passen.

Der Begriff: Configuration Drift

Configuration Drift bezeichnet das schleichende Auseinanderlaufen von Tool-Konfiguration, dokumentiertem Prozess und tatsächlicher Arbeitsweise. Die Mechanik hat drei Stufen:

1. Umdeutung: Felder, Status und Vorlagen werden für Zwecke genutzt, für die sie nicht gebaut wurden — zunächst als pragmatische Lösung einzelner Teams.
2. Umgehung: Workflows, die die reale Arbeit behindern, werden formal durchlaufen, aber inhaltlich entleert. Pflichtfelder erhalten Platzhalterwerte, Übergaben passieren außerhalb des Tools.
3. Parallelstruktur: Die eigentliche Steuerung wandert in Schatteninstrumente — meist Excel —, während das offizielle Tool zur Berichtsfassade wird. Ab diesem Punkt sind automatisierte Reports strukturell falsch, ohne dass es jemand einzeln bemerkt.

Entscheidend ist die Ursachenzuschreibung: Der Drift entsteht nicht, weil Nutzer undiszipliniert sind, sondern weil niemand die Verantwortung trägt, Konfiguration und Arbeitsrealität regelmäßig wieder zusammenzuführen. Konfiguration wird als Projektaufgabe behandelt („einmal aufsetzen“), obwohl sie eine Betriebsaufgabe ist („laufend pflegen“).

Auslöser für eine Neukonfiguration

Nicht jede Änderung verlangt ein neues Steuerungsmodell. Bestimmte Ereignisse sollten aber automatisch eine Überprüfung auslösen:

• Kritikalität — das System übernimmt geschäftskritische Funktionen, verarbeitet sensible Daten oder wird regulatorisch relevant.
• Delivery-Struktur — ein Lieferant, mehrere externe Teams oder ein Managed Service kommen hinzu.
• Architektur — aus einer lokalen Anwendung wird eine Plattform, neue Schnittstellen entstehen, mehrere Services müssen gemeinsam releasen.
• Projektphase — der Übergang von Discovery zu Umsetzung, von Test zu Cutover oder von Go-live zu Betrieb.
• Organisatorische Reichweite — ein Pilot wird international ausgerollt, weitere Gesellschaften oder Fachbereiche kommen hinzu.
• Vertragsmodell — aus flexibler Entwicklung wird eine fest definierte Lieferung mit Abnahme- und Meilensteinpflichten.

Bausteine brauchen Zustände — nicht nur „an" oder „aus"

Ein Steuerungsbaustein sollte nicht nur „aktiv" oder „inaktiv" sein. Nützlicher sind abgestufte Zustände, die mit dem Kontext mitwachsen und wieder zurückgefahren werden können:

• Observe — Entwicklung beobachten.
• Light — vereinfachte Anwendung.
• Standard — reguläre Anwendung.
• Enhanced — verstärkte Anwendung.
• Independent — unabhängige Prüfung.
• Sunset — kontrollierte Abschaltung.

Risikomanagement kann etwa als Top-5-Liste am Teamboard beginnen, später in ein formales Risk Review übergehen, vor einem kritischen Go-live durch eine unabhängige Prüfung ergänzt und nach der Stabilisierung wieder reduziert werden.

Reconfiguration Latency

Eine relevante Kennzahl ist die Zeit zwischen einem bedeutsamen Kontextwechsel und der tatsächlichen Anpassung der Steuerung. Diese Reconfiguration Latency kann Wochen bis Monate betragen: Ein zusätzlicher Lieferant ist vertraglich aktiv, bevor ein gemeinsames Ticketmodell steht; ein Go-live-Termin ist fixiert, bevor ein Cutover-Manager benannt ist; das Produkt verarbeitet bereits kritische Daten, bevor Security und Datenschutz in die Governance integriert sind. In dieser Zeit besteht eine Steuerungslücke. Ziel ist nicht, auf jede Änderung sofort mit neuen Prozessen zu reagieren, sondern relevante Änderungen früh genug als Konfigurationsentscheidung zu behandeln.

Anwendung in Projekten

• Konfigurations-Reviews im festen Takt. Quartalsweise wird geprüft, wo Konfiguration und reale Arbeit auseinanderlaufen: Welche Felder sind faktisch umgedeutet, welche Workflow-Schritte inhaltlich leer, welche Excel-Listen existieren parallel? Das Review ist ein Arbeitsformat mit den Nutzern, kein Audit gegen sie.
• Ownership für Standards. Jeder Standard — Feldkatalog, Workflow, Report-Struktur — hat eine benannte Person, die Änderungsbedarf aufnimmt und Anpassungen umsetzt. Ein Standard ohne Owner ist ein Standard auf Abruf.
• Messpunkte für Datenqualität. Wenige, dauerhaft beobachtete Indikatoren machen den Drift sichtbar, bevor er Reports entwertet: Anteil der Vorgänge mit Platzhalterwerten, Alter unveränderter Pflichtfelder, Abweichung zwischen Tool-Status und berichtetem Status.
• Nutzerbefähigung statt Regelkatalog. Statt mehr Pflichtfelder und strengere Workflows: verständliche Konventionen, kurze Onboardings und ein einfacher Weg, Änderungsbedarf an der Konfiguration zu melden. Wer den Drift melden kann, muss ihn nicht umgehen.

Grenzen

Configuration Drift ist ein Praxisbegriff; die dreistufige Mechanik ist eine Verallgemeinerung aus Assessments, keine empirisch geprüfte Typologie. Die zitierten Gartner-Zahlen betreffen Datenqualität allgemein und sind kein Beleg für die Kosten von Tool-Drift im Speziellen. Und nicht jede Abweichung ist Drift: Manche Umdeutung ist eine sinnvolle Weiterentwicklung, die schlicht noch nicht in den Standard übernommen wurde. Das Ziel ist deshalb nicht eine perfekt regelkonforme Nutzung, sondern eine Konfiguration, die der realen Arbeit folgt — in kontrollierten, dokumentierten Schritten.