JNAGA

Decisions in practice

Before buying the fix,
find the failure.

Three familiar requests—a new customer system, replacement software and a successful launch—can conceal different problems. These illustrated examples show what to examine before committing time and money.

The situations are illustrative. Their point is the test, not a claim that one answer fits every organisation.

01 / The enquiry

The enquiry arrived.
Who owned the reply?

Consider a firm receiving enquiries through its website, email and introductions. Follow-up is uneven, so the team asks for a customer-management system.

Take five recent enquiries and follow each from arrival to first useful reply. If every message reached the right inbox but nobody was assigned to answer, the failure is ownership. A new system may record the delay without removing it.

The decision

Define who takes each enquiry, what must be recorded and when it is escalated. Test that hand-off with existing tools before deciding whether a new system has work to do.

A passage interrupted between request and responseThree connected spaces represent an incoming request, an unclear hand-off and the eventual response. The interruption is highlighted rather than a new software product.
A passage interrupted between request and response

02 / The ageing system

Repair, connect
or replace?

Suppose an operational system still handles its core task but staff retype information into two newer tools. Replacing it during a busy period would disrupt customers and require a difficult migration. Compare the cost of that disruption with the cost of a maintained connection—not just the initial quotes.

Three different ways through an existing structureA small repair, a connecting passage and a full rebuild are drawn at different scales to show that the options carry different disruption and uncertainty.
Three different ways through an existing structure

Repair

Fix a specific failure in the current system. Choose this when its main job remains sound and the limitation is contained.

Connect

Keep the sound core and move agreed facts to other tools. Name the authoritative record and who resolves a failed transfer.

Replace

Move when the core workflow no longer fits. Budget for data migration, parallel operation, training and support—not only software.

Test the most difficult recurring case against each route. If a connection solves the hand-off but not the wider operating problem, that evidence strengthens the case for replacement.

A structure observed after it opensAn architectural elevation shows a clear route, an exception and a later adjustment. Launch is a point of observation, not the end of the work.
A structure observed after it opens

03 / After launch

Why is the spreadsheet
still there?

A new service journey goes live. A month later, staff still maintain a spreadsheet alongside it. Telling them to stop may remove the only place they can record an unusual request.

Examine which cases enter the spreadsheet, who updates it and what decision it supports. If it records exceptions the new service cannot assign, add an owned exception route. If it duplicates a reliable record, remove it and check that no essential information disappears.

The decision

Judge the launch by the work it changed, including work that moved elsewhere. Fund a repair only where the evidence shows one is needed.

Your decision

Bring the case
that does not fit.

If you are considering a system, service or operating change, tell us where a real case stalls and what decision is pending. We can discuss what to examine first and agree a defined scope if the work is a fit.

How we work Begin a conversation