Why External Consultants Rarely Find the Right RM Tool and How to Do It Better

1. Lack of understanding of requirements, structures, and reality

Requirements management is not just a tool issue. It is a reflection of a company's working methods, thinking, and product structure. An RM tool has a profound impact on processes: from the way requirements are created, to communication between departments, to the question of how decisions are documented and made traceable.

However, this is precisely where the core problem lies. External consultants only have a superficial knowledge of the organization and perhaps a few other companies in the industry. They see selected documents, talk to a few key people, take a look at the organizational chart, but all of this remains a snapshot. What they don't really grasp are the many invisible factors: how decisions are actually made, where friction losses occur in everyday life, or which coordination channels are informal but crucial.

What's more, corporate reality is often contradictory. In addition to technical requirements, budget constraints, political conditions, existing IT landscapes, and even the personal preferences of decision-makers all play a role. Consultants can hardly grasp these aspects in depth, simply because they are not involved in day-to-day business.

The result is almost always the same: tools are recommended that look good on paper, are convincing in PowerPoint slides, and shine in general comparison tables, but in practice are either oversized, seem unenforceable, or simply do not fit the actual working methods of the company.

The result is sobering: instead of relief and clarity, the introduction brings more discussion, resistance, and adaptation costs than originally expected.

‍

2. Focus on features instead of real support

Another common mistake in externally supported selection processes: consultants create huge lists of criteria – sometimes with over 100 points – and then check how many boxes each tool ticks. In the end, the solution with the most boxes automatically seems like the best choice.

But this is precisely where the error in reasoning lies. What gets lost in the process is the crucial question: Can the tool meaningfully support our own way of working?

Because the key question is not: Does the tool have this function? Rather: How well is this function implemented and does it really fit our approach, our organization, our people?

‍This is particularly critical when it comes to RM tools. Their usefulness is not evident in the user interface or the number of features, but in their depth:

• How flexibly can the structure be adapted to your own product logic?
• How clearly can relationships and dependencies be modeled?
• How much does the tool support your daily work – instead of creating additional effort?

These are questions that cannot be answered with an Excel sheet. A spreadsheet can measure whether a function exists, but not whether it is practical. And even a quick look at a demo version is not enough to get a feel for whether the tool really works in everyday use.

The result: companies end up with tools that are theoretically “suitable” but in practice are either too complex or too simple to ever really be used in a way that adds value.

‍

3. Between bias and arbitrariness: the wrong focus of many consultants

Our experience shows that the quality of a tool selection depends heavily on the type of consultant. Unfortunately, we repeatedly encounter two extremes, both of which are equally problematic.

• The biased:
  They prefer to work with the tools they are already familiar with. Sometimes because they earn money from partnerships or commissions. Sometimes simply because they feel comfortable with them and are reluctant to break new ground. The result: instead of an objective analysis, companies receive a preconceived recommendation, regardless of whether this solution is really suitable.
• The arbitrary:
  They shortlist everything the market has to offer. Project management tools, wiki systems, ticket solutions with a “requirements module” – the main thing is that the list is long. This has little to do with finding the right fit, but it increases the scope of consulting and thus the fee.

The crucial point that many overlook: The tool landscape in the area of requirements management is not that large.

In German-speaking countries, there are perhaps a dozen serious solutions. The rest are tools that can only marginally map requirements, but never achieve the depth and logic of a true RM tool.

The challenge, therefore, lies not in the number of options, but in recognizing the actual fit:

• How well does the tool reflect the specific processes of the company?
• How clearly can it be integrated into existing IT landscapes?
• And above all: How well does it work in practice with the people who will later use it on a daily basis?‍

These questions cannot be answered with bias or arbitrariness, but only with real practical relevance. This is precisely where many consulting approaches fail, because they try to make a decision based on tables and standard criteria that should actually be made in the real project environment.

‍

4. When information gets lost

Another often underestimated problem is that consultants are translators between the manufacturer and the customer and in the process, something regularly gets lost.

In selection processes, consultants hold discussions with tool providers, have functions explained to them, and try to prepare these findings for the company. However, especially with more complex topics, it often happens that important details are misunderstood or simplified.

The consequences are serious:

• A solution that would have been exactly right suddenly seems unsuitable to the customer simply because a crucial aspect was not communicated correctly.
• Or vice versa: a tool appears attractive because weaknesses were not addressed or were simply overlooked.

This does not happen out of malice, but because requirements management is a complex field that cannot be grasped in its entirety “on the side”. When consultants try to translate highly specialized concepts into general management jargon, the result is often a distorted picture, and the actual strengths or weaknesses of a tool remain hidden or are even reversed.

In the end, the company does not get the whole truth, but a filtered version, and makes its decision based on incomplete or distorted information.

‍

How to do it better: Involve consultants but don't let them make the decisions

Don't get me wrong: External consultants can be very helpful. They provide valuable input, help to avoid blind spots, and systematically identify requirements. They can structure the selection process, point out typical stumbling blocks, and ensure that no important aspect is overlooked.

But: They should not be the ones comparing, evaluating, or even preselecting tools.

‍Why?

• Because they are not the ones who will have to work with the tool later on.
• Because they are not familiar with internal resistance, political dynamics, and real needs.
• And because, in the end, they are not responsible for whether the tool is actually used or disappears back into a drawer.

The responsibility for tool selection must therefore remain within the company itself. Consultants are valuable supporters, but they should not be the decision-makers.

Three principles for good tool selection

To ensure that an RM tool really adds value and does not become a paper tiger, the selection should follow three clear principles:

1. Internal involvement instead of delegation

An RM tool changes the daily work of many roles - from product management and requirements analysis to system architecture, development, and testing. Therefore, those who will later work with the tool must be involved from the outset. In practical terms, this means that the relevant roles look at the tools themselves, discuss them together, and contribute their perspectives. This creates acceptance and significantly increases the likelihood that the tool will actually be used.

2. Focus on process compatibility instead of feature lists

The decisive criterion is not the number of features, but how well they fit your own approach.

A medium-sized tool that precisely supports your own way of working is more valuable in practice than a huge toolbox that no one can find their way around, but also better than a simple out-of-the-box tool that gives the impression that you can start right away.

So instead of checking off feature lists, the question should be: How well does the tool reflect our structures, processes, and way of thinking?

3. Hold providers accountable

Good manufacturers quickly recognize whether their tool is a good fit or not and they say so. You should actively use this knowledge. Instead of blindly playing through test accounts, dialogue is crucial:

• What structures do you have today?
• How do you currently work?
• Where are the biggest bottlenecks?
• What needs to be improved?

Providers who listen, think along with you, and offer concrete solutions are the most valuable partners. They have the deepest understanding of their own tool and are therefore best placed to assess whether it is really suitable.

‍

Requirements management is too important to outsource

The introduction of an RM tool is not a classic IT project that can simply be purchased like a server or standard software. It is an investment in better product development, clearer communication, and less friction.

That is why this decision should not be delegated to external consultants. The risk is too great that a tool will be chosen that looks good on paper but does not work in practice.

Does that mean consultants are superfluous? Not at all, because they can provide valuable support. But the roles must be clearly defined. The responsibility for selection lies with the people in the company who will later work with the tool and who are familiar with the internal conditions.

A frequently heard counterargument is: “We will make the final decision ourselves, but consultants should do the preliminary selection first.”

This sounds like a good compromise, but it is not. The decisive course is already set in the preliminary selection. If the wrong tools are eliminated at this stage, employees will never see them and thus have no chance of considering the best solution.

This is precisely where the biggest mistakes are made: a tool that would be perfect in practice is rejected simply because a consultant is unfamiliar with it, has not understood it properly, or because it did not fit into a standardized evaluation matrix.

The right approach is therefore to involve consultants as sparring partners, but to consistently anchor the pre-selection, evaluation, and final decision in-house.

Because only those who know the reality of the company can recognize the right tool.

And only those who are involved in the decision from the outset will use it with conviction later on.