The five most common software development problems are unclear requirements, poor communication, dependence on one person, costs that run away and too little testing. None of them is really a technical problem. They are problems of agreement and management, which means the person paying for the work can see them coming and has a say in whether they happen.
For each one, this article sets out how it starts, the early sign to watch for and what to do about it.
1. Unclear requirements
In our experience, most projects that fail were in trouble before any code was written. The buyer described what they wanted in a page or two, the developers filled the gaps with assumptions, and the two sides discovered months later that they had been picturing different systems.
Requirements do not have to be long. They have to be specific about the things that change the amount of work: who will use the system, what each of them needs to get done, which existing systems and data it must work with, and how you will decide that a piece of work is finished. “A dispatcher can assign a job to an engineer and see it on the schedule” can be built and checked. “A scheduling module” cannot.
Early sign: nobody can state, for the work now in progress, the check that will show it is done.
What to do: write the requirements as tasks people perform, and agree acceptance checks for each before work starts. Our article on acceptance criteria shows how, and the project planning worksheet gives you a structure for the rest.
2. Poor communication
Software is built from hundreds of small decisions, such as whether an order with no delivery date should be allowed, or who can approve a refund. When the developers cannot get an answer, they either wait or guess. Waiting costs time. Guessing costs more, because the wrong guess is found later and has to be undone.
The usual cause is on the client side, and it is not carelessness. The person who knows the answers has a full-time job already, and the project was added on top of it. The second cause is on the supplier side: progress reported as percentages and reassurance when it should be shown as working software.
Early sign: questions from the developers sit unanswered for more than a couple of days, or you have not seen the system running for a month.
What to do: name one person on your side who can make decisions about the system, and give them the time to do it. Ask for a demonstration of working software at a regular interval, every week or two, and treat a cancelled demonstration as information.
3. Dependence on one person
A system built by one developer, whether an employee, a freelancer or the only person at a supplier who ever worked on it, is fine until that person is ill, busy or gone. Then nobody can change it, and sometimes nobody can even find everything it runs on.
The same problem appears in teams in a milder form. One person holds the passwords, or is the only one who knows how to release a new version, or wrote the part that nobody else will touch.
Early sign: the answer to “who else could do this?” is nobody.
What to do: make sure the source code, the hosting accounts and the domain names are held in your organisation’s name and not in an individual’s. Ask for written instructions for building and releasing the system, and have a second person follow them at least once. Check the contract says the code is yours; our note on who owns the source code of bespoke software explains what to look for, and it is worth taking legal advice on the wording.
4. Costs that run away
Cost trouble comes in two forms. In the first, the price was fixed and the scope was not, so every clarification becomes an argument about whether it is a change. In the second, the work is charged by the hour with no agreed limit, and the bills keep arriving while the finish stays just out of sight.
Neither way of charging is the problem. A fixed price works when the deliverable is clear and both sides have agreed how changes will be handled, as we explain in when fixed-price software development works. Charging for time works when the work really is open-ended, provided there is a budget, a regular review and the right to stop. What fails is a number given before anyone has looked at the existing data, the systems to be connected and the rules the business takes for granted.
Early sign: the quote arrived quickly with no questions asked, or the monthly invoices are not tied to anything you can see working.
What to do: pay for a short investigation before the main price is set, so the unknowns are examined first. Agree in writing that any new request is assessed and quoted before it is built, and that nothing is added to the bill without your approval.
5. Too little testing
Software that has been tested only by the person who wrote it works when used as they expected and fails when used any other way. Users find the faults, confidence drops, and each fix carries a risk of breaking something else because nothing checks the parts that were working.
Testing is the first thing cut when a deadline is tight, because its absence does not show on the day of delivery. It shows over the following months. The same applies to code written with AI assistance, which is now common: it is produced faster, and it needs the same checking as any other code.
Early sign: releases are followed by a run of urgent fixes, or the same fault comes back after it was reported fixed.
What to do: ask how the software is tested, and expect a specific answer. A sound answer includes automated tests that are run before every release, so that a change which breaks existing behaviour is caught at once. That practice is called regression testing. It also includes a period in which your own staff try the system with real examples before it goes live.
If a project already shows these signs
One of these on its own can usually be put right in a conversation. Several together, getting worse, is the pattern of a project in trouble.
Start with facts, not blame. Ask to see what has been built, running, and compare it with what was agreed. Confirm that you hold the current source code and control of the accounts. Then list what is finished, what is partly done and what has not been started. That list tells you whether the project needs a firmer plan, a pause, or a second opinion from someone outside it. If it is the last of those, our project rescue page describes how an independent assessment works.
For a project that has not started yet, the cheapest protection is five questions to put to any supplier:
- How will we agree that each piece of work is finished?
- Who answers your developers’ questions, and how quickly do you need answers?
- Who else at your company could take over this work?
- What happens, and what does it cost, when we ask for something that is not in the scope?
- How is the software tested before we see it?