Start with an outcome and understand how it is produced
Business-led transformation does not imply that business teams first joined change programmes in 2023. The title describes a starting choice: define the outcome and understand the work producing it before selecting a platform. IT participates from the beginning because data, interfaces and technical constraints are part of the actual flow. The first object of discussion is a completed request, a delivered decision or a usable service rather than a feature catalogue.
This retrospective on 2023 was written in 2026. All situations, volumes and timings are fictional teaching examples, not CYTIZEN engagements. The business owns operating consequences and quality criteria; IT helps establish feasibility and sustainability. Both must be able to correct an assumption before it becomes a solution commitment.
Follow a request from arrival to decision
Imagine a fictional organisation handling simple compensation requests. Managers want a new portal because files take too long. A request enters the current portal, is checked, waits for a document, then goes to an expert interpreting an exception. The conclusion returns to a caseworker for notification. The intake screen explains only part of the delay. Ask where the file stops advancing and what decision is missing.
Observe completed, incomplete and unusual cases. Keep timestamps, return reasons, status changes and channels actually used. Interviews explain why staff re-enter information; observation checks what they do. Procedure documents show intended flow, while email and parallel spreadsheets may reveal actual flow. Do not label these workarounds as individual failings before understanding the constraint they address.
The actual flow changes priorities
| Fictional step | Work time | Wait | Decision or cause | Proposed test |
|---|---|---|---|---|
| Receipt and checks | 12 minutes | 1 day | Document list varies by caseworker | List adapted to request type |
| Request for evidence | 8 minutes | 6 days | Unclear wording and difficult return channel | Explicit message and accepted-document example |
| Expert exception | 20 minutes | 4 days | Undefined delegation boundary | Decision rule for recurring cases |
| Notification | 5 minutes | 1 day | Routine approval even for simple cases | Exception-based approval with targeted checks |
These teaching figures distinguish effort from waiting. Do not add them without checking overlap; measure end-to-end time directly. The table suggests a hypothesis: clearer evidence requests and delegation may help more than a general portal replacement. Test this on comparable cases rather than treating a limited observation as an explanation of the whole organisation.
Frame the problem without choosing the solution
A useful problem statement names the beneficiary, observable difficulty, consequence and measured baseline. “We need a new tool” does not establish what should improve. “Applicants frequently receive unclear evidence requests, extending processing and creating calls” invites several responses: clearer wording, a document rule, a better channel or a technical change. A platform remains possible, but it must address an identified cause and verifiable requirement.
Distinguish applicant and caseworker needs. Applicants need to know what to provide and when a conclusion will arrive. Caseworkers need usable files and clear decision authority. A visually pleasing portal creating manual re-entry does not fix the flow. Faster processing that weakens explanation may degrade the service. Preserve multiple quality criteria rather than burying their trade-offs inside a composite score.
Hidden decisions often define the real work
At each wait, ask what decision enables progress, who can make it and what information it needs. Some decisions apply a clear document rule. Others need expert interpretation. Others accept risk or fund capacity. Automation does not erase these distinctions. It can implement an agreed rule, but cannot create legitimate authority to resolve disagreement over the rule.
The business documents recurring exceptions and boundaries. An authorised owner selects those caseworkers may decide and those requiring expertise. IT checks data availability and traceability; control specialists examine misclassification risks. This establishes a usable rule before development. If ambiguity remains, continue analysis or a manual trial instead of immediately turning uncertainty into code.
Test where the change should have an effect
In this fictional case, one team tests standard evidence-request wording for one category and a delegation rule for two frequent exceptions. Check applicant understanding, usability of returned documents and decisions against the rule. The trial examines outcomes and downstream work, rather than merely demonstrating a screen to internal stakeholders.
The journey owner takes responsibility for the end-to-end result. Team leads organise capacity. Caseworkers identify uncovered cases. Experts review a sample of delegated decisions. IT follows access constraints and development needs. Analysts separate case complexity and volume changes from trial effects. The sponsor arbitrates when a local improvement creates work elsewhere. These roles prevent success being defined only by delivery or project-team enthusiasm.
Use stable denominators
First-time completeness equals eligible requests containing all necessary evidence on arrival divided by all eligible arrivals. Return rate equals files requiring additional evidence divided by examined files. Median and ninetieth-percentile lead times end at final notification, not an intermediate status change. Keep abandoned files as a separate category: silently removing them may make the service appear faster because difficult cases no longer finish.
Estimated capacity gained equals avoided tasks multiplied by observed average duration, minus additional control and support work. In a fictional example, forty avoided evidence requests at eight minutes save 320 gross minutes. With 120 minutes of new checking, net capacity is 200 minutes. This is neither automatic headcount reduction nor cash savings; connect it to capacity actually available for other work or quality improvement.
Continue, correct or reverse
Set criteria before testing. Continue if evidence becomes more usable, comparable-case delays fall and checks reveal no increase in incorrect decisions. Correct misunderstood wording or uncovered exceptions. Stop delegation if decisions exceed authority; suspend a misleading message. A positive result for simple cases does not justify immediate extension to complex requests or people with different access needs.
Describe reversal concretely: withdraw the rule, restore expert examination and identify cases needing review. A claim of reversibility is insufficient once a conclusion has been notified. Qualified owners examine commitments and correction routes. This may require observing proposed decisions before applying them or limiting the initial trial to a lower-risk document change. Learning should not create consequences the organisation cannot repair.
Select the solution after the team understands necessary functions, supported flow and evidence of usefulness. Requirements can then describe data, exceptions, access, explanation needs and operating constraints. Compare non-development options and limited changes alongside larger acquisitions. A larger investment is justified by observed causes and needed capabilities rather than an idealised demonstration without incomplete cases.
Different sectors reveal different flows
Manufacturing order-to-delivery observation reveals replanning, approval waits and capacity constraints; speeding one station does not guarantee overall throughput. Retail returns connect stores, transport, refunds and stock. Healthcare depends on qualified availability, safety and confidentiality. Public services include applicable rules, accessibility and appeal rights as part of the service itself.
Starting with the business makes changed work and enabling decisions visible. A flow map connects a difficulty, probable cause, responsible person and expected proof. Revise it when evidence contradicts the hypothesis. This helps leaders fund necessary change and helps IT build for observable work rather than automate unexplained waiting.
Sources and chronology
Official references checked in October 2026. Examples, calculations and test designs are original teaching proposals.
- GOV.UK, How the discovery phase works: a Service Manual reference consulted in 2026 on understanding problems, needs and constraints before building. Its current version is not treated wholesale as a fixed 2023 prescription.
- GOV.UK, Measuring the success of your service, first published in 2018: available before 2023, addressing defined and measured service outcomes.