Tools werden einmal konfiguriert, Arbeitsweisen ändern sich jede Woche. Ohne Governance laufen Konfiguration und Realität deshalb auseinander. Die Ursache liegt selten in mangelnder Disziplin der Nutzer. Sie liegt in einer Organisation, die niemanden dafür verantwortlich macht, beides wieder zusammenzuführen.
Kernaussagen
  • Jira, Confluence und Reporting-Strukturen werden zum Projektstart sorgfältig aufgesetzt und danach selten systematisch gepflegt. Die Arbeit verändert sich, die Konfiguration bleibt gleich.
  • Der Drift beginnt schleichend. Felder werden umgedeutet, Workflows umgangen, und daneben entstehen Excel-Listen. Am Ende zeigt das Tool einen Zustand, dem niemand mehr ganz vertraut.
  • Strengere Regeln lösen das Problem nach eigener Erfahrung nicht. Wirksamer ist benannte Verantwortung mit regelmäßigen Konfigurations-Reviews, Owners für Standards, Messpunkten für Datenqualität und gut befähigten Nutzern.

Beobachtung

Bei Brownfield-Assessments, also bei der Übernahme laufender Projektumgebungen, zeigt sich immer wieder derselbe Befund. Die Jira-Konfiguration beschreibt das Projekt so, wie es vor achtzehn Monaten geplant war. Seitdem hat das Programm neue Workstreams, einen anderen Release-Schnitt und zwei zusätzliche Lieferanten bekommen. Die Teams haben sich selbst beholfen. Ein Feld für den Fachbereich enthält inzwischen Release-Namen, ein verpflichtender Workflow-Schritt wird routinemäßig mit einem Platzhalter durchlaufen, und gesteuert wird tatsächlich über eine Excel-Datei, die eine einzelne Person pflegt.

Meist wird dieser Zustand als Disziplinproblem gedeutet, nach dem Muster „Die Teams pflegen das Tool nicht". Die Erfahrung aus der Praxis spricht für das Gegenteil. Die Teams handeln rational, denn sie umgehen eine Konfiguration, die ihre tatsächliche Arbeit nicht mehr abbildet. Diese Einordnung beruht auf eigener Praxiserfahrung und nicht auf einer Studie.

Einordnung

Dass eine einmal gewählte Konfiguration nicht dauerhaft passt, ist auch in den Standards des Projektmanagements angelegt. ISO 21502 und der PMBOK Guide behandeln Tailoring und Progressive Elaboration als fortlaufende Aufgabe. Der Steuerungsansatz wird an den Kontext angepasst, und dieser Kontext verändert sich.1 Shenhar und Dvir zeigen mit dem Diamond-Ansatz, dass sich Projekte in Neuheit, Technologie, Komplexität und Tempo unterscheiden und deshalb unterschiedlich gesteuert werden müssen.2 Der Drift betrifft also nicht nur Tools. Auch die Steuerung selbst mit ihren Gremien, Rollen, Reports und Eskalationswegen 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. Der Ablauf hat drei Stufen.

  1. Umdeutung: Felder, Status und Vorlagen werden für Zwecke genutzt, für die sie nicht gebaut wurden. Anfangs ist das eine pragmatische Lösung einzelner Teams.
  2. Umgehung: Workflows, die die tatsächliche Arbeit behindern, werden formal durchlaufen, haben aber keinen Inhalt mehr. Pflichtfelder erhalten Platzhalterwerte, und Übergaben finden außerhalb des Tools statt.
  3. Parallelstruktur: Die eigentliche Steuerung wandert in Schatteninstrumente, meist in Excel. Das offizielle Tool dient nur noch als Fassade für Berichte. Ab diesem Punkt verlieren automatisierte Reports an Aussagekraft, ohne dass es jemandem auffällt.

Wichtig ist, wo die Ursache liegt. Der Drift entsteht, weil niemand dafür verantwortlich ist, Konfiguration und Arbeitsrealität regelmäßig wieder zusammenzuführen. Die Konfiguration wird als einmalige Projektaufgabe behandelt, obwohl sie wie jede Aufgabe im Betrieb laufend gepflegt werden muss.

Auslöser für eine Neukonfiguration

Nicht jede Änderung verlangt ein neues Steuerungsmodell. Bestimmte Ereignisse sollten aber immer 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, es entstehen neue Schnittstellen, oder mehrere Services müssen gemeinsam releasen.
  • Projektphase: Das Projekt geht von Discovery in die Umsetzung, vom Test in den Cutover oder vom Go-live in den Betrieb über.
  • Organisatorische Reichweite: Ein Pilot wird international ausgerollt, oder weitere Gesellschaften und Fachbereiche kommen hinzu.
  • Vertragsmodell: Aus flexibler Entwicklung wird eine fest definierte Lieferung mit Abnahme- und Meilensteinpflichten.

Bausteine brauchen Zustände zwischen an und aus

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

  • Observe: Die Entwicklung wird beobachtet.
  • Light: Der Baustein wird vereinfacht angewendet.
  • Standard: Der Baustein wird regulär angewendet.
  • Enhanced: Der Baustein wird verstärkt angewendet.
  • Independent: Der Baustein wird unabhängig geprüft.
  • Sunset: Der Baustein wird kontrolliert abgeschaltet.

Risikomanagement kann zum Beispiel als Liste der fünf größten Risiken am Teamboard beginnen. Später wird daraus ein formales Risk Review, vor einem kritischen Go-live kommt eine unabhängige Prüfung hinzu, und nach der Stabilisierung wird der Aufwand wieder reduziert.

Reconfiguration Latency

Eine aufschlussreiche Kennzahl ist die Zeit zwischen einem bedeutsamen Wechsel im Kontext und der tatsächlichen Anpassung der Steuerung. Diese Reconfiguration Latency wurde bisher nicht gemessen. In der Praxis zeigt sie sich zum Beispiel so. Ein zusätzlicher Lieferant ist vertraglich schon aktiv, bevor ein gemeinsames Ticketmodell steht. Ein Go-live-Termin ist festgelegt, bevor ein Cutover-Manager benannt ist. Das Produkt verarbeitet bereits kritische Daten, bevor Security und Datenschutz in die Governance eingebunden sind. Während dieser Zeit besteht eine Lücke in der Steuerung. Es geht nicht darum, auf jede Änderung sofort mit neuen Prozessen zu reagieren. Relevante Änderungen sollten aber früh genug als Entscheidung über die Konfiguration behandelt werden.

Anwendung in Projekten

  • Konfigurations-Reviews in festem Takt: Einmal im Quartal wird geprüft, wo Konfiguration und tatsächliche Arbeit auseinanderlaufen. Gefragt wird, welche Felder umgedeutet sind, welche Workflow-Schritte keinen Inhalt mehr haben und welche Excel-Listen parallel existieren. Das Review ist ein Arbeitsformat gemeinsam mit den Nutzern und kein Audit gegen sie.
  • Ownership für Standards: Jeder Standard, ob Feldkatalog, Workflow oder Report-Struktur, hat eine benannte Person. Sie nimmt Änderungsbedarf auf und setzt Anpassungen um. Ein Standard ohne Owner verliert schnell an Verbindlichkeit.
  • Messpunkte für Datenqualität: Wenige, dauerhaft beobachtete Indikatoren machen den Drift sichtbar, bevor er die Reports entwertet. Geeignet sind der Anteil der Vorgänge mit Platzhalterwerten, das Alter unveränderter Pflichtfelder und die Abweichung zwischen dem Status im Tool und dem berichteten Status.
  • Befähigung der Nutzer statt Regelkatalog: Statt weiterer Pflichtfelder und strengerer Workflows helfen verständliche Konventionen, kurze Einführungen und ein einfacher Weg, Änderungsbedarf an der Konfiguration zu melden. Wer den Drift melden kann, muss ihn nicht umgehen.

Grenzen

Configuration Drift ist ein Begriff aus der Praxis. Die drei Stufen sind eine Verallgemeinerung aus Assessments und keine empirisch geprüfte Typologie. Außerdem ist nicht jede Abweichung ein Drift. Manche Umdeutung ist eine sinnvolle Weiterentwicklung, die nur noch nicht in den Standard übernommen wurde. Ziel ist deshalb keine vollständig regelkonforme Nutzung. Ziel ist eine Konfiguration, die der tatsächlichen Arbeit in kontrollierten und dokumentierten Schritten folgt.