← All guides

Project rescue

Signs your software project is off track, and the questions to ask

Software projects rarely fail suddenly. They drift, and the signs are visible months before anyone says the word "failing". Here is what to watch for, and what to ask when you see it.

By the time a project is openly in trouble, most of the expensive decisions have already been made. The value of spotting drift early is that the options are still cheap: re-scope, re-sequence, or change course before the budget is gone.

Signs in the status reports

  • “Ninety per cent done” for weeks. Percentages of completion that stop moving usually mean the last ten per cent contains the hard part nobody estimated.
  • Progress measured in effort, not outcomes. Hours spent and tasks closed are not the same as working features you can use.
  • Nothing written down about what remains. If nobody can list what is left, nobody can estimate it.

Signs in the demos

  • The same demo, repeatedly. Each review shows the same screens with small changes, rather than new capability.
  • Demo data only. The system works on carefully prepared examples but has never been tried on your real data, with its exceptions and mess.
  • You cannot use it yourself. If the only way to see the software is a guided demonstration, it is not ready for the people who will actually use it.

Signs in the scope

  • There is no written scope — or there is, but nobody refers to it.
  • Changes are absorbed silently. New requests go in without anyone saying what they cost or what they displace, so the finish line moves without anyone deciding to move it.
  • Or every change is a dispute. The opposite pattern: each conversation about what was included becomes an argument, because what was promised was never precise enough to settle it.

Signs in the team

  • Turnover. People leave and their replacements need weeks to understand what was built.
  • One person knows. If a single developer is the only one who understands how the system fits together, the project is one resignation away from a crisis.
  • Questions go unanswered. The team asks the business how something should work and does not get an answer, so they guess.

Signs in the money

  • Spend is tracking the budget, delivery is not. The money is being used on schedule; the working software is not arriving on schedule.
  • Invoices you cannot match to anything you can see.

Questions to ask this week

You do not need technical knowledge to ask these, and the quality of the answers tells you a great deal.

  1. What exactly is left, and how do you know? Ask for a list, not a percentage.
  2. Can I use it, on our real data, today? Not watch it — use it.
  3. What are the automated tests, and do they pass? A team that tests can answer immediately.
  4. If you left tomorrow, could someone else continue? Ask what documentation exists and where the code and accounts live.
  5. What has changed since we agreed the scope, and what did each change cost?

What to do with the answers

Vague answers to these questions are themselves an answer. If the remaining work cannot be listed, the scope was probably never pinned down, and the most valuable next step is to write it down — what was intended, what exists, and what it will take to close the gap. Our guide on deciding whether to fix or rebuild walks through that assessment; our project rescue service runs it for you at a fixed fee.

Where Elarion fits

Project rescue & audit

A build in trouble, an inherited codebase, or a vendor on the way out. It starts with a fixed-fee assessment of what was intended against what exists — then you decide what happens next, with us or without us.

30 minutes, free. Bring the problem, or the document you already have.

Related guides