Most software projects that fail do not fail suddenly. They drift for months, and the people closest to them explain the drift away because they want it to work. By the time the deadline makes it undeniable, a lot of money has gone into a system nobody can use.
This is written for the person who suspects, but is not yet sure. Here are the signs, and here is what the first thirty days of a real rescue look like so you know what to expect.
The warning signs
Any one of these is worth a hard conversation. Three or more and the project is already in trouble.
- The demo is always next week. You have been shown slides, mockups, or a development environment, but never working software you could use yourself.
- The definition of done keeps moving. Features are “done except for” testing, or integration, or the edge cases. Done means you can use it.
- Estimates only go up. Every status update adds time and money and explains why this time is different.
- The team has changed. The people who sold you the project are gone, and you do not know who is actually writing the code.
- You cannot see the code. It lives in the vendor’s accounts, you have never been given access, and asking makes people uncomfortable.
- Bugs recur. The same problem gets fixed twice, which means nobody understands why it happened.
- Communication has gone quiet or defensive. Questions get long answers that do not answer the question.
- Your own people are working around it. They have gone back to the spreadsheet, or built a parallel process, because the new system does not work.
None of these mean the work is unsalvageable. Most rescued projects keep a good share of what was built. They do mean the project needs an independent read, now, before another invoice.
The first 30 days of a rescue
A competent rescue does not start by writing code. It starts by finding out what you actually have.
Week one: get the keys. Source code, cloud accounts, environments, documentation, the backlog, and the people. If the current vendor will not hand these over, that tells you most of what you need to know, and it becomes the first problem to solve.
Weeks one to three: evaluate. This is a System Evaluation: architecture, code quality, data, infrastructure and DevOps, security, and how work reaches your users. The output is written findings, a prioritized list, and a plain answer to the question you are really asking: what here can survive into production, and what has to be redone.
Week three: stabilize what is running. If any part of the system is live, the first fixes are the ones that stop the bleeding: the failing job, the data that does not reconcile, the security hole. These are small, fast, and they buy trust.
Week four: a real plan with a real number. Fix it, extend it, replace it, or connect it. A fixed proposal for the next step, on the engagement model that fits how well-defined the work has turned out to be. You decide with facts instead of hope.
What to do today
If you recognized your project in the list above, three things you can do before you call anyone:
- Ask for access to the source code and the cloud accounts, in writing. The response is diagnostic.
- Write down, in one paragraph, what “working” would mean to the people who have to use the system. That paragraph is what the rescue will be measured against.
- Stop approving new features until you have an independent read. More scope on top of an unstable foundation makes the rescue harder.
Rescuing projects that started somewhere else is a specialty of ours. Here is how we approach it, and here is how getting started works. The first conversation is thirty minutes, and we will tell you straight whether the project is worth saving.