Rescuing a stalled software project
What I check first when a project has blown its deadlines and lost control: the recurring root causes of a crisis and the sequence for turning it around.
The request I hear most often on troubled projects is phrased the same way: “we need to move faster” — add developers, or tighten the deadline. In most cases this only makes things worse. A project that is losing control suffers not from a lack of speed, but from a loss of clarity: in the requirements, in the architecture, and in the relationship between the business and the team.
Over the years I’ve worked through dozens of these situations. The outward signs are similar: missed deadlines, a release that keeps slipping, weekend work, no predictable finish date. But these are symptoms, not causes. Acting on the symptoms — more people, more overtime, more pressure — does not fix the problem and usually accelerates the decline.
The first step is diagnosis, not action
I don’t start with the code or with reworking the schedule. I start with diagnosis. First, separate conversations with the business and with the engineers. As a rule, the two sides describe the same project differently, and the source of the problem is found in that gap.
Then I look not at the current state of the codebase but at its history: where tasks repeatedly stall, what gets redone, which architectural decisions were made and on what grounds. The code tells a large part of the story, but the decisive information usually comes from people.
Common root causes
The first and most widespread is the absence of a shared understanding of what is being built. The business expects one result, the team builds another, and the line between them gradually shifts. Increasing the pace here is counterproductive: the faster the team moves, the further it drifts from the original goal.
The second is architectural decisions made in isolation from the business context: either an over-engineered system that solves the wrong problem, or a temporary prototype that production functionality keeps being bolted onto. Both become a source of systemic failures over time.
The third is technical debt that has crossed acceptable limits. Debt itself is inevitable and manageable. It becomes a problem when it stops being addressed, and every subsequent change starts touching a disproportionate amount of code.
The fourth is rarely recorded in reports but is almost always present — a loss of trust between the business and engineering. The client stops relying on the team’s estimates; the team stops believing its arguments will be heard. The project shifts into a mode of working to exhaustion, without stable processes, and that mode is the first to burn out.
A recovery plan
A full rewrite from scratch is almost always the wrong call. It looks appealing, but in practice it means losing time and the knowledge already embedded in the current code.
The sequence I follow is different. First, stabilization: fix the working part of the system in place and stop changing it. Then prioritization together with the business — decide what is genuinely needed for the nearest goal and what can wait. In parallel, working communication between the sides is restored, because without trust any plan loses its footing at the first piece of bad news. Only after that, in small controlled steps, do I work on technical debt and architecture — where they objectively stand in the way of progress.
What doesn’t work
Adding people to a project in crisis usually slows it down further: newcomers have to be brought up to speed, and there is no spare capacity to do so. Tightening deadlines leads to new compromises on quality that surface later. Rewriting from scratch costs time and context. These three seemingly obvious decisions are what drive projects to the point where an outside specialist is brought in.
In summary
In most cases a project is brought out of crisis not by mobilizing resources but by restoring clarity: a shared understanding of the goals and a substantive dialogue between client and contractor. The technical problems are solved at the next stage, and their scope usually turns out to be smaller than it appears in the middle of a crisis.