Project Drift Isn't a Failure. It's a Steering Problem.

Drift rarely looks like a crisis from inside it. It looks like fog, and fog is steered through, not powered through.

There was no single blowup. No post-mortem-worthy disaster, no one decision you could point to. The deadline that used to feel comfortable now feels like a stretch. Standups keep surfacing problems that were supposedly solved months ago. Nobody on the team could tell you, if you asked directly, exactly when things started slipping.

That’s not a failed project. It’s what CIO.com’s reporting on the pattern calls “drift”: movement that happens “slowly, especially as a result of outside forces, with no one in control of direction.”¹ The distinction is more than semantic. A project that was mismanaged from day one and a project that drifted off course need different fixes, and applying a failure-mode intervention (a full audit, a blame-finding retro, a rebuilt org chart) to a drift problem usually just adds more process on top of a project that already has too much of it.

Recovering from that doesn’t require a dramatic rescue plan or an outside consultant parachuting in. It requires five deliberate moves. None of them are novel on their own (they show up, in different words, in Richard Keenlyside’s 10-step rescue playbook², in PMI’s own recovery research³, and in Birchman Group’s project-reset framework⁴), but run in sequence, they’re what actually gets a drifted project back under someone’s control.

The order matters more than the list does. The most common shortcut is skipping straight to step four (replanning and re-governing) because it feels the most like “doing something,” while step one (naming the drift specifically, out loud) gets treated as a formality to rush past. PMI’s own recovery research and Keenlyside’s independently-published playbook both open with that same recognition step for a reason: a replan built on top of an undiagnosed problem just gives the drift a new, better-organized place to keep happening.²³ The other skip is step three. Renegotiating feels confrontational, so teams quietly absorb the change instead, which is precisely the mechanism that turned the original scope into a different project in the first place.

None of this is a heroic effort, and it shouldn’t be sold internally as one: a reset that gets dramatized becomes its own distraction from the work. What it actually requires is the discipline to keep taking the next small step even when the full path back isn’t fully mapped yet, which is a far older idea than project management.

If you can’t fly then run, if you can’t run then walk, if you can’t walk then crawl, but whatever you do you have to keep moving forward.

Martin Luther King Jr. said that closing a 1960 address at Spelman College, talking about mountains with far higher stakes than a missed sprint deadline.⁵ The comparison only holds at one narrow point, and it’s worth being precise about which one: not the size of the obstacle, but the mechanism for getting past it. Momentum, sustained in small steps, is what actually restores control, not the single perfect move that undoes months of drift in one stroke, because that move doesn’t exist.

A drifted project rarely announces itself with a crisis. It just quietly stops being the thing everyone agreed to build. Naming that plainly, freezing what’s left, renegotiating instead of absorbing, rebuilding the governance that slipped, and shipping something real, in that order, is a small number of decisions you can make on purpose, instead of remaking them from scratch every time a new request shows up asking to be absorbed for free.