There’s a category of building problem that’s distinct from unclear requirements or technical complexity. It’s the problem of requirements that are clear and well-understood — and still changing faster than the build process can keep up with.

This isn’t scope creep, exactly. Scope creep is usually about addition: new things get added to what a system needs to do. The moving target problem is about drift: the thing the system is supposed to do stays roughly the same, but the specifics of what that means in practice keep shifting underneath you.

The result is a particular kind of frustrating: you’re not building the wrong thing, and you’re not building it wrong, but what you’ve finished building is already slightly off from where the target has moved.

Why Targets Move

Targets move for a few reasons that are worth distinguishing, because they have different implications.

The domain is evolving. When the underlying space you’re building in is actively changing — new tools appearing, standards shifting, adjacent players moving — the requirements that accurately described what to build six months ago may accurately describe something that no longer fits. The requirements weren’t wrong; they were right for a previous state of the domain.

The users are learning. Sometimes requirements drift because the people specifying them understand what they need better as the project progresses. Early specifications are approximations. Later ones are more precise. A system built to the early spec may be a good solution to the wrong version of the problem.

The environment is changing. Regulatory shifts, market changes, competitive moves — the external context that gives requirements their meaning can shift without any conscious decision by anyone involved in the build.

All three feel similar from inside a project. The build feels perpetually behind. Finished work needs revision. The gap between “what’s done” and “what’s needed” keeps reopening. The cause matters because the response differs.

What Makes It Worse

A few things make the moving target problem significantly worse.

Long cycle times. The longer the time from specification to delivery, the more the target can move. A build that takes a week gives the target little time to drift. A build that takes six months gives it substantial time. High-velocity environments with slow build cycles suffer most from this.

Tight coupling between components. When changing one part of a system requires changing many others, adapting to a moved target is expensive. The cost of recalibration is high enough that teams defer it, accumulating drift until it’s large enough to cause real problems.

Optimization for the spec rather than the goal. When the build process optimizes for meeting the specification precisely, it can lose track of the underlying goal the spec was approximating. When the spec drifts, there’s no anchor. When the spec is well-understood as an approximation of the goal, drift in the spec can be evaluated against the goal rather than just accumulated.

How to Build for Moving Targets

The honest answer is that you can’t fully solve the moving target problem. You can manage it.

Short delivery cycles reduce exposure. The less time between specification and delivery, the less the target can move in the interval. This is the main practical argument for iterative development — not that it produces better plans, but that it reduces the gap during which plans can become stale.

Reversibility reduces the cost of drift. Systems built to be modified adapt more cheaply to moved targets than systems built to be correct. This isn’t an argument against correctness — it’s an argument for choosing correctness along the dimensions that matter most and accepting mutability elsewhere.

Track the goal, not just the spec. Requirements are approximations of goals. When you track the goal independently of the spec, you can notice when spec and goal are diverging — when the target has moved but the spec hasn’t caught up yet. You can’t always close the gap immediately, but you can avoid being surprised by it.

Build tolerance for recalibration. The hardest part of moving target problems isn’t technically recalibrating the build — it’s accepting that recalibration is normal and not a sign of failure. Teams that treat drift as a planning error spend energy on preventing the unpreventable. Teams that treat it as a normal property of building in changing environments spend energy on managing it efficiently.

The target will move. The question is how much that costs you when it does.