A consultant can know the software well and still misunderstand the business decision it must support. The gap often appears in a small question: when does a delivery promise become binding, what makes a quantity usable, or which evidence establishes that a service has been completed?
Industry knowledge matters because it helps the team recognize those questions before they become expensive design assumptions. It is most valuable when it produces better investigation, clearer tradeoffs and more credible tests. Familiar terminology and a long list of sector logos are weaker evidence on their own.
For a buyer selecting a technology partner, the useful task is to evaluate how the proposed team reasons through your operating conditions. The aim is neither to find someone who claims to know everything nor to make the consultant reproduce your entire business during procurement. It is to establish whether their experience will improve the decisions that matter in the engagement.
Look for questions that change the design
Consider a hypothetical produce distributor whose customer contract requires at least five days of remaining product life when goods are received. A candidate lot has seven days remaining at dispatch. Under a simplified assumption of three elapsed days in transit, four days remain at receipt, so the lot would not meet that commercial condition.
The example is deliberately limited. It does not establish product safety, legal saleability, the meaning of a particular date label or the correct treatment of any real food product. Those questions belong to qualified specialists and applicable requirements. The five-day condition and all quantities are assumed solely to illustrate a business requirement.
A consultant who records only “track expiry date” has not yet defined the decision. A more useful investigation asks whether the requirement applies at dispatch or receipt, how the relevant dates and elapsed time are interpreted, which customer and product conditions apply, and what happens when the expected arrival changes.
Transit variability matters as well. A three-day planning assumption is not a guarantee. The team should identify the evidence and policy used to make a promise, who can approve an exception where an exception is permitted, and when the customer must be involved. A technical date comparison should implement an agreed rule, not invent it.
These questions affect allocation, order review, transport planning, exception communication and testing. That is the practical value of domain judgment: it reveals a consequential requirement that a generic feature checklist could miss.
Distinguish experience from an unsupported claim of fit
A relevant reference should help you understand the work performed, the consultant’s actual role and the conditions under which the result was achieved. “We worked with a distributor” says little about whether the team handled your type of commitment, operating model or transition risk.
Ask which decisions the proposed people personally contributed to and what evidence they used. A firm may have relevant experience without assigning those experienced people to your project. Clarify who will lead discovery, who will review difficult domain questions and how specialist support becomes available when needed.
Respect confidentiality. A consultant should be able to explain a method, a sanitized decision or a transferable lesson without exposing another customer’s sensitive information. Refusal to disclose private records is not evidence of weak experience; inability to explain the reasoning at any useful level may be more informative.
References also need context. A successful design for a simple single-site operation may not transfer directly to a business with multiple entities, partners or service obligations. Ask what would need to be checked before applying the earlier approach to your situation.
The best evidence is not always an identical industry label. Experience with a closely related operating constraint may be valuable, provided the consultant identifies the differences and does not assume equivalence. Conversely, years in the same sector do not guarantee current knowledge of your process or the selected technology.
Use a bounded working session to observe judgment
Give shortlisted teams a concise, representative scenario with enough facts to make the problem meaningful. Include a normal case and one exception. Make clear which information is deliberately unknown, and assess whether the team asks useful questions rather than rewarding confident guesses.
For the hypothetical remaining-life case, provide the customer condition, the lot dates and a planned transport duration. Ask what the system must establish before confirming the order and what changes if arrival is delayed. A strong response should identify missing definitions and the accountable business roles before proposing automation.
Do not turn this session into an unpaid full solution design. Keep the exercise proportionate, disclose how it will be evaluated and use equivalent information for each candidate. A paid discovery engagement may be more appropriate when the problem requires substantial analysis or access to detailed operations.
Look for a traceable sequence from business condition to design implication to acceptance evidence. The consultant should be able to say what would make their initial recommendation wrong. That willingness to define a disconfirming test is more useful than an impressive diagram that cannot be challenged.
The session also reveals collaboration style. Do specialists listen to operational staff? Do they distinguish a policy decision from a technical limitation? Can they explain a tradeoff to finance and frontline users without replacing precision with jargon? Those behaviors will matter repeatedly during delivery.
Combine domain knowledge with technical and change capability
Industry understanding is necessary in many engagements, but it is not a substitute for sound integration, data, security or delivery practice. A specialist who recognizes the right business rule can still implement it poorly or overlook the operational consequences of a migration.
Evaluate the proposed team as a combination of capabilities. Identify who owns the industry interpretation, the technical design, the data evidence, the testing strategy and the transition into normal operations. Where responsibilities overlap, define how disagreements are resolved.
In the produce example, a domain specialist may clarify the commercial requirement while a planner explains actual transport uncertainty, a data owner validates date information and a technical architect designs the relevant checks. Qualified safety and compliance roles retain their own judgments. No single consultant needs to replace all of them.
The team also needs to understand how people currently compensate for weak information. A planner’s spreadsheet may contain undocumented customer conditions. Removing it without recovering that knowledge can make a technically cleaner system operationally worse.
Ask how the partner will transfer understanding to your staff. A design that works only while an external specialist interprets every exception creates a continuing dependency. Documentation, worked examples, training and reviewable decision records should leave the business able to operate and change the solution responsibly.
Avoid turning industry practice into unquestioned authority
Experienced consultants can recognize patterns quickly, but a familiar pattern can also hide a different problem. “This is how the industry does it” should begin a discussion about evidence and fit, not end one.
Ask whether a practice is a legal requirement, an applicable standard, a customer commitment, a common convention or simply the consultant’s preferred design. Those categories require different evidence and different decision authority. A convention may be worth following without being mandatory; a customer-specific commitment may matter even when it is uncommon.
Verify consequential regulatory, technical or accounting interpretations with the appropriate qualified roles and current primary sources. An enterprise project should not rely on a consultant’s recollection of a rule when the implementation will enforce it across many transactions.
Also test whether the suggested approach creates unnecessary customization. Domain expertise should help identify the few distinctions the business truly needs, not justify reproducing every historical habit in code. Sometimes a standard process can meet the underlying need once the organization clarifies its policy.
The opposite risk is excessive standardization. A consultant should be able to explain why an apparently small industry distinction cannot safely be ignored. The goal is a reasoned boundary between necessary capability and avoidable complexity, supported by the actual operating consequences.
Put the engagement around evidence and accountable decisions
ISO 20700:2017 provides guidelines for effective delivery of management consultancy services. Its existence is a reminder that consultancy is itself a service to define and manage, not simply access to an expert’s time. The evaluation approach in this article is a proposed buyer practice; it is not an ISO certification test or a claim to reproduce the standard’s requirements. ISO 20700 public abstract.
Before committing to a major phase, agree the decisions the engagement must support, the evidence to be produced, the business participation required and the acceptance responsibilities. A discovery deliverable should make consequential assumptions visible rather than merely summarize interviews.
For a high-risk requirement, retain a short decision record: the business condition, its source, alternatives considered, selected approach, accountable owner and test that demonstrates the intended result. This gives later team members a way to understand why the design exists and when it needs review.
Commercial arrangements should also make specialist availability and knowledge transfer concrete. If the engagement depends on a particular capability, clarify how it will be provided and what happens if the named person is unavailable. Appropriate procurement and legal review can turn that dependency into an explicit arrangement.
Industry expertise earns its value when it changes the quality of a decision. A strong technology partner helps the business ask the right questions, recognizes where further evidence or specialist authority is needed, and leaves behind a design that people can explain and operate. Buyers can test for those qualities before relying on a reputation alone.
