What evidence should an IT consultant provide before recommending a major change?
Before recommending a major change, an IT consultant should provide evidence from the current environment, including documented requirements, system data, identified risks, viable alternatives and a clear business case. The recommendation should show how the proposed change supports business objectives, affects users and services, and can be implemented and tested without creating unmanaged risk.
An IT consultant should provide auditable, decision-ready evidence before recommending a major change. That evidence should demonstrate how the conclusion was reached, distinguish verified facts from assumptions, show which options were considered, and identify the conditions under which the recommendation would no longer be appropriate.
Evidence should be traceable to its source. A credible assessment normally identifies where important findings came from. This may include configuration exports, asset records, service reports, licensing information, access reviews, architecture diagrams, supplier documentation, interview notes and relevant business records. Each source should have a date and a clear relationship to the conclusion being drawn. For example, a statement that infrastructure is unsuitable for future growth should be supported by specific technical constraints or observed capacity issues, rather than by a general view that the environment is old.
The consultant should also state the limitations of the investigation. If some systems could not be inspected, records were incomplete, or usage information was unavailable, that uncertainty belongs in the report. A recommendation based on partial evidence may still be reasonable, but the decision-maker should be able to see what remains unverified and whether further discovery is needed.
Technical findings should be separated from professional judgement. Evidence such as a failed control, unsupported operating system, recurring incident pattern or incompatible dependency is different from the consultant’s interpretation of what should happen next. A well-structured report makes both visible. This allows the business to challenge an assumption without having to dispute the underlying fact, and makes it easier for another qualified professional to review the work.
Where measurements are used, the consultant should explain what was measured and how. Useful context can include the period observed, the systems included, the method of collection and any factors that might distort the result. A single snapshot may not represent normal demand, while an incident report may show an exceptional condition rather than a persistent weakness. Evidence is stronger when the method is proportionate to the scale and consequences of the proposed change.
The recommendation should have a transparent evaluation model. Before a major technology decision is made, the consultant should define the criteria used to compare options. These may include compatibility, security control coverage, operational complexity, support requirements, data handling, integration, supplier dependency, continuity arrangements and the effect on different groups of users. The weighting of those criteria should be explained where one factor has been given greater importance than another.
An options appraisal should show more than the preferred choice. It should record the credible alternatives considered, the reasons for rejecting them and any circumstances in which a different option would be preferable. “Best practice” is not, on its own, evidence that a particular solution is right for a business. The recommendation should connect the selected approach to the organisation’s actual constraints and priorities.
Financial evidence should cover the whole decision, not just the purchase price. The consultant should identify relevant one-off and ongoing costs, including implementation work, migration, training, support, additional security measures, licences, connectivity, equipment renewal and potential decommissioning. Where an amount cannot yet be known, it should be labelled as an estimate with its assumptions and level of confidence.
A useful business case also explains what happens if the change is deferred or not made. That comparison should be evidence-based rather than alarmist. It might consider continued maintenance effort, contractual exposure, audit requirements, operational limitations or the likelihood and consequence of known weaknesses. Benefits should likewise be stated in measurable or observable terms where possible, with the method for checking them after implementation.
Dependencies and boundaries should be documented. Major IT changes rarely affect one system in isolation. The consultant should identify dependencies involving identity services, networks, data flows, integrations, suppliers, premises, devices, contracts and internal responsibilities. The report should make clear what is included in the recommendation, what is excluded and what must be completed first.
This is particularly important where the change crosses organisational or supplier boundaries. Responsibility for data, configuration, approvals, support and ongoing monitoring should be assigned rather than left implicit. A technically sound recommendation can still be unsuitable if the organisation cannot operate or govern it after the consultant’s involvement ends.
Security and compliance evidence should be specific to the proposed change. The consultant should explain how the change affects identity, privilege, authentication, logging, data protection, vulnerability management, backup arrangements and recovery processes. Relevant legal, contractual or sector requirements should be identified without claiming compliance merely because a product or design is commonly used.
Where the recommendation changes how information is stored, accessed or transferred, the evidence should describe the data involved and the controls required at each stage. If a formal assessment, approval or policy exception is needed, that requirement should be stated before a commitment is made.
A decision pack should include conditions and review points. The consultant should specify the assumptions that must remain true for the recommendation to stand, together with trigger points that would require the decision to be revisited. Examples include a change in business structure, an integration that proves unsuitable, a supplier limitation, a revised legal requirement or evidence that an expected control cannot be implemented.
The pack should also define acceptance criteria in practical terms. These criteria should describe how the business will determine whether the agreed design is fit for purpose, whether required controls are operating and whether affected processes can be supported. They turn a recommendation into a decision that can later be reviewed rather than a one-off opinion.
Before approving the change, decision-makers should be able to ask the consultant to show the source of each material conclusion, explain unresolved uncertainty, compare the selected option with a credible alternative and identify who owns the remaining decisions. If the evidence cannot support those questions, the appropriate next step may be further investigation rather than immediate approval. S2 Technology Group applies this evidence-led approach within its IT consulting work for businesses around Stourbridge, Kinver, Wordsley, Kingswinford, Kidderminster, Halesowen, Dudley and neighbouring areas.
The amount of evidence required should reflect the change’s risk, reversibility and potential business impact. A low-risk change that can be easily undone may need a documented rationale and basic compatibility checks. A change affecting critical operations, sensitive data or many users requires stronger evidence before approval.
For higher-risk changes, the consultant should normally recommend proportionate safeguards such as a limited pilot, staged implementation, technical peer review or a rehearsal using representative systems and data. The evidence should show what was tested, which conditions were not reproduced, what problems were found and whether those problems were resolved.
This approach prevents the decision from relying solely on a proposal or demonstration. It also gives decision-makers a clearer basis for judging whether the proposed change is sufficiently understood to proceed, or whether its uncertainty remains too high for approval.