In this post
More choice initially increases the decision-making effort
A digital tool should not be chosen based on its feature set or popularity, but rather on its task, process, data, interfaces, responsibility, total cost, and ease of switching. The strategic decision is not: Which product can do the most? It is: Which solution fulfills the specific purpose with manageable dependencies?
The larger the tool landscape becomes, the more important a joint architecture decision is. Otherwise, parallel data sets, duplicate functions, and responsibilities will emerge that no one fully oversees.
Starting point
At the beginning of 2021, the number of digital applications for communication, collaboration, marketing, sales, and analytics was already large. Many companies had introduced additional tools in the preceding months to remain operational at short notice or to create new digital contact channels.
The selection seemed convenient at first glance. For almost every task, there were several specialized solutions. At the same time, the decision became more difficult. Products differed not only in features and price. They influenced data storage, processes, interfaces, access, training effort, and future switching options.
This shifted the central question. The availability of a tool was no longer the problem. The ability to make a sound selection decision became the bottleneck.
What lies behind the problem
Feature lists do not replace requirement logic
Tool decisions often start with product pages, recommendations, or a list of desired features. This perspective comes too late. Before comparing features, it must be clarified which task in the existing process is to be improved.
A CRM can have many functions and still be unsuitable if sales phases, data responsibility, and maintenance processes are unclear. A newsletter system can be powerful and still create additional effort if content, consents, and contacts are managed separately across multiple systems. A project tool can promise transparency and yet become just another isolated island.
The requirement therefore does not arise from the product. It arises from the problem, the user group, and the process.
A tool changes the workflow
New software is often viewed as neutral support. In fact, it brings its own data models, roles, operating logic, and standard processes. This can be useful if this logic matches the company. It can become problematic if a historically evolved process is adopted solely because the tool dictates it.
Therefore, the selection must examine both directions:
- Does the tool fit the necessary process?
- Is the existing process sensible at all, or should it be simplified before digitization?
Without this check, either a bad process will be digitized or a company will unnecessarily bend for the software.
The purchase price shows only part of the costs
The total costs are not just made up of licenses. In addition, there are setup, data migration, interfaces, training, internal maintenance, rights management, support, documentation, and possible changes.
A supposedly inexpensive tool can become expensive if data is difficult to export, central functions require additional products, or individual adjustments permanently require external help. Conversely, a higher license can make sense if it replaces several controlled individual solutions and simplifies operation.
Every addition creates dependencies
Official technology guidelines have emphasized open standards, portability, interoperability, and the ability to change decisions later for years. These criteria are not purely technical details. They determine whether a company continues to control its data, processes, and vendor changes.
A dependency is not fundamentally bad. Every system creates dependencies. The crucial point is whether they are known, justifiable, and contractually as well as technically manageable.
Strategic Classification
The GOV.UK Service Manual formulates a clear principle for technology decisions: the selection should make it possible to change direction later, adapt the technology to new insights, and effectively manage security risks. The Technology Code of Practice complements this with open standards, reusability, and the avoidance of unnecessary vendor lock-in.
These guidelines originate from the public sector, but the decision criteria are transferable to companies. Technology is not chosen solely for its current function. It is chosen for a lifecycle in which requirements, responsible parties, and adjacent systems change.
The smallest viable solution
A sensible selection principle is: Do not choose the maximum possible solution, but rather the smallest viable one.
"Small" does not mean the smallest possible feature set here. It refers to a solution that:
- fully accomplishes the essential task
- fits into existing processes and data flows
- can be mastered by the responsible persons
- possesses necessary interfaces
- meets adequate security and data protection requirements
- enables realistic operations
- does not unnecessarily block future changes
Additional features are only an advantage if they can be foreseeably used and managed responsibly.
Weighing standardization and specialization
Companies often find themselves caught between a broad platform and several specialized tools. There is no one-size-fits-all answer.
Broad platforms can bundle data and access. However, they can also be too extensive, expensive, or inflexible. Specialized tools can solve individual tasks better. However, they increase interfaces, coordination, and administrative effort.
The decision should be based on the strategic importance of the task. A differentiating core process may justify a specialized solution. For interchangeable standard tasks, consolidation is often more sensible.
Perspective from practice
A robust selection process does not start with a demo. It starts with a brief requirements profile. In practice, seven fields are often sufficient for this:
- What problem needs to be solved?
- Who uses and who is responsible for the tool?
- What data is needed, generated, and passed on?
- What existing systems does it need to fit into?
- Which requirements are indispensable, which are merely desirable?
- What do operation, maintenance, and support look like?
- How can data and processes be transferred or terminated later?
These questions also change the product demo. Instead of having the entire range of features demonstrated, a specific workflow is tested. Vendors must explain how data is exported, how permissions work, what interfaces exist, and which tasks remain outside the product.
A second practical principle is: The tool needs a responsible role before purchase. If no one takes responsibility for operation, data quality, and further development, the introduction is not yet ready for a decision.
Decision tree for digital tools
Framework of action
1. Describe the problem and desired change
Formulate the current state, the desired state, and the affected roles. Avoid requirements like "We need a modern CRM." Instead, describe which decision or workflow should be improved.
2. Separate must-have and nice-to-have requirements
Limit indispensable requirements to what is truly necessary. Extensive wish lists automatically favor complex products. Every optional feature should have a discernible use and responsibility.
3. Review data and interfaces
Clarify ownership, export, import, data formats, rights, deletion options, and necessary connections. Also check which manual handovers remain despite integration.
4. Plan operations before introduction
Determine system ownership, user management, documentation, training, support, and review frequency. A tool without an operating model quickly becomes an isolated silo tied to specific individuals.
5. Consider transition and end from the start
Before signing a contract, ask how data can be fully exported, integrations resolved, and processes transferred. An exit perspective does not weaken the decision. It makes it more resilient.
What companies should not do
Companies should not test multiple tools in parallel without first establishing common criteria. Otherwise, the most convincing presentation often wins instead of the most suitable solution.
Equally problematic is selecting based on the largest possible feature set. Unused features increase complexity and can distort decisions. The tool then becomes the framework into which processes are retrofitted.
Consequences for companies
Tool selection is an architectural and responsibility decision. It influences how information flows, how flexible processes remain, and how much administrative overhead will arise in the future.
The growing selection therefore requires not more product knowledge, but better criteria. Companies must understand their problem, their process, and their dependencies more precisely. Only then will technology become the appropriate means instead of the starting point of the strategy.
Deepening the strategic classification of measures "More digital measures do not create a digital strategy". How selected systems are integrated into a roadmap is shown by "What a robust digital roadmap must achieve". The later consolidation of grown landscapes deals with „Fewer tools, clearer systems, better decisions“.
The overall overview is provided by the Subject Areas Digital Strategy.
Subject-matter connection
Check system and tool decisions before commitment
Digital system and strategy consulting combines technical requirements, processes, data, integrations, operations, and migration options. It helps derive a selection not from product promises, but from the company's purpose and the manageable overall architecture.
Evaluate digital system decisions in a structured manner
Sources and technical foundations (5)
- GOV.UK Service Manual, "Choosing technology: an introduction". Open source
- GOV.UK Service Standard, „Choose the right tools and technology“. Open source
- GOV.UK, "The Technology Code of Practice", 2021. Open source
- GOV.UK Service Manual, "Working with open standards". Open source
- NIST, "Cloud Computing Standards Roadmap". Open source
