[August 2026 edition]
The Art of Not Building, Part 2 — Seeing the Whole Process and Deciding What to Systematise
Published: Aug 11, 2026
Reading time: ~13 min
Part 1 covered the three distortions that arrive with a request, the five ways digitalisation leaves work unchanged, and the ECRS procedure for trimming work. Applying ECRS requires an accurate picture of the work in the first place.
Part 2 sorts out what obscures that picture, then carries the results of the cleanup into a decision about what to systematise.
1. What a task list never shows
Ask individual staff what they do and you get a list of tasks per person. Systematise that list as it stands and you freeze the departmental boundaries and existing division of labour along with it. Take expense claims: asking the people involved produces a sequence of internal steps, while the real start and end of the process sit elsewhere.
| View | Range |
|---|---|
| Task list | Enter into the claim screen → manager approves → finance checks → payment file is produced |
| The whole process | An employee pays a business cost → the correct amount is refunded promptly → it lands in the company’s accounts |
Reframed at the second scope, other solutions appear. Use a corporate card and pull line items from transit cards or booking systems, and the data entry itself shrinks. Move small expenses to a fixed allowance and set a threshold below which receipts are unnecessary, and the volume shrinks. Merge accounting and claiming so that only exceptions get human review. Every one of these reduces the claim procedure that was supposed to be the target of efficiency work.
2. Requests from the floor and the problems behind them
The people doing the work know its friction better than anyone, while the reason that friction exists and the role it plays across the whole process may sit outside their view. Requests arrive as solutions, so the problem behind them needs checking.
Take “please show the customer’s address on this screen too.” Several different problems could sit behind it. Opening another screen may be tedious. There may have been an incident where the wrong customer was selected. Perhaps an address has to be written onto a printed document, or identity is verified during enquiries, or the address in another system is not trusted. Before adding the field, establish which problem is being solved.
GOV.UK’s guide to user research states that delivering a service which meets user needs requires understanding who the users are, what they are trying to do, and how they do it today. What you collect from the floor is therefore more than a list of feature orders.
| Subject | Question |
|---|---|
| Time | What takes time, and where does work wait |
| Errors | Where do mistakes happen |
| Concerns | What are people afraid of, and what do they double-check |
| Exceptions | Which exceptions do they handle |
| Dependencies | Who do they ask, and which information do they distrust |
| Purpose | What outcome do they actually want |
These are not questions for interrogating a user department. They exist to surface, jointly, the assumptions an organisation holds without noticing.
3. Testing “the law requires it”
Try to eliminate a process and the responses arrive: the law requires it, the auditors need it, security demands it, internal control cannot lose it, compliance requires it. Some of those controls are genuinely necessary, so what you examine is the specific basis and what it actually requires. Whether the requirement is an outcome or today’s procedure, and whether the basis still holds, changes the options available.
| Basis | What to establish |
|---|---|
| Law | Which statute and which clause. What must be retained, for how long, whether an original is required or an electronic record suffices, whose confirmation is needed, whether every case is in scope |
| Audit | The audit objective and the risk being tested. Whether every case must be checked, what information is needed as evidence, whether it must be an approval action, whether an automatic record can substitute |
| Security | Means other than human approval: input constraints, separation of duties, usage limits, anomaly detection, tamper-evident logs, periodic review |
Separate the purpose of a control from how it is currently operated and other implementations become available. Instead of keeping something because it is necessary, define what would have to be satisfied for the necessary condition to be met.
4. What to keep from the cleanup
The point of this cleanup is not to produce an enormous requirements document. It is to leave the decisions traceable: why the current work exists, what is changing, and how much is being handed to a system.
Four things are worth keeping. The number of documents scales with the size of the operation, but they should fall into these four groups.
| # | Deliverable | Contents |
|---|---|---|
| 1 | Problem and purpose | The problem being solved, the outcome sought, users, stakeholders, constraints and their basis |
| 2 | Current state | The real flow of work and information, departments, systems, baselines, the value and necessity of each step |
| 3 | Future state and options | The future process after elimination, consolidation, reduction and standardisation; non-system measures; risks, assumptions and dependencies; success measures |
| 4 | System boundary | What humans handle, what goes to existing services, what new development covers, what is out of scope, and the go/stop decision |
The four connect in sequence. Problem and purpose leads to current state, which produces the future state, and the system boundary is settled before anything reaches system requirements.
4.1 Problem and purpose
Record whose problem is being solved and what state is being achieved. IPA’s requirements definition guide organises business requirements definition in the order of grasping the current state, extracting problems and issues, extracting goals, and then extracting means. The goal is settled first; means come afterwards.
Write the purpose as an outcome. “Produce a monthly report” becomes “executives can see last month’s anomalies by the next working day,” which removes the report itself from the set of assumptions.
Stakeholders include users, beneficiaries, operators, decision-makers, and those accountable for controls. The requester, the user, and the beneficiary are not necessarily the same party. GOV.UK also places understanding users and their needs as its first standard, asking teams to see what users are trying to achieve in the wider context rather than only at the point of contact with the service.
Concrete documents:
- A problem statement (the problem, the intended outcome, what counts as success)
- A stakeholder list (role, interest, how they are affected, approval authority)
- A constraints list (law, contract, internal rules, budget, deadline, relationships with existing systems)
4.2 Current state
Map the actual flow of work and information — what happens in practice, not what the manual says. Lean Enterprise Institute’s practical article lists process steps, cycle time, percent complete and accurate, information flow, and wait time as the elements a map needs.
Take baselines at the same time: volume, handling time, wait time, headcount, error rate, rework rate, enquiry count, and running cost. GOV.UK’s guidance on performance metrics asks teams to establish a baseline covering all channels before improving anything, and to compare post-change performance against it. The benefits guidance adds that without knowing where you started, you cannot tell at the end of a project whether anything improved.
Classify each step by value and necessity: it creates user value, it is required by law or control, a later step needs it, it is needed now but will not be later, or its basis is unknown. Record the basis and its source alongside.
| Step | Reason given | Basis | Owner of the basis |
|---|---|---|---|
| Manager approval | Fraud prevention | Internal rule, article X | Finance |
| Seven-year retention | Statutory retention | Statute, article X | Legal |
| Monthly aggregation | Executive meeting | Custom only | Corporate planning |
Laid out this way, what rests on law and what rests on habit sit in the same table and can be told apart. “We have always done it” cannot be written in the basis column.
Concrete documents:
- A current-state process map (start to finish, across departments and systems, as actually performed)
- A measurement table for volume and time (cases, handling time, wait time, rework rate, error rate)
- A list of reports and data fields (where each originates, where it is used, which fields are never referenced)
- A value-and-basis table per step (as in the example above)
4.3 Future state and options
Rather than digitising the current state, build a future process with unnecessary steps, duplication, re-entry, and approvals removed, merged, or simplified. Lean Enterprise Institute’s account of city government work works the same way, drawing out rework and duplication from the current state and examining which steps to combine and which to delete.
Put non-system measures into the same candidate set: changes to rules, organisation, contracts, training, delegated authority, and use of existing services. The GOV.UK DDaT Playbook likewise asks teams to evaluate the available options before settling on a delivery model.
Attach risks, assumptions, dependencies, and expected benefits to each option. Handle risk as probability, impact, and compensating control, so that no step survives merely because removing it feels frightening.
Concrete documents:
- A future-state process map (after elimination, consolidation, and simplification)
- A disposition list per step (eliminate, reduce frequency, narrow scope, consolidate, standardise, reorder, or leave as is — with the reason)
- An options comparison (building a system, solving it through rules or organisation, and doing nothing, in the same columns)
- A risk register (per elimination or change: probability, impact, compensating control, whether it is accepted)
4.4 System boundary
From the future state, decide what humans perform, what goes to existing services, and what a new system handles. State what is out of scope. Only here do candidate system requirements appear.
IPA’s DX SQUARE likewise treats system requirements as something derived from business requirements settled beforehand.
Concrete documents:
- A boundary definition (human scope, existing-service scope, new development scope, out of scope)
- A candidate list of system requirements (priority, and which problem each one addresses)
- A decision record (go or stop, the reasoning, and when it will be reassessed)
What matters in this section is that the current state does not connect directly to system requirements. The future state and the comparison against non-system measures sit in between. That is the line between ordinary requirements work and a cleanup aimed at not building.
5. The pre-commitment decision table
Work through each process in this order.
| # | Decision | Main question | Result |
|---|---|---|---|
| 1 | Purpose | What outcome does this produce | Unclear purpose makes it a candidate for elimination |
| 2 | Necessity | Is it genuinely required by law, contract, value, or risk | No basis, eliminate |
| 3 | Duplication | Can other work or data serve instead | Consolidate or share |
| 4 | Scope | Is it needed for every case, every field, every time | Narrow the scope or frequency |
| 5 | Procedure | Can branches, approvals, and handoffs be reduced | Simplify |
| 6 | Standardisation | Can department- and person-specific exceptions go | Standardise |
| 7 | Existing means | Can a rule change, an operational change, or an existing product solve it | Do not build |
| 8 | Return on investment | Does it justify development, operation, and migration cost | Staying manual is an option |
| 9 | Technical fit | Is the processing stable and repeatable | Automate only the parts that fit |
| 10 | End condition | When does it get retired or reassessed | Avoid indefinite operation |
The order deliberately does not ask about systematisation first. Whether something can be automated is the last question.
5.1 Is it worth systematising
Two different questions remain after the table, and the order matters. One is whether the system is worth the investment; the other is whether the processing can be automated. The first comes first. Even a perfectly regular task repeated a thousand times a day is better left unautomated if the task itself can be eliminated.
On the investment side, six things need to hold.
- The problem being solved and the outcome sought are clear
- There is sufficient volume, risk, or value
- The expected user or business outcome can be measured
- The required data and its purpose are defined, and its quality can be managed
- Owners exist for the service, the process, and the data
- The expected value exceeds the lifecycle cost
The first three overlap almost exactly with what GOV.UK’s discovery checks before moving to the next phase: understand the problem and the users, establish the value of solving it and what it costs today, and judge whether pursuing it is worthwhile.
Volume is one variable in that judgement, not the judgement itself. Something that occurs once a year still belongs in a system if a single failure is a serious incident, if the data volume exceeds what people can handle, or if the law requires an audit trail.
On the fourth point, wanting to collect data is not a reason. The UK government makes data owners accountable for meaning, content, quality, and management, and for ensuring the data is fit for its intended purpose. The Data Quality Framework likewise treats good data as a precondition for better outcomes. Data whose quality and stewardship nobody can take on is not a reason to build.
The fifth point works the same way. GOV.UK defines the service owner as accountable for quality, performance, benefits, and outcomes. Start development with builders in place but nobody assigned to judge value, quality, data, and retirement after launch, and that accountability simply stays vacant.
The sixth point covers development and operation plus security work, data management, changes, migration, and eventual retirement. Part 3 returns to this.
5.2 How much can be automated
Once the investment holds up, look at the automation fit of each piece of processing. Microsoft’s guidance on automation recommends prioritising work that is repetitive, procedural, straightforward and clearly defined, with a long shelf life, and warns against forcing automation onto complex variation or human judgement.
- The processing is repeatable
- Start conditions, inputs, and results can be defined
- The decisions being automated can be expressed as rules or thresholds
- The procedure can be expected to stay stable for a while
- Standard processing can be separated from exceptions needing human judgement
The first two are linked. Even repeatable processing cannot be implemented until you know what triggers it, what it receives, and what it returns. Lean’s standardised work takes the same view, defining the currently most efficient method and using it as the baseline for improvement. Work that cannot be repeated reliably belongs to standardisation before automation.
The fifth point is what matters in practice. Being unable to automate the exceptions does not rule out systematisation. The same guidance treats automation as something other than an all-or-nothing choice: even a workstream containing human decision points can have the surrounding steps automated. With 100 routine cases and 5 exceptions, set the boundary that routes exceptions to a person.
5.3 States that belong back in the business
Work matching any of the following needs attention on the business side before it reaches a system.
| State | Where it goes back to |
|---|---|
| The purpose or users are vague | Problem definition |
| Success or improvement cannot be observed | Problem definition and measurement design |
| Criteria are not shared, and nobody knows why people differ | Standardisation of the work |
| Exceptions and variation dominate the standard path | Rethinking the process model |
| The procedure is not yet stable | Wait until it can be standardised |
| Data quality, meaning, and ownership cannot be assured | Sorting out the data |
| No owner exists for the service or the data | Assigning accountability |
| Low frequency with little expected value from automating | Keep it manual |
| Reproducing the current process is treated as a given | Examining whether improvement is possible |
Systematise while these remain and you fix the ambiguity and the disagreements into code. Establish first whether staying manual is tolerable, and whether an existing product would do.
That completes the procedure for understanding the work, recording it, and deciding what to systematise. Organisations that know this procedure still proceed to development. Part 3 covers the budget and contract structures that tilt them that way, and then organises everything from Part 1 onward into the conditions for committing to development.
References
- GOV.UK Service Manual — How user research improves service design
- GOV.UK Service Manual — How the discovery phase works
- GOV.UK Service Standard — 1. Understand users and their needs
- GOV.UK — Data ownership model
- GOV.UK — The Government Data Quality Framework
- GOV.UK DDaT Capability Framework — Service owner
- Microsoft — Recommendations for implementing automation
- Lean Enterprise Institute — Standardized Work
- Lean Enterprise Institute — Using Lean Thinking to Reinvent City Government
- IPA — Requirements definition guide for users, 2nd edition (Japanese)
- GOV.UK Service Manual — How to set performance metrics for your service
- GOV.UK — The Digital, Data and Technology Playbook
- Lean Enterprise Institute — Your Value Stream Map Looks a Little Different…
- GOV.UK Service Manual — Measuring the benefits of your service
- IPA DX SQUARE — What is requirements definition? (Japanese)