Contents
A business case for technical improvement should explain which problem consumes effort or creates risk, what would change and how the result will be assessed. A large headline estimate is less useful than a small set of well-supported observations. Keep measured activity separate from estimates of work that might have been avoided.
Define the problem you are costing
Choose a specific difficulty: repeated repair of an integration, an approval rule duplicated across several places, or a release process that requires extensive manual coordination. State where it occurs and who experiences its consequences. Avoid assigning a single cost to the whole codebase before understanding individual problems.
Connect the concern to current priorities. If a planned change touches the affected area, describe the additional work the team expects. If the concern is operational, identify the service or user journey at risk. Missing features and slow business decisions may also consume time, but record them separately so the proposed remedy addresses the right cause.
Collect a small set of traceable observations
Review recent changes or incidents that illustrate the problem. Record what happened, the work performed and the evidence available, such as a change history or an incident review. Keep commercially sensitive details in the organisation's appropriate internal systems. The public argument does not need to expose customer data or private incident records.
Ask the people involved to distinguish necessary work from avoidable rework. If a developer spent time understanding an unfamiliar business rule, some of that effort might still have been needed in a cleaner implementation. Do not treat all time spent in an awkward part of the system as recoverable savings.
Include operational effort where it is relevant. Users may reconcile records, repeat failed tasks or check outputs manually. Establish whether those actions are caused by the technical issue under review, a process decision or another limitation. A shared description of the cause is more useful than adding unrelated frustrations to the same total.
Keep measured costs and estimates separate
Show observed effort in one part of the assessment and estimated future effects in another. For each estimate, name its assumptions and the person best placed to review them. If you convert time into money, use a costing basis agreed with the organisation and explain whether it represents cash expenditure, internal capacity or an opportunity cost.
Avoid double counting. A delayed release, the engineering effort used to repair it and a hypothetical lost opportunity may describe overlapping consequences. State the relationship between them before adding figures together. Where the evidence does not support a monetary estimate, describe the consequence and uncertainty directly.
Use a range when the result depends on uncertain frequency or effort. Explain what evidence would narrow that range. The purpose is to support a decision, not to make a speculative amount look authoritative by displaying more decimal places.
Cost the intervention and its disruption
Describe the proposed change and the behaviour that must remain intact. Include investigation, implementation, testing, release and documentation. If data or integrations are affected, account for migration, reconciliation and coordination with other owners. Ask what could make the work larger than expected.
Compare more than one response where appropriate. A bounded repair, improved operational checks, incremental restructuring or replacement may have different effects and responsibilities. Include the option of deferring work with an explicit review trigger, provided the relevant owners accept the consequences.
Distinguish capacity released from cash saved. Making a team more able to deliver the roadmap can be valuable without reducing its budget. Explain the intended benefit in the terms the organisation will actually use to judge the investment.
Agree how to judge the result
Before starting, choose a practical review point and the evidence to collect. For a release-process improvement, that might be the next few relevant releases and the manual steps they require. For a difficult integration, it might be the next change to that interface and the problems encountered. Use comparable work where possible and record differences in scope.
Review the outcome with both technical and operational owners. Identify what improved, what remained unchanged and what the team learned. Do not infer a permanent saving from one unusually easy change. Carry the evidence into the next prioritisation decision and update the remaining assumptions.
Cost one recurring problem without double-counting
For a fictional planning exercise, assume staff spend 6 hours a week reconciling records at an internal loaded cost of £30 an hour. Over 46 working weeks that is £8,280. Separately assume developers spend 2 person-days a month reworking the same duplicated rule, at an invented £600 per day: £14,400 a year. If the effort records cover distinct work, the annual observed burden is £22,680. These inputs are illustrative, not Veda rates or a market estimate.
Suppose an assessment proposes a £12,000 correction and £2,000 of transition work. If it removed the entire measured burden immediately, the simple payback would be £14,000 divided by £22,680, about 0.62 years. That optimistic calculation is only a bound. At 50% reduction the annual benefit becomes £11,340 and payback about 1.23 years. Check adoption, residual work and additional maintenance before using either scenario in a business case.
Do not add hypothetical lost sales, incident exposure and staff time as though all were certain cash savings. Keep measured effort, conditional outcomes and unquantified risks in separate lines. Record where each input came from and when it will be rechecked. Commission a bounded correction when the evidence supports it, then compare actual burden afterwards instead of claiming savings from a completed code change alone.
How this relates to Veda Software’s work
Encounter is relevant to replacing repeated preparation with managed trip information. Its qualitative narrative is not the source of the invented hours, rates or savings in this exercise.