How can you tell whether IT consulting advice is genuinely independent?

Independent IT consulting advice is advice produced through a transparent, evidence-led process in which the business need determines the outcome, rather than a supplier relationship or sales target. Independence is not proved by a claim on a website; it is assessed through the consultant’s commercial arrangements, working method, evidence, documentation and willingness to recommend that no change is needed.

Start by examining how the consultant is paid. Ask whether the engagement is funded solely by your organisation or whether the adviser can receive referral fees, rebates, reseller margin, implementation revenue or other benefits from a recommended supplier. These arrangements do not automatically make advice invalid, but they create a potential conflict that should be made clear before any recommendation is accepted. The consultant should also explain whether the same firm would be paid to implement the proposed solution and how that affects the independence of its assessment.

A credible consultant should be comfortable separating advisory work from procurement and implementation. This may involve agreeing a fixed scope for the assessment, setting out any later implementation work as a separate decision, or allowing the business to purchase and deploy the chosen solution through another route. A recommendation that can only be delivered by the adviser’s own team deserves closer scrutiny, particularly where the technical and commercial alternatives have not been documented.

Check whether the advice begins with your operating requirements. Before discussing products or platforms, the consultant should establish how the organisation works, which processes depend on technology, what constraints exist and what risks are material. Relevant questions may cover:

• Which business processes must remain available and which can tolerate disruption?
• What information requires stronger protection, and who needs access to it?
• What skills, resources and support arrangements are available internally?
• Which regulatory, contractual or insurance requirements affect the decision?
• What technical debt, integration dependencies or legacy constraints could alter the options?
• How will the proposed change be operated, maintained and reviewed after implementation?

If a consultant reaches a firm solution recommendation before understanding these factors, the process may be product-led rather than genuinely advisory. Independent advice should connect each proposed capability to a defined business requirement and identify requirements that are not essential. It should also distinguish between a mandatory control, a useful improvement and an optional feature.

Look for a documented decision method. Good advice normally shows how options were assessed against criteria that matter to the organisation. Depending on the engagement, those criteria could include security controls, resilience, integration, administrative effort, data location, exit arrangements, scalability, user impact and total cost of ownership. The weighting of each criterion should be understandable rather than selected to favour a predetermined result.

The assessment should consider the full lifecycle, not just the initial purchase price. Migration effort, licensing changes, training, configuration, monitoring, support, renewal terms and eventual replacement can all affect the suitability of an option. A low initial cost does not necessarily represent the lowest long-term cost, while a technically capable solution may be unsuitable if the organisation cannot operate it effectively.

Ask for the assumptions behind the recommendation. Advice is easier to test when it identifies the information on which it relies. Assumptions might relate to user numbers, connectivity, data volumes, existing equipment, application compatibility, recovery requirements or available staff time. Each important assumption should have a validation method, such as a technical discovery exercise, configuration review, proof of concept, supplier clarification or controlled pilot.

Pay attention to how uncertainty is handled. An independent consultant should identify unresolved questions and explain how they could change the decision. Overconfident conclusions that contain no limitations, dependencies or conditions are less useful than a qualified recommendation that shows what is known and what still needs to be tested.

Test whether alternatives have been considered fairly. Independence does not require every possible technology to be assessed. It does require a rational explanation for the shortlist. The consultant should be able to state why an option was included, why another was excluded and whether an alternative would become more suitable if a particular constraint changed. This can include retaining the current arrangement, making a smaller improvement or postponing a major change until better information is available.

References to alternatives should be specific enough to support review. Statements such as a solution being the best, most secure or most scalable are not meaningful without the criteria and evidence behind them. Ask what was tested, what documentation was reviewed and which findings materially affected the conclusion.

Review the written deliverables before approving action. A useful independent assessment should leave an audit trail. Depending on its scope, this may include the stated objectives, current-state findings, risks, requirements, options considered, evaluation criteria, assumptions, dependencies, cost categories, implementation implications and recommended next steps. It should be possible for a decision-maker who did not attend every meeting to understand how the conclusion was reached.

The language should also separate fact from professional judgement. For example, a configuration finding can be presented as evidence, while the priority assigned to correcting it is a judgement based on business impact and risk. This distinction helps stakeholders challenge the reasoning without treating every disagreement as a technical dispute.

Watch for practical warning signs. Independence may be questionable where the consultant:

• introduces a named solution before carrying out meaningful discovery;
• uses urgency or fear to prevent reasonable evaluation;
• will not explain how commercial interests are structured;
• provides only one option without showing the selection criteria;
• treats implementation work as an unavoidable part of the recommendation;
• dismisses the existing environment without examining whether it can be improved;
• avoids documenting assumptions, limitations or unresolved risks; or
• cannot explain how the recommendation would be reviewed if circumstances change.

These signs are prompts for further questions rather than automatic proof of misconduct. A specialist may have strong experience with particular technologies, and a consultant may reasonably recommend a familiar approach where it fits the documented requirements. The important issue is whether the method remains open to evidence and whether the commercial relationship is visible to the people making the decision.

Use proportionate assurance for high-impact decisions. For a major infrastructure, security or cloud change, the organisation can ask an independent party to review the requirements, assumptions and proposed design before committing. A focused peer review may be sufficient; a larger decision may justify a separate options appraisal, proof of concept or procurement exercise. The reviewer should be given the original evidence, not only the preferred supplier’s proposal, so that the assessment covers the decision process as well as the technical design.

Ultimately, genuinely independent advice leaves the business able to explain why it chose a particular course, what risks remain, what alternatives were considered and what would cause the decision to be revisited. That level of transparency is a more reliable indicator of independence than a consultant’s description of its own services.