Organisations rarely suffer from a shortage of technology - CRM platforms, ERP systems, workflow tools, marketing platforms, analytics solutions, AI products; there is almost always another system promising to make work faster, simpler or more intelligent.
Sometimes a new system is exactly what is needed but sometimes it becomes another login, another integration, another source of data and another layer of complexity sitting on top of the problem it was supposed to solve.
Before choosing the technology, it is worth asking a more fundamental question:
Do we actually need another system?
Here are ten questions worth answering before you buy one.
1) What problem are we actually trying to solve?
Not what software do we need or which vendor should we choose - simply ask:
what is the actual problem?
“We need a new CRM” is not a problem statement… but “we cannot see the complete relationship we have with a customer because information is spread across four systems and several spreadsheets” is.
This distinction matters because once the problem is understood properly, the solution could end up look very different.
2) Is the problem really caused by technology?
Technology often gets blamed for problems created elsewhere:
- A slow approval process may be caused by unclear authority.
- Poor customer data may be caused by inconsistent processes.
- Reporting problems may exist because nobody agrees which measures actually matter.
A new platform might make those problems easier to see without doing anything to resolve them.
Before replacing the technology it’s important to understand the system around it.
3) Could we remove something instead?
Organisations are very good at adding another process, another approval, another integration and yet another platform…
They are considerably less enthusiastic about removing things, however.
Before adding another system, ask whether an existing step, tool or requirement could simply disappear. Sometimes the best technology transformation involves less technology.
4) What do people actually do today?
The documented process and the real process are rarely identical - people create spreadsheets, copy information between systems, maintain unofficial lists, bypass approvals and ask particular colleagues for help because they know how things really work.
Those workarounds are valuable evidence so before designing the future system, it’s vital to understand the one people have already created for themselves.
5) Do we already have this capability somewhere?
Large organisations frequently buy functionality they already own… existing platforms may be poorly configured, badly integrated, underused or simply unknown to the people making the purchasing decision.
That does not automatically mean the existing technology is the right answer but it is worth knowing whether you already have one before buying another one.
6) What new complexity will this introduce?
Every system solves some problems and creates others so it’s vital to ask what the new platform will require:
- New integrations?
- New data flows?
- New user accounts and permissions?
- New skills?
- New governance?
- New support processes?
- New dependencies?
The question should not simply be “What can this system do?”; it should also be “What will we have to do because this system exists?”
7) How will it connect to everything else?
Integration should not be an afterthought. A system that works brilliantly in isolation can make the organisation worse if people have to manually move information between it and everything around it.
Understand where the data comes from, where it needs to go and what other processes depend upon it.
A new system should reduce fragmentation, not become another island.
8) What happens to our data if we leave?
This question is much easier to ask before signing the contract.
- Can you export your data?
- In what format?
- Can another system actually use it?
- What happens to documents, relationships, metadata, configuration and historical information?
- How difficult would migration be?
The ability to enter a platform is rarely the problem but the ability to leave one might be.
9) What does success actually look like?
“Implement the new system” is not success - it’s just an activity.
Success might mean reducing an approval from five days to one or removing three manual hand-offs.
It could also mean giving teams a single reliable view of customer information, reducing the time required to publish content or simply eliminating a collection of spreadsheets.
The business needs to define the outcome before the implementation begins otherwise, a technically successful deployment can solve very little.
10) If we were starting again, would we design it this way?
This is perhaps the most uncomfortable question…
Organisations accumulate technology over time - every decision may have made sense individually while the resulting landscape makes very little sense collectively.
So step outside the existing architecture for a moment and ask yourself:
If you were designing the process today, without the historical systems, organisational boundaries and assumptions - what would it look like?
You may still conclude that you need another platform but at least you will understand why.
Technology Should Remove Complexity
There is nothing wrong with buying another system and sometimes new technology unlocks capabilities that genuinely weren’t possible before.
The problem comes when purchasing technology becomes the default response to organisational complexity.
Before adding another platform, understand the problem, the process, the people, the information and the technology you already have.
Only then can you decide what needs to change.
The best technology decision isn’t always choosing the right system. Sometimes it’s realising you didn’t need another one in the first place.
