Failed does not always mean a project is abandoned. Often the software runs in the end, but nobody likes using it. Staff keep their Excel list going, half the functions go unused, and the budget has been spent all the same.
This article describes the reasons we see again and again from the client’s side, and what you can do about each of them. Not every reason lies with the client. But the client can do something about every one of them.
The workflow was not understood
It starts with a wish: “We need an order management system.” What then gets developed is whatever the supplier understands by order management. The business’s special cases, the exceptions, the rules that exist only in one colleague’s head only come to light once the software is finished. Then it does not fit, and putting it right is expensive.
What helps: Write the process down before anything is developed, the way it really runs and not the way it is described in the manual. How to do that is described in Documenting business processes.
Everything was meant to arrive at once
The new system is meant to cover quotes, orders, stock, invoices and field staff, all on the same go-live date. That means every uncertainty grows at the same time. By the time the first function is used day to day, many decisions have been made that nobody was ever able to check.
What helps: Broad for the whole, precise for the first area. A high-level concept sets the direction, and the first area is chosen so that it is useful on its own. More on this in High-level and detailed concept.
Your own experts had no time
The people who know the workflow best are also the ones the day-to-day business cannot do without. So the project is supported “on the side”. Questions are left unanswered, drafts are not looked at, and the supplier ends up deciding what the business should really decide.
What helps: Plan your experts’ time the way you plan the budget. Name one person who knows the process, answers questions promptly and is relieved of some day-to-day work for it.
Nobody made decisions
May field staff grant discounts themselves? Does the new rule apply to existing customers too? Questions like these come up in every project. If nobody decides them, they are postponed, or everyone decides them differently. “We’ll sort it out later” is a common reason for extra effort.
What helps: Decide who makes the decisions in your business, and give that person the authority to do so. Open questions belong on a list with a name and a date, not in the next meeting.
The contacts kept changing
At the first meeting someone experienced sits at the table, a different team does the work, and later someone new again is responsible. With every change, knowledge is lost that was never written down. The same applies on your side if the person responsible for the project leaves the business.
What helps: Ask beforehand who your contact will be, and whether that person will stay on until the software is in use. Which other questions to ask a supplier is covered in Choosing a software partner.
Everything was switched over in one day
On the cut-over date the old system is switched off and the new one started. If something does not work that day, the business comes to a standstill and there is no way back. Under that pressure, faults are fixed in a hurry, and staff trust is quickly lost.
What helps: Where possible, switch over area by area while the old system is still running. Both approaches are compared in Cut-over date or step by step.
Testing used made-up examples
The software works with “Sample Ltd” and an order for three items. Then real life brings the customer with four delivery addresses, the order with a hundred lines and the invoice with a special discount. Nobody tried that beforehand.
What helps: A test environment separate from live operation, and acceptance testing with real examples from your day-to-day work, by the people who will use the software later. How that works in practice is described in Acceptance and test environment.
Staff were asked too late
The software is planned in the managing director’s office and presented at the end. Staff see it for the first time when they are supposed to work with it, and immediately find what does not fit. Then the resistance is high, even if the software is good.
What helps: Involve the people who will work with it every day from the start: when the workflow is mapped, with the first drafts and in testing. People who had a say work with the result.
Running it after launch was not settled
The software is finished, the project closed. Then comes the first operating system update, the first bug, the first change request. Who takes care of it? If nobody settled that beforehand, the software ages before it has paid for itself.
What helps: Operation, maintenance and further development should be agreed before launch, not afterwards. What that involves is covered in Software after launch.
Everything depended on one person
A freelance developer who is the only one who knows the source code. A colleague who is the only one who knows how the interface is set up. As long as that person is around, nobody notices. When they leave, the software stands still.
What helps: Source code, access and documentation are in your hands, and more than one person knows the software. What you own of software you have paid for is described in Who owns your software?, and what to do if it has already happened in Taking over software without its developer.
What the reasons have in common
Hardly any of these reasons is technical. Almost all of them arise at the start, long before anyone writes a line of code, and almost all of them can already be spotted in the first conversation. That is why it pays to look there more closely than at the question of which technology is used.
Checklist before you start
- Is the workflow written down so that staff recognise it?
- Is it clear which area comes first, and is it useful on its own?
- Does the person who knows the process have time for the project alongside the day-to-day work?
- Who decides open questions, and are they authorised to?
- Will your contact at the supplier stay the same until the software is in use?
- Will testing use real examples from your day-to-day work?
- Is it settled who looks after the software after launch?
- Are the source code and access in your hands?
