An IT project rarely stalls all at once. Usually it slips a week, then two, while the reports still say "on track", until the decision maker discovers that the deadline has passed, the budget is spent and the system is not finished. The good news is that the causes are recurring and well known, and that rescuing the project is possible in many cases if a clear sequence is followed instead of pouring more effort in the same direction.

The common causes of stalling

1. Unclear scope and undefined ownership

The project starts from a general idea, then requirements are added during delivery by more than one department, with nobody holding the authority to say "this is out of scope" or "this is deferred". Each small addition looks reasonable on its own, but together they add up to a different project from the one that was planned and priced.

2. No single accountable project manager

When responsibility is split between a busy IT manager, a coordinator on the vendor's side and representatives of the business departments, nobody sees the whole picture or answers for the deadline. The result is decisions that wait because nobody is authorised to make them, and risks that everyone can see and nobody acts on.

3. Vendor lock-in without documentation

The source code sits in the vendor's account, the servers are registered in the vendor's name, the passwords are with one developer, and there is no documentation explaining how the system works. In this situation the organisation loses its ability to negotiate or change course, and any disagreement with the vendor becomes a threat to the whole project.

4. No staging environment and no regular delivery

Without a staging environment that matches production, and without automated deployment, every release becomes a risky manual operation. Releases drift further apart, undelivered work piles up, and the business sees nothing working until the end, when correcting course is expensive.

5. Reports that hide risk

A status report that says "80% complete" says nothing about the remaining 20%, which is usually the hardest part. And when the team is rewarded for good news and blamed for bad news, the reports learn to be optimistic and the real news arrives late.

Early warning signs

If three or more of the following signs appear, the project needs a serious review now, not at the next quarterly meeting:

  • Deadlines slip gradually, and each delay comes with a different reason
  • Nobody can show you a working version of the system today
  • The answer to "when do we finish?" depends on who you ask
  • You do not know where the source code is kept or who owns the server accounts
  • The requirements list keeps growing, and nothing is removed or deferred
  • There are many meetings and few written decisions
  • One developer, or one person, is the only one who understands a core part of the system

The rescue sequence

The most common mistake when a stall is discovered is to add people or push the team to work harder. That usually accelerates the same direction that led the project to stall. The following sequence works better, and the order matters:

1. Freeze and assess

Stop adding new requirements for a short, defined period, and have a party not involved in delivery assess the actual state: what really works, what was written but not tested, and what has not started. The goal is an honest picture, not finding someone to blame.

2. Reset the baseline

Based on the assessment, the scope is redefined: what is the minimum that delivers business value and can be run? That is separated from everything that is "important but can wait". Then a new schedule and budget are set for that scope alone, and one project manager is made accountable for it.

3. Bring the assets back under the organisation's control

Before any new development work, make sure the organisation owns what it paid for:

  • The source code is in a repository in the organisation's name, with its full change history
  • Server accounts, cloud services and domains are registered in the organisation's name
  • Passwords and keys are kept somewhere the organisation controls, not with individuals
  • There is enough documentation for another team to run and develop the system
  • Data backups whose restore has actually been verified

This step is not a sign of distrust in the current vendor. It is what makes any later decision, staying with them or moving to someone else, a free one. The last point has important details that we explain in the article An Untested Backup Is Not a Backup.

4. Short delivery cycles

Instead of one big release at the end, the work is split into short cycles of roughly two weeks, each ending with something that works and that the business can see in a staging environment. This requires setting up a staging environment and a regular deployment process if they do not exist, an investment that pays back quickly because it surfaces problems early.

5. Honest reporting to decision makers

A status report aimed at management should answer a few questions clearly:

Question What the report should show
What has actually been delivered? What works and can be tried, not an estimated completion percentage
What are the current risks? The main risks, their likelihood, their impact, and who is handling them
What decisions are needed? What needs a management decision, and when delaying it becomes costly
Has the deadline or budget changed? The change and its reason, stated plainly as soon as it is known, not at the end of the phase

And when management hears bad news early without punishing whoever brought it, report quality improves on its own, and decisions become faster and cheaper.

Management's role in the rescue

No rescue sequence succeeds without clear support from senior management, because most of its steps need decisions the technical team cannot make alone: stopping requests from an influential department, renegotiating with the vendor to hand over the accounts and code, or accepting a smaller scope than originally promised. Management needs to do three things here: name one project manager and genuinely give them the authority, attend a short regular review that does not get cancelled, and make it known that early bad news is welcome. And if part of the project depends on an external vendor, it helps to have their commitments clearly written down, as we explain in the article Service level agreements: what they must actually contain (in Arabic).

When is continuing worse than stopping?

Sometimes the assessment reveals that a large part of what was built is not a sound basis to continue. Here the decision must be based on the remaining cost of finishing the project compared with its value, not on what has been spent so far. The money already spent will not come back either way, and the only useful question is: which path leads to a working system at lower cost and lower risk than today?

The bottom line

IT projects stall mostly for management reasons rather than technical ones: scope with no limits, responsibility with no owner, assets outside the organisation's control, and reports that do not tell the truth. The rescue starts from the same list in reverse: an honest assessment, a defined scope, assets under your control, regular delivery that everyone can see, and reports that decisions can be made on.