Transformations rarely fail for one technical reason

Acceptance testing passed; the work did not change as expected

This retrospective analysis of 2018 was written and published in 2026. It examines the interconnected causes of an IT transformation without claiming to measure their statistical frequency. The narrative is a teaching scenario: the people, volumes and decisions are invented to make the mechanisms visible. It describes neither a CYTIZEN failure or success nor an identifiable client.

On launch Monday, Nora, the programme manager, hears that the tool is working. Interfaces are available, screens respond and tests have been signed off. By eleven, purchase requests are piling up. Some managers cannot see approvals; others approve requests only to discover that the order has not been transmitted. Assistants maintain a parallel spreadsheet to keep work moving. The integrator says the configuration matches the rules it received.

All these statements can be true simultaneously. The system applies a rule the business has not sufficiently clarified, using incomplete data, with permissions distributed late and support prepared only for technical incidents. Looking for a single culprit avoids examining the entire journey. Claiming that “everything is organisational” would be equally reductive: an interface that genuinely fails requires a technical correction.

Reconstruct a case before rebuilding the schedule

Nora selects a pending request and retains its identifier from entry through to the order. The buyer explains the expected result; support retrieves permissions; the integrator examines events; finance clarifies the delegation rule. The team writes the chronology without immediately changing the data. An intervention intended to help the user might otherwise erase evidence of the cause.

The first case reveals a missing delegation for a recently appointed manager. The second exposes an incorrect cost centre. The third reaches the interface but fails on supplier data. There are therefore several classes of defect requiring different treatments. Reinstallation or general training will not solve all three situations.

The team then examines a small sample covering locations, amounts, standard cases and exceptions. It does not select only requests that are easiest to explain. The record states its limitations: ten cases can identify mechanisms but cannot precisely estimate the failure rate across the company. Overall volumes are investigated separately using available events.

Six links to test before going live

The first link connects the objective to the business rule. Reducing order lead time does not authorise removing a control whose usefulness nobody has examined. The process owner defines exceptions and the authority empowered to accept them. The second connects that rule to data: cost centres, suppliers, delegations and effective dates need owners for creation and correction.

The third link connects data and configuration. The team tests incorrect, missing and changed values, rather than only lists prepared for demonstrations. The fourth connects configuration and permissions. Every participant executes the journey with their future access rights; administrator accounts must not conceal problems that will appear in actual operation.

The fifth connects the journey to support: detection, classification, recovery and communication. The final link connects the service to external commitments and business calendars. A supplier available during head-office hours does not necessarily cover a factory’s first night shift. Each link has evidence and an accountable owner; none can be replaced by an overall progress percentage.

Separate causes from decisions

A workaround needs a cost and an end date

The parallel spreadsheet keeps the day running but introduces risks of duplicate orders and lost control. Nora does not prohibit it without an alternative. She has the authorised cases, approval owner, transaction list and reconciliation before re-entry specified. The business and service accept the additional workload for a limited period.

This exception is reviewed daily while requests accumulate. A case that cannot be reconciled is not automatically reintroduced. The technical team corrects causes; the business owner confirms the rule; support progressively resumes processing. The programme does not close the defect because a developer has delivered a fix. It closes it after executing the case, checking the result and verifying recovery.

The sponsor chooses between retaining a limited scope, suspending the next rollout and mobilising additional capacity. The choice is connected to duplicate risk, control workload and genuinely available capacity. The programme does not promise a date before suitably skilled people have estimated the work.

Acceptance testing should resemble the first Monday

Component acceptance testing remains necessary: an interface-contract failure cannot be discovered simply by gathering users. It is complemented by journey acceptance testing. Tests combine a user profile, representative data, an event and a verifiable result. Entry conditions specify which reference data and permissions must be available.

Nora organises a rehearsal involving an urgent request, a replacement approver and a recently created supplier. Representatives from three locations participate during their usual hours. Support classifies incidents using the tools and permissions it will actually have. The integrator observes without resolving every error for the operators. The test becomes an exercise in learning how to operate the service, rather than simply a software demonstration.

The result produces two separate lists: defects preventing service and improvements that can be deferred. The business explains why a defect blocks its activity; technical staff estimate options; the sponsor makes decisions within their mandate. The list is not reordered solely according to ease of correction.

Adoption is a result in context, not a communication sent

One hundred trained people do not mean one hundred people able to work. Measure users who have executed the relevant journey, those requesting assistance and those retaining a parallel procedure. Feedback distinguishes lack of knowledge, an incomprehensible rule, missing access and usability problems. Each cause requires a different response.

In the scenario, fifty requests are observed over two days. Twelve require manual intervention, including eight involving delegations. The manual recovery rate is therefore 24% in this sample. This figure is neither a commercial result nor a prediction; it helps select the first correction. If the team addresses delegations, it reruns the cases and measures again using the same scope.

Processing time distinguishes waiting from actual work. An operation completed in two minutes after three days of waiting has not become a fast service. Any claimed gain must also include control, support and recovery. Comparison with the previous operation retains difficult cases; removing them would make the transformation look artificially favourable.

The sponsor’s role when explanations diverge

Finance says its rules were known; the business says the old process allowed exceptions; the integrator says it never received those variants. Nora does not ask the sponsor to adjudicate memories. She presents the dated case, rule versions and events. The sponsor decides who owns the target rule and how exceptions will be handled from now on.

When the contract does not cover a correction, procurement and legal examine the commitment. The programme distinguishes changed requirements, delivery defects and incorrect client data. Mixing these categories leads to endless debates about financial responsibility. Documenting the cause supports negotiation of an appropriate response without pretending that technical evidence alone resolves a contractual dispute.

The decision to resume the next wave includes an expected result, a validation condition and a service owner. In our example, resumption requires a rehearsal without duplicate orders and handling of known errors by regular support. These criteria are specific to the scenario, rather than a standard applicable to every transformation.

Sector consequences change the evidence required

In pharmaceutical manufacturing, a quality workflow can affect traceability, approved procedures and regulated activities. A functional correction may require change control and documented testing depending on the context. The programme cannot treat the system as a simple administrative tool whose results users accept verbally.

In financial activities, the ability to reconcile transactions and retain appropriate permissions may be decisive. Recovery includes checking the result, rather than merely reopening a screen. In distribution operations with pronounced peaks, load and exceptions are tested together; a journey that is easy under no load may collapse as queues grow.

In all these cases, business, data, technical and operational expertise must be present before the go-live decision. The programme director orchestrates evidence and decisions. Their role is not to claim expertise in every domain, but to make it impossible for a global sign-off to erase an essential responsibility.

Sources and method

Official references offer guidance on direction and governance. The analysis of failure mechanisms, narrative and conditions for resumption are an original construction intended for programme management. The current version of GovS 002, updated in 2025, is distinguished from its existence in 2018. No statistical failure frequency, universal causality or guarantee of success is asserted.

• GOV.UK — GovS 002, Project Delivery, page published in 2018; consulted version updated in 2025
• GOV.UK — Governance principles for agile service delivery

Links verified on 4 October 2026. The scenarios and thresholds proposed in this dossier are educational; they describe neither a client engagement nor a result achieved by CYTIZEN.