Analysis: transformation fails for organisational reasons, not technical ones

Failure is organisational — so diagnose the organisation

If the majority of failures are organisational, the standard vendor sequence — pick a platform, build, then worry about adoption — is backwards. It resolves the easy variable first and leaves the decisive one to chance.

We invert it. The diagnostic phase exists to test the organisational conditions, and only the processes that pass move into build.

The four conditions we check

1. Ownership: one named person is accountable for the system after launch, with the authority to change it.
2. Stability: the process has not materially changed in the last two quarters and no change is planned.
3. Data: the inputs are consistent enough that a rule can act on them without a human interpreting first.
4. Scope: the first build can be proved or disproved inside a quarter.

A process failing any one of these is not disqualified — it is sequenced later, behind whatever fixes the missing condition.

What failure looks like from the inside

Programmes rarely announce their failure. They degrade: an exception appears that nobody owns, someone works around it manually, the workaround becomes the process, and six months later the system is a licence line item nobody can justify. Every step of that is organisational.

This is the reason we run what we build. A system without an operator is a system with a shelf life.

The reframe we recommend

Stop asking whether the technology can do it — with current tooling the answer is almost always yes. Ask instead who will own the output, what happens on the day it breaks, and how you will know it is still working in six months. Those three answers predict the outcome better than any platform selection.