The maintenance profession has a well-worn maturity model: Reactive, Preventive, Predictive, Reliability-centered. Every organisation knows (or should know) where they sit on that spectrum, and the goal is always to move away from firefighting, towards foresight, by gradually generating more and more predictable outcomes.
But there is a scenario that model was never built to handle. It lives in the handover space between projects and operations, where the first maintenance workorders begin to appear. So, what happens when the asset you’re maintaining is still being engineered while you’re operating it?
This is the lived reality for any organisation deploying first-of-kind or rapidly evolving technology. And the failure to name it correctly is costing teams their credibility, their resources, and their ability to plan.
The problem with “reactive”
In early-stage technology deployments, a significant portion of corrective maintenance is not driven by failure at all. It’s driven by engineering change, design improvements, upgrades, and modifications as the technology finds its final form in the field.
In a CMMS, this work looks indistinguishable from reactive maintenance. Work orders accumulate. Corrective ratios climb. Leadership asks the obvious question: why can’t the team get ahead of this?
The answer is that they’re being measured against a benchmark built for a stable asset, and they don’t have one. The design is still moving. The failure modes are still being discovered. The spare parts stocked last quarter may already be obsolete. Calling this reactive maintenance isn’t just inaccurate. It’s unfair, and it obscures what’s actually happening.
The trigger isn’t failure. The goal isn’t restoration. The driver is technology maturation, and that changes everything about how we should measure success.
A different name for a different phase
The more accurate label is Adaptive Maintenance. This is a phase in which maintenance activity is driven primarily by engineering, design evolution, and feedback from the field, rather than operational failure.
In software engineering, this distinction already exists. Adaptive maintenance is formally defined as modifications made to keep a system current with a changing environment, separate from corrective work that addresses defects. That framing translates directly to physical assets in development cycles.
The difference matters because the triggers, goals, and appropriate metrics are fundamentally different. Classical reactive maintenance asks: what broke, and how fast can we restore it? Adaptive maintenance asks: what has changed in the design, and how efficiently are we incorporating it? These are not the same question, and MTTR was never designed to answer the second one.
What to do while you’re in it
The most important immediate step is to separate design-driven work from operationally-driven work in your CMMS. Tag engineering change incorporations distinctly from genuine failure events. If you’re pooling them together, your reliability data is not just noisy, it’s misleading every decision downstream.
That separation also gives you leverage with OEMs. A clean record of engineering change driven maintenance burden is hard evidence in conversations about warranty, reliability improvement agreements, and performance guarantees. Without it, you’re negotiating with anecdote and here say.
Beyond data, name the phase to your stakeholders. When leadership understands that the team is operating in an adaptive cycle instead of a reactive one, they often shift from rigid expectations to seeking to gain practical understanding. What follows is alignment of resourcing, KPI-setting, and transition planning, leading to higher quality decision making.
Use the adaptive phase deliberately. This is when your failure mode library is being written in real time. Capture everything. The data you generate now is the foundation that a future RCM program will be built on and the quality of that foundation determines how clean the transition will be.
Adaptive Maintenance isn’t a failure to progress. It’s a necessary phase and organisations that name it, measure it, and manage it deliberately will make the transition far more smoothly than those that don’t.
The standard maintenance frameworks describe a journey. What they haven’t mapped is the terrain that exists before the journey can properly begin, when the asset itself is still becoming what it will eventually be.
It’s time we gave that terrain a name.