Configuration Drift: Why project tools, processes and real ways of working drift apart.

Tools are configured once, ways of working change every week. Without governance, configuration and reality therefore drift apart. The cause rarely lies in a lack of discipline among users. It lies in an organisation that makes nobody responsible for bringing the two back together.

Observation

In brownfield assessments, that is when taking over running project environments, the same finding appears again and again. The Jira configuration describes the project as it was planned eighteen months ago. Since then, the programme has gained new workstreams, a different release cut and two additional suppliers. The teams have helped themselves. A field for the business unit now contains release names, a mandatory workflow step is routinely passed with a placeholder, and the actual steering happens in an Excel file maintained by a single person.

This state is usually interpreted as a discipline problem, along the lines of "the teams do not maintain the tool". Experience from practice suggests the opposite. The teams act rationally, because they bypass a configuration that no longer reflects their actual work. This interpretation is based on our own practical experience and not on a study.

Context

That a configuration chosen once does not fit permanently is also built into project management standards. ISO 21502 and the PMBOK Guide treat tailoring and progressive elaboration as an ongoing task. The steering approach is adapted to the context, and this context changes.¹ Shenhar and Dvir show with the diamond approach that projects differ in novelty, technology, complexity and pace and therefore have to be steered differently.² The drift therefore does not only affect tools. Steering itself, with its committees, roles, reports and escalation paths, can remain formally in place and still no longer fit the project.

The term: Configuration Drift

Configuration drift describes the gradual divergence of tool configuration, documented process and actual way of working. The process has three stages.

1. Reinterpretation: Fields, statuses and templates are used for purposes they were not built for. At first, this is a pragmatic solution by individual teams.
2. Bypassing: Workflows that hinder the actual work are passed through formally but no longer have any content. Mandatory fields receive placeholder values, and handovers take place outside the tool.
3. Parallel structure: The actual steering moves into shadow instruments, usually Excel. The official tool only serves as a facade for reports. From this point on, automated reports lose meaning without anyone noticing.

It is important where the cause lies. The drift arises because nobody is responsible for regularly bringing configuration and working reality back together. Configuration is treated as a one-off project task, although it has to be maintained continuously like any operational task.

Triggers for reconfiguration

Not every change requires a new steering model. Certain events should, however, always trigger a review.

• Criticality: The system takes over business-critical functions, processes sensitive data or becomes relevant for regulation.
• Delivery structure: A supplier, several external teams or a managed service are added.
• Architecture: A local application becomes a platform, new interfaces emerge, or several services have to release together.
• Project phase: The project moves from discovery to delivery, from testing to cutover or from go-live to operations.
• Organisational reach: A pilot is rolled out internationally, or further companies and business units are added.
• Contract model: Flexible development turns into a firmly defined delivery with acceptance and milestone obligations.

Building blocks need states between on and off

A steering building block should not only be able to be active or inactive. More useful are graded states that grow with the context and can be scaled back again.

• Observe: Developments are observed.
• Light: The building block is applied in simplified form.
• Standard: The building block is applied regularly.
• Enhanced: The building block is applied more intensively.
• Independent: The building block is reviewed independently.
• Sunset: The building block is switched off in a controlled way.

Risk management can, for example, start as a list of the five biggest risks on the team board. Later it becomes a formal risk review, before a critical go-live an independent review is added, and after stabilisation the effort is reduced again.

Reconfiguration Latency

A revealing metric is the time between a significant change in context and the actual adaptation of steering. This reconfiguration latency has not been measured so far. In practice it shows up, for example, like this. An additional supplier is already contractually active before a shared ticket model is in place. A go-live date is fixed before a cutover manager is named. The product is already processing critical data before security and data protection are integrated into governance. During this time, there is a gap in steering. The point is not to react to every change immediately with new processes. Relevant changes should, however, be treated early enough as a decision about the configuration.

Application in projects

• Configuration reviews at a fixed cadence: Once a quarter, the team checks where configuration and actual work diverge. The questions are which fields have been reinterpreted, which workflow steps no longer have content and which Excel lists exist in parallel. The review is a working format together with the users and not an audit against them.
• Ownership for standards: Every standard, whether field catalogue, workflow or report structure, has a named person. This person collects change requests and implements adjustments. A standard without an owner quickly loses its binding force.
• Measurement points for data quality: A few indicators observed permanently make the drift visible before it devalues the reports. Suitable ones are the share of items with placeholder values, the age of unchanged mandatory fields and the deviation between the status in the tool and the reported status.
• User enablement instead of a rulebook: Instead of more mandatory fields and stricter workflows, understandable conventions, short introductions and an easy way to report change needs in the configuration help. Those who can report the drift do not have to bypass it.

Limits

Configuration drift is a term from practice. The three stages are a generalisation from assessments and not an empirically tested typology. Moreover, not every deviation is drift. Some reinterpretation is a sensible further development that has simply not yet been adopted into the standard. The goal is therefore not fully rule-compliant use. The goal is a configuration that follows the actual work in controlled and documented steps.