Technology investment decisions should start with the change the business needs

“Replace the platform” is a project description. It is not yet a reason to invest. A technology sponsor needs to explain what the business will do better, why the current arrangement cannot reasonably deliver that change and which evidence supports the preferred option.

That work should begin before a supplier demonstration. Otherwise the evaluation tends to become a comparison of features the organisation has not established it needs, with a benefit case assembled afterwards.

One attractive number can conceal several different benefits

Consider a hypothetical workflow handling 1,000 cases each month. A proposed change reduces handling time from 15 minutes to 10 minutes per case, releasing about 83 hours of capacity. That is a useful operational result if the new time is demonstrated and quality is maintained.

It is not automatically 83 hours of cash saving. The organisation may redeploy the time, reduce a backlog or absorb growth without adding staff. Those outcomes have different implications for the business case. Name the benefit the operating team can realistically deliver.

Also include work moved elsewhere. If another team spends longer correcting outputs or maintaining integrations, the local gain may overstate the service-level improvement. Use the same boundary for the baseline and proposed approach.

Evidence should determine the size of the commitment

Where a key assumption is weak, fund a bounded test capable of resolving it. Where the evidence is already strong, do not add a ceremonial pilot that cannot change the decision. The next commitment should match the uncertainty that remains.

Write a decision statement

Describe the business outcome, the people affected and the constraint that makes action necessary. For customer onboarding, for example, specify which manual steps cause delay and which checks must remain. That gives the sponsor a result to assess across both replacement and improvement options.

Record the baseline and its limits. If the team does not know how long the current process takes or where rework occurs, say so and collect a useful sample. An honest uncertainty is a better input than a precise benefit estimate built on an unmeasured starting point.

Separate gates from preferences

Some requirements determine whether an option is acceptable at all. Others help distinguish acceptable options. Keep those two roles separate. A weighted score should not allow attractive features to compensate for an unresolved requirement the organisation considers mandatory.

Agree the gates before evaluating suppliers. For each one, specify the evidence required and the person authorised to judge it. Where a requirement can be met through a workaround, include that workaround’s cost, owner and operational risk in the comparison.

Compare the option you already have

Include a credible do-minimum option: repair a workflow, improve configuration or extend the current service where feasible. This is not an argument against investment. It is a way to identify which benefits genuinely require a replacement and which depend on work the organisation must do anyway.

A hypothetical evaluation might find that two suppliers can automate a process, but both require the same unresolved data cleanup. Attribute the benefit and cost carefully. The new platform should not receive all the credit for an improvement that primarily comes from fixing the data, and the cleanup should not disappear from the delivery plan.

Model the operating trade-offs

The FinOps principles emphasise business value and conscious trade-offs among cost, quality and speed. That is a useful discipline for this decision: an option’s lowest headline price does not establish its value in the intended workflow.

Build a comparable view of implementation, integrations, training, support and ongoing administration. Add transition and exit assumptions where they could change the decision. Keep uncertain inputs visible and test whether a reasonable change would alter the preferred option.

If the choice changes after a modest shift in one assumption, investigate that assumption before presenting the ranking as decisive. A small difference between totals may be less important than the quality of the evidence behind them.

Set a review point before approving the spend

Name the benefit owner and agree how the outcome will be checked after adoption. Distinguish deployment, usage and realised benefit. A system can be live without being adopted, and widely used without delivering the improvement originally proposed.

Define what the organisation will do if the evidence disappoints: improve the workflow, narrow the deployment, renegotiate the commitment or stop further expansion. A review has little value if every possible result leads automatically to buying more of the same thing.

Keep a short decision record

Record the chosen option, rejected alternatives, assumptions, unresolved risks, decision owner and review trigger. Future teams need to understand why the choice made sense at the time. That record also makes it easier to change direction when the underlying conditions change.

Use a scorecard with explicit gates when comparing acceptable options, and a benefit review once the technology is in use. Approval is the beginning of the value argument, not the point at which the promised improvement becomes real.