9 Signs Your Software Project Is Failing

A software project is failing when you can no longer see working software, get straight answers, or reach your own code and accounts. The nine signs below all come down to those three things. Any one of them can happen on a healthy project during a bad month. When several show up together and persist for more than a few weeks, the project is unlikely to recover without a change.

You do not need a technical background to spot any of them. Each sign comes with what it usually means underneath and one thing you can do this week. After the list there is a section on telling a rough patch from real failure, a two-week plan, and advice on when to pay for an outside audit.

Signs in What You Are Shown

1. Demos Keep Getting Postponed, or Turn Into Slides

A team with working software likes showing it. When the demo moves to next week for the third time, or you are shown screenshots and a slide deck in place of the product, the usual cause is that the pieces do not run together yet. Individual screens may exist on a developer's laptop while the login, the database, and the payment flow have never been connected.

This week, ask for a link to a staging environment you can open yourself, on your own phone or laptop, without anyone presenting. If there is none, ask for a date when there will be.

2. It Has Been "90 Percent Done" for Weeks

The last part of a software project is where the hard work was deferred: error handling, edge cases, performance with real data, app store review, migration of existing records. A team reporting the same percentage week after week usually has no list of what remains, so the number is a feeling.

Ask for the remaining work in writing as individual tasks, each with an owner and an estimate in days. The quality of that list tells you more than the percentage ever did. If it cannot be produced within a day or two, nobody has one.

Signs in How the Team Communicates

3. The People on Your Calls Keep Changing

Every departure takes knowledge of your project with it, and every replacement spends weeks reading before contributing. Frequent changes often mean the vendor is moving its stronger people to newer or better-paying clients, or that developers are leaving the company. In both cases you are paying for the learning curve again and again.

Find out who has been on the project since the start, who the technical lead is, and what happens to your project if that person leaves. Request that changes to the team be announced in advance.

4. You Cannot Get a Straight Answer to a Direct Question

You ask whether the payment integration is finished and receive three paragraphs about architecture. Sometimes this is a communication problem, with engineers explaining the how when you asked for the what. More often the honest answer is "no" or "we do not know," and nobody wants to be the one to say it.

Put questions in writing and phrase them so they can be answered with yes, no, or a date. Keep a note of which ones come back unanswered. A pattern across two or three weeks is evidence you can act on.

5. Silence for Days, Then a Burst Before the Invoice

Healthy projects show a steady rhythm of small updates, questions, and changes to the code. A team that goes quiet and then produces a flurry of messages and commits just before billing is usually spread across too many clients and is working on yours when payment is at stake.

If you have repository access, look at the dates of the commits over the last two months. You do not need to read the code. The calendar pattern is visible to anyone.

Signs in Estimates and Quality

6. Estimates Only Ever Go Up, and Nobody Can Say Why

Estimates change on every project, and an increase with a clear reason is normal. "The bank's API does not support refunds the way its documentation claims, so we need another week" is a good explanation. The warning sign is an increase with no specific cause, repeated. It means the team does not understand the remaining work or the state of its own code.

For the next revised estimate, ask what was discovered that was not known before, and ask to see it.

7. Every Fix Breaks Something Else

When fixing the checkout breaks the order history, the code has parts that are tangled together, and there are no automated tests to catch the damage before you do. The problem grows over time, because each hurried patch adds to the tangle.

The question for this week is how changes are tested before release, and whether there is a written list of checks that someone runs through each time. If the answer is that the developer tries it quickly, you have found the cause.

8. Reported Bugs Are Closed Without a Fix, or Come Back

A bug marked as resolved that you can still reproduce points to a process with no verification step. A bug that disappears and returns a month later often means that fixes are being made directly on the server, or on a branch that is later overwritten, which points to poor version control habits.

Keep your own list of reported bugs with dates and screenshots. When something is marked fixed, test it yourself in staging before accepting it.

The Sign That Outweighs the Others

9. You Do Not Have Access to the Code or the Accounts

If the source code sits in the vendor's private account, the servers are in their cloud account, the domain is registered in their name, and the app is published under their developer account, then you do not control your own product. Every other problem on this list becomes harder to solve, because you cannot leave and cannot let anyone else inspect the work.

Sometimes this comes from convenience at the start and nothing worse. It still has to be corrected. Ask this week for admin access to the repository, and for the cloud, domain, and app store accounts to be moved into your company's name. A vendor with nothing to hide will agree, and reluctance on this point worries us more than any other sign here.

Rough Patch or Real Failure?

Good projects have bad months. A key developer falls ill, a third-party service changes its rules, or a requirement turns out to be harder than anyone thought. What separates a rough patch from failure is how the team behaves around the problem.

In a rough patch, the team tells you about the problem before you discover it, explains the cause in specific terms, and gives you a revised plan that it then more or less keeps. You can still see working software, even if it is behind schedule. In a failing project, you find out about problems yourself, the explanations are vague, and each new plan is missed like the last one. It depends less on how late the project is than on whether the lateness is understood.

What to Do in the Next Two Weeks

Do these in order, and keep the tone routine. First, secure access: the repository, the cloud account, the domain, the app store accounts, and a recent database backup. This protects you whatever happens next and should come before any difficult conversation.

Second, ask for a working build on a staging link, together with the written list of remaining tasks. Third, set one small milestone with a fixed date, something that can be finished in a week and that you can verify yourself, such as a user being able to register, log in, and reset a password on staging. A team that is basically sound will hit it. A team in trouble will miss it or deliver something that only half works, and then you have your answer in two weeks where you might otherwise have waited another quarter.

Fourth, read your contract for the notice period and the clauses about who owns the code. Do this quietly. You may not need it, but you should know your position before you need it.

When to Bring in an Outside Audit

Bring in an independent reviewer if the milestone is missed, if access is refused or keeps being delayed, or if you simply cannot tell whether what you are being told is true. An audit is a few days of an experienced engineer reading the code, trying to build and deploy it, and checking the accounts and backups. The output should be a written report you can understand, with a recommendation to continue, to repair, or to change course.

Choose someone who does not need the follow-on work to justify their conclusion, or who at least shows the evidence for it. Tell your current vendor that it is happening. A healthy team tends to welcome a second pair of eyes, and the reaction is informative in itself.

If several of these signs look familiar, the free 10-point Project Failure Risk Checklist on our site produces a PDF report you can share with your partners or board. Lionasys Technologies, based in Ahmedabad, India, and founded in 2010, takes over software, AI, IoT, mobile, and game projects. The initial rescue audit is free and takes one to two days, we commit to responding within 48 hours, and the work is covered by a no fix, no fee guarantee.