What Evidence to Ask For Before Approving a Software Investment

A software proposal can promise faster work, fewer errors, and future growth. Before approving the expense, ask what problem has been observed, how the proposed approach addresses it, and what evidence would show improvement. You do not need certainty about every outcome. You need clear assumptions and a way to learn without committing the whole budget to an untested story.

Establish the current cost of the problem

Look at a sample of real work. How often does the issue occur, who handles it, and what happens to customers or staff? Record the time spent on repeated entry or correction if it can be measured reasonably. Note consequences that are difficult to price, such as delayed replies or a lack of confidence in records. Separate observed facts from estimates. A dramatic claim about savings is weak if nobody has examined the existing task.

The GOV.UK guidance on measuring service benefits recommends relating improvements to the size of the problem and agreeing how benefits will be tracked. The methods are designed for public services, but the principle supports a modest business case: know the starting point and the decision that better software should enable.

Compare plausible options

Ask whether a clearer process, an existing product, a focused connection, or custom software could solve the problem. Include setup, training, ongoing fees, support, and the cost of moving information. A custom build may be justified when the workflow is distinctive; a simple existing tool may be better when the need is common. The GOV.UK guide to choosing technology stresses adaptability and total ownership cost. Use the same questions at a scale appropriate to your business.

Request a concrete example of the proposed solution handling a normal case and a difficult one. Ask what is already built, what must be tailored, and what depends on another provider. A demonstration is evidence of a possible workflow, not proof that staff will adopt it or that all records can be moved. Identify which assumptions need a small pilot or a sample data transfer before larger spending.

Define how the investment will be judged

Choose a few measures tied to the problem: a completed task, fewer corrections, shorter handoffs, or more dependable customer updates. Decide when they will be reviewed and who supplies the records. Include staff and customer feedback so the team understands why a number changed. Do not demand a guaranteed return from uncertain early information; ask for a staged plan that limits exposure while learning.

Check ongoing obligations. Who maintains the system, handles incidents, tests backups, and responds when business rules change? A low initial quote can omit these costs. Ask for the boundaries of the proposal and how new requests will be estimated. Record the risks and the owner of each decision before approving work.

Ask who will use the product and whether those people have tried the proposed workflow. A manager's view of a process may differ from the work performed at the counter or in the field. A brief task observation or prototype test can reveal missing information before it becomes an expensive change request. Include an exception rather than testing only the easiest case.

Consider the consequence of doing nothing for a while. Some problems are urgent because customers or important records are at risk. Others may be watched while the business gathers better evidence. A staged decision can begin with a process improvement or a small pilot. This is a legitimate option when the cost of a full system is high relative to the uncertainty.

Holism can help an owner assess the options with a developer who uses AI and a reusable Software Product Line to deliver focused custom work. The owner sets the business outcome and spending limit; the developer explains the technical approach and uncertainty. Evidence worth approving includes a real problem, a plausible solution, honest costs, and a practical test of results—not an unsupported guarantee.