A stalled handover is an outcome. Capacity, skills, budget, and interest are four candidate explanations for it, and they produce the same visible symptom: the recipient does not assume the work.
Problems in the deliverable, in access, in authority, in timing, or in the value of the service produce that symptom too. So the diagnosis has to be made rather than assumed, and the reason it matters is that the four causes take four different remedies.
Four gaps, four kinds of evidence
Capacity. Look at actual allocations, existing commitments, coverage, and observed support workload. The competing explanation is that skills or access prevent the use of nominally available time. The remedy to test is reprioritising or resourcing defined tasks, then checking whether coverage actually appeared.
Skills. Look at recipient task attempts, the errors, the explanations offered, and the assistance required. The competing explanation is a missing permission, a defective instruction, or a broken system. The remedy is correcting the specific gap and observing a repeat attempt.
Budget. Look at the approved scope and period, the payer, the renewal, and the spending authority. The competing explanation is that funds exist centrally while responsibility is unclear. The remedy is resolving the actual funding or ownership boundary and verifying it.
Commitment. Look at stated priorities, the reasons given for declining, the incentives, and the decisions of the people who actually have to act. The competing explanations are no protected time, incompatible duties, poor usability, or a genuinely disputed value. The remedy is reassessing scope and value with the affected owners.
The diagnosis that goes wrong first
A manager says the team is keen to take ownership. Nobody attends the deployment exercise. The immediate reading is lack of interest.
Allocation records then show every proposed operator assigned to a concurrent incident, and the exercise’s required deployment role missing entirely. Those observations point at capacity and access. They do not establish that motivation was absent, and they do not establish that training would help.
Two lessons sit in that example. An enthusiastic sponsor does not represent every required contributor, and one person’s account does not establish a shared organisational state. Commitment to implement a particular change is distinct from shared belief in collective capability, and people can misjudge their own readiness in either direction.
Keep no interest as a question about this change, its value, and actual priorities — not as a judgement about people. A recipient declining a system with no acceptable operating model has made a correct decision.
Capacity is arithmetic, and the arithmetic comes up short
Capacity is the people, time, tools, and coverage actually available for the transferred scope. A named owner with no allocation is an assumption.
The estimate covers recurring administration, user support, incident investigation, updates, evaluations, dependency maintenance, and records work — using observed workload where it exists and labelling forecasts as forecasts. It adds transition learning, known renewals, and infrequent but consequential work. And it separates time actively spent from being reachable during a support window.
Four people each allocated 30 hours to a delivery pool have 120 hours. Existing commitments consuming 110 leave 10. A forecast of 16 hours of recurring work for the transferred system produces a six-hour gap before any exceptional incident. The arithmetic does not establish that the remaining 10 hours carry the right skills at the right times, nor that the forecast is accurate — and both of those make it worse rather than better.
Two counting errors recur: the same person’s spare time allocated across several services, and a nominal backup assumed available during a shared incident. Sufficient trained personnel means enough for normal operations, incidents, on-call rotation, and time off, reassessed as the workload changes.
Readiness is bilateral
Readiness asks two questions, and answering only one is the standard mistake.
Can the outgoing party supply the agreed system and evidence? Versions, intended behaviour, known limits, dependencies, artifacts, permitted data, recovery options, unresolved defects.
Can the recipient assume the responsibilities under actual conditions? Task competence, allocated time, access, funding, authority, support coverage, dependency contacts.
Neither side’s assurance substitutes for the other side’s demonstration. The interfaces are verified by recipient-led exercises: the recipient builds or deploys the identified version, locates the relevant evidence, investigates an induced fault, and follows a recovery procedure — with setup, result, assistance, and limits recorded. A builder-run demonstration shows system capability and says almost nothing about recipient capability.
Each requirement is then classified demonstrated, conditional, blocked, or unassessed, with an owner and a deadline for every condition and a named operator meanwhile. An explicitly required but unmet condition does not get averaged away into an overall score.
The characteristic finding: a deliverable with a reproducible package and a tested recovery procedure, and a recipient who can read the procedure but cannot access the backup account. The document establishes that a procedure exists. Recovery responsibility stays untransferred.
The rule
What stays fixed is that a remedy is tested rather than assumed to have worked. What changes is which gap binds, and several can bind at once — in which case later success after a combined intervention does not identify which component caused it.
Not to be confused with
A maturity score. A general capability profile informs procurement planning. It cannot establish readiness for a particular technology or workload, and unknowns and critical gaps stay visible rather than being averaged into one number.
A validated instrument. The four-way split is a diagnostic aid. No failed-transfer dataset supports it, and it earns its place by forcing an observation for each proposed cause.