Rescuing a Software Project Another Company Could Not Finish

Often, yes. A stalled or failed software project is rescued by first assessing what exists: the code, the database design and the requirements. Each part is then kept, repaired or replaced on its merits. Even when the code cannot be saved, the work done to define what the system must do usually can, which makes the second attempt faster and far less risky than the first.

Signs this is your problem

• Deadlines have slipped more than twice with no clear reason.
• You have paid for months of work and cannot log in to anything that works.
• Every fix seems to break something else.
• Your developer has stopped giving straight answers.
• You have lost confidence but are afraid of losing what you have spent.

Why software projects go off the rails

In our experience it is seldom one dramatic failure. It is usually some mix of these:

• The requirements were never pinned down. The developers built what they understood, which was not what the business needed.
• The database was designed badly. Everything built on top of a weak data model gets harder with each new feature.
• The team was too small or too junior. One person, or a firm that had never built anything this size.
• Nobody showed working software. Months passed with status reports and no screens to try.
• Communication broke down. Questions went unanswered and trust went with them.

What can usually be salvaged

More than most owners expect. A rescue starts by sorting what exists into three piles:

• Keep. Sound code, a workable database, screens your staff already like.
• Repair. Parts with the right idea and poor execution.
• Replace. Parts that would cost more to fix than to rebuild.

Even in the worst case, you are not back where you began. You now know what you need, your staff have seen what does not work, and the requirements are far clearer than they were on day one.

We have been the third firm in

When Southwest Exchange came to Keene Systems, two other software development firms had already tried and failed to design and build their system. It had to manage many kinds of data with complex relationships between them, and the whole workflow of a 1031 real estate exchange. We started with a rock-solid database architecture and delivered the system. Read the Southwest Exchange case study.

How Keene Systems handles it

1. We listen to the whole story. What was promised, what was delivered and where it stands.
2. We assess the code, database and requirements. You get an honest report: keep, repair or replace.
3. We agree a plan with visible milestones. Working software you can try at every stage, so progress is never a matter of opinion.
4. We finish the job. And stay to support it.

The next step is a short, no-pressure conversation. Book a call with Lance Keene or use the form on this page.