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

Tools are configured once. Ways of working keep evolving every week. Without governance, configuration and reality drift apart — and that is not a discipline problem of the users, but a governance problem of the organisation.

Observation

In brownfield assessments — that is, when taking over running project environments — one finding recurs: the Jira configuration describes the project as it was planned eighteen months ago. Since then the programme has new workstreams, a different release cut and two additional suppliers. The teams have improvised: a field for “business unit” now carries release names, a mandatory workflow step is routinely passed with a placeholder, and the actual steering runs through an Excel file that one person maintains.

What is remarkable is how this state is usually interpreted: as a discipline problem. “The teams don't maintain the tool.” The observation from practice suggests the opposite — the teams are acting rationally. They are circumventing a configuration that no longer reflects their real work. This reading rests on my own practical experience, not on a study.

Context

What the drift costs can be grasped through its most visible consequence: unreliable data. Gartner puts the average cost of poor data quality at 12.9 million US dollars per organisation per year.¹ At the same time, according to Gartner, around 60 per cent of organisations do not measure these costs systematically.² Both figures relate to data quality overall, not specifically to project tools; the transfer to project environments — where status reports, forecasts and steering documents arise directly from these data — is my own contextualisation. It does, however, explain why the drift remains invisible for so long: what no one measures, no one escalates.

That a configuration once chosen does not fit indefinitely is also inherent in the 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 the context changes.³ The Cynefin framework by Snowden and Boone makes the same point for decision contexts: what is right in an ordered environment becomes wrong in a complex one — phase transitions demand a fresh reading.⁴ And Shenhar and Dvir show, with the Diamond approach, that projects vary across novelty, technology, complexity and pace and therefore must be steered differently.⁵ The drift is thus not only a tool matter: the steering configuration itself — committees, roles, reporting, escalation paths — can formally remain in place and still no longer fit the project.

The concept: Configuration Drift

Configuration Drift denotes the gradual divergence of tool configuration, documented process and actual way of working. The mechanics have three stages:

1. Reinterpretation: Fields, statuses and templates are used for purposes they were not built for — at first as a pragmatic solution for individual teams.
2. Circumvention: Workflows that impede the real work are formally passed through but emptied of substance. Mandatory fields receive placeholder values, handovers happen outside the tool.
3. Parallel structure: The actual steering migrates into shadow instruments — usually Excel — while the official tool becomes a reporting façade. From this point on, automated reports are structurally wrong without anyone noticing individually.

Decisive is the attribution of cause: the drift arises not because users are undisciplined, but because no one holds the responsibility to bring configuration and the reality of work back together regularly. Configuration is treated as a project task (“set up once”), although it is an operational task (“maintain continuously”).

Triggers for a reconfiguration

Not every change calls for a new steering model. Certain events should, however, automatically trigger a review:

• Criticality — the system takes on business-critical functions, processes sensitive data or becomes regulatorily relevant.
• Delivery structure — a supplier, several external teams or a managed service are added.
• Architecture — a local application becomes a platform, new interfaces emerge, several services must release together.
• Project phase — the transition from discovery to delivery, from test to cutover or from go-live to operations.
• Organisational reach — a pilot is rolled out internationally, further entities or business units are added.
• Contract model — flexible development becomes a firmly defined delivery with acceptance and milestone obligations.

Building blocks need states — not just “on” or “off”

A steering building block should not be merely “active” or “inactive”. More useful are graduated states that grow with the context and can be scaled back again:

• Observe — watch developments.
• Light — simplified application.
• Standard — regular application.
• Enhanced — reinforced application.
• Independent — independent review.
• Sunset — controlled shutdown.

Risk management can, for instance, begin as a top-5 list on the team board, later move into a formal risk review, be supplemented by an independent review before a critical go-live, and be reduced again after stabilisation.

Reconfiguration Latency

One relevant metric is the time between a significant context change and the actual adjustment of the steering. This Reconfiguration Latency can amount to weeks or months: an additional supplier is 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 the governance. During this time a steering gap exists. The goal is not to react to every change immediately with new processes, but to treat relevant changes early enough as a configuration decision.

Application in projects

• Configuration reviews on a fixed cadence. Each quarter, where configuration and real work diverge is examined: which fields are effectively reinterpreted, which workflow steps empty of substance, which Excel lists exist in parallel? The review is a working format with the users, not an audit against them.
• Ownership for standards. Every standard — field catalogue, workflow, report structure — has a named person who takes up the need for change and implements adjustments. A standard without an owner is a standard on borrowed time.
• Measurement points for data quality. A few, permanently observed indicators make the drift visible before it devalues reports: share of items with placeholder values, age of unchanged mandatory fields, deviation between tool status and reported status.
• User enablement instead of a rulebook. Rather than more mandatory fields and stricter workflows: comprehensible conventions, short onboardings and an easy way to report the need for change in the configuration. Whoever can report the drift does not have to circumvent it.

Limitations

Configuration Drift is a practitioner concept; the three-stage mechanics are a generalisation from assessments, not an empirically tested typology. The cited Gartner figures concern data quality in general and are not proof of the cost of tool drift specifically. And not every deviation is drift: some reinterpretation is a sensible evolution that has simply not yet been adopted into the standard. The goal is therefore not perfectly rule-compliant use, but a configuration that follows the real work — in controlled, documented steps.