How do you choose the right software house?
Ask ten questions before signing, not after. According to McKinsey around 70% of process transformation projects miss their objectives, and the reason is almost never the technology: it is how the work was set up. The questions that matter cover experience in your kind of process, who owns the code, and what happens when requirements change.
Choosing a software supplier is a decision you pay for over years: the wrong one does not show up in month one, it shows up when the process changes and the software will not follow.
According to McKinsey, roughly 70% of process transformation projects miss their objectives, and almost never because of the technology: the reason is how the work was set up.
Below are the ten questions we think change the outcome. For each one: why it matters, what a poor answer sounds like, and the answer we give. If ours do not convince you, you still have the questions to ask everybody else: this article is useful even if you do not choose us.
1. What experience do you have with our kind of process?
Not “in our industry”: in our kind of process. Somebody who has already built batch traceability knows the three questions that sink the project, and asks them on day one.
Poor answer: “we work across all sectors.”
Ours: industrial processes (production, warehouse, laboratory). Outside that we say no, and it happens.
2. Can I see cases with a name and a number?
A portfolio with no names and no numbers is a portfolio of descriptions.
Poor answer: “we cannot say who, for confidentiality.” Sometimes that is true. But if it is true for every client, then it is a policy, and a policy like that should be stated.
Ours: we are collecting permission to publish names and figures. Until they arrive, our site says figure to be collected instead of an invented number. If you ask for references privately, we give them.
3. What technologies do you use, and who will maintain them in three years?
The second half is the part that matters. A technology nobody in the area knows ties you to the supplier who chose it, and it is a cost you discover late.
Poor answer: the list of technologies without the reasoning.
Ours: widely adopted, well documented tools, chosen with an eye on whoever maintains the system after us. We keep the unusual choices for data acquisition and performance under load, where they earn their place.
4. How do you gather requirements?
How a supplier gathers requirements tells you what project they will build. Somebody who gathers them in a meeting room will deliver the process as written in the procedures; somebody who goes to the shop floor will deliver the process as it is.
Poor answer: “send us the specification and we will quote.”
Ours: half a day on site before any quote, watching the people who do the work. We look for the shortcuts the floor has already invented: they are proof of where the official process does not hold.
5. How is the work organised, week by week?
Poor answer: “we use Agile.” Everybody says it, and it means everything.
Ours: every week there is something working to try, not one distant delivery. The perimeter is reviewed at short intervals, to move the priorities as the work goes on. Architecture decisions and the release stay with a named person, and at the end there is a system working on real data.
6. How do you assure quality, and who answers when it breaks?
Poor answer: “we do testing.”
Ours: code review between people, automated tests at several levels, and one named person answering for the release. We are certified ISO 9001:2015, which does not certify that the software is good: it certifies that the procedures exist, are written down, and are audited by an outside body every year.
7. How much of our time will this take?
Anybody who answers “hardly any” is selling, not designing. Process software that costs the client no time is software built on assumptions.
Ours: half a day on site at the start, one person who can decide, and a recurring hour to review priorities together. Three things, said before signing, and without them the method does not work.
8. What happens when requirements change mid-project?
They always do. The real question is whether the contract makes change possible or painful.
Poor answer: “we handle it with a change request.” Translation: every discovery becomes a negotiation.
Ours: change is provided for in the contract. A priority can move without reopening the agreement, because what we keep fixed is the way of working, not the list of features.
9. When do you release, and how often?
Poor answer: one date, far away, with everything in it.
Ours: something to try every week. If there is nothing to show in a given week, that is the thing to talk about in the meeting.
10. What happens after go-live, and on what terms?
The moment a supplier becomes inconvenient is when the project is finished and the software is in service.
Ours: fine-tuning in production sits within the deadlines we sign in the contract. In the first weeks something the testing had not seen almost always turns up, and we are there to fix it; defects in the software we correct at our own cost, under the legal warranty. Further development is separate work, and support is bought with its own agreement, with response times in writing if you need them. Once the work is paid for, the code is yours: if you decide to bring the system in house or hand it to somebody else, we hand it over in a form another team can pick up.
What to watch for
Some answers tell you more than others, and all in the same direction:
- A quote that arrived without anyone visiting. The scope was imagined.
- No no. A supplier who says yes to everything will say yes when they should be warning you.
- The team you meet is not the team that will work. Ask for the names of the people who will write the code, and whether they will change.
- “The source code stays with us.” On custom software that is a position that has to be declared up front, because it decides what happens if you ever want to change supplier.
- Technologies without the reasoning. A list is not a choice.
Comparing three quotes
They are usually not comparable, and the difference is not price: they are quoting different scopes. To make them comparable you need five lines, the same for everyone: the list of screens, the integrations one by one, what happens when the source system is down, who owns the code, and what is included after go-live.
With those, the most expensive quote often turns out to be the cheapest: it is the only one that counted the integrations.
The point behind the ten questions
The Project Management Institute has measured for years how much management weighs on project outcomes, and the direction is always the same: it matters more than how the code is written.
All ten questions are there to find out one thing: whether the supplier will tell you the truth when things go wrong. Technologies can be learned, a late project can be recovered; a supplier who hides a problem for three weeks cannot.
If you want to try with us, the shortest route is to tell us about the process, not the software: get in touch. If you would rather see how we work first, the method is written out in full.