Diagnose capability and technical debt before buying a solution

A manager sees a long queue and proposes a new platform. The technology team calls the legacy system the cause. Before approving either diagnosis, connect the user outcome to the work, the required capability and the actual constraint. A **capability** is something the organization can do repeatedly, such as verifying eligibility or passing a correct decision between teams; it is not the name of an application or department. The capability may exist but lack capacity, be split across decision owners, or depend on a fragile integration. **Technical debt** here means a technical choice or accumulation that raises later change or operating cost, not simply any old system.

Start with the outcome and draw a short chain: outcome → work activity → capability → people, data, authority and technology needed. In a fictional grant service, the desired outcome is a correct decision communicated within ten working days. That requires valid intake, eligibility check, financial appraisal, decision and communication. A faster eligibility engine cannot fix a delay after the decision has been made. If nobody can correct an applicant record across two systems, both data accountability and integration may be involved. The chain stops a solution name from substituting for a diagnosis.

Collect three kinds of evidence. First, user evidence: demand, the distribution of completion times rather than the mean alone, recontacts, and decisions later corrected. Second, work evidence: active time, waiting, re-entry, outages and late delegations. Third, technology evidence: exchange errors, interface limitations, manual workarounds and change failures when a rule is updated. Label confidence in each inference: observed in complete logs, found in a specialist-reviewed sample, or reported anecdotally and needing a test. Missing records are not zero events.

Annual re-entry volume is 20,000 × 60% = 12,000 applications. Direct effort is 12,000 × 12 / 60 = 2,400 hours, with an arithmetic labor value of 72,000 units a year if that capacity can be released or redeployed. Do not book all 72,000 as immediate cash savings: salaries may stay in place, while time is used to clear a backlog. The sample suggests that roughly 75% of observed re-entry causes involve the absent interface, but 75% × 2,400 hours is not a verified saving. The sample is limited, cases may differ in duration, and integration does not remove human review. Those qualifications materially affect the decision.

Set out competing hypotheses. A: the missing capability is a controlled transfer of valid fields between systems; test it with a limited connector for ten fields, validation and rollback. B: poor source-data quality drives the burden; test a change to the intake form and the rate of missing fields before transfer. C: decision rights cause delay; examine exceptions to see whether they wait for authority longer than they wait for entry. The sample favors A but does not eliminate B or C. The first investment is therefore a bounded integration trial with repairs to the most frequently missing fields. Human exceptions remain explicit rather than disappearing under a promise of complete automation.

For an initial financial comparison, suppose a testable integration costs 90,000 up front and 20,000 a year to maintain, and ultimately frees all 2,400 hours. Arithmetic annual value net of maintenance is 72,000 − 20,000 = 52,000, giving a simple initial payback of 90,000 / 52,000 ≈ 1.73 years. This is an **optimistic bound**: it assumes all manual effort disappears and ignores training and quality risk. If the connector releases only half the hours, labor value is 36,000, net value is 16,000 a year and payback lengthens to 5.625 years. Sensitivity changes the investment judgment; presenting only 1.73 would be misleading. Moreover, the value of staff time is not cash flow unless the organization specifies how it will use released capacity or remove a real cost.

Recommend a short trial rather than an enterprise platform contract. Across 200 varied applications, measure the share of fields transferred accurately, actual minutes saved, decision errors, end-to-end application time and fallbacks to manual entry. Keep separate counts for missing fields, transfer faults and judgment exceptions. Do not expand if staff minutes improve while corrected decisions rise, or if data cannot be exported on exit. If the trial meets gates defined in advance, update the business case using observed hours rather than the supplier's promise. “The system is old” has become a testable hypothesis about a particular capability.

An absent interface is not, by itself, proof of technical debt. The separation might have been deliberate to protect sensitive data, or earlier volume might not have justified integration. “Debt” is a more useful diagnosis when a past deferral, accumulated rework cost and difficulty changing fields as policy evolves can be shown. Even when debt is real, repaying all of it immediately is not automatically rational: compare the cost of leaving it with alternatives and the risks of change. A first repair might be a shared field definition and quality check rather than a full platform migration.