[August 2026 edition]

The Art of Not Building, Part 3 — The Budget, Contract and Approval Structures That Block a Decision Not to Build

Published: Aug 11, 2026
Reading time: ~10 min

Part 1 trimmed the work with ECRS, and Part 2 decided the scope of systematisation from what remained.

Even so, a practitioner who follows both can find the development impossible to stop. The finance function has already secured budget under a system development line. The procurement function has signed a contract that pays against delivered artefacts. The user department picks the option that leaves its roles and responsibility boundaries untouched, and the approver holds no authority to cancel a development already under way.

In other words, a practitioner may propose reducing the work while the institutions receiving that proposal have no way to score it. Part 3 sets out seven factors on the institutional side, and then organises everything so far into the conditions for committing to development.

1. Organisational factors that block a decision not to build

Even when not building is the rational choice, organisations lean toward development. The factors sit in the structure rather than in individual judgement, and they operate in sequence.

#	Factor	What happens
1	Budget approval fixes the solution first	Funding processes ask for approval of a concrete investment rather than an exploration of the problem. Once approved as development, changing or cancelling it is hard even if research shows it is unnecessary
2	The artefact becomes the goal	”Introduce the new system” is an output, not an outcome. Once introduction is the target, deciding not to introduce reads as failure
3	Contracts pay for building	Where payment attaches to feature counts, effort, and fixed-scope delivery, discovering that something is better left unbuilt has no economic route
4	Existing work resists change	Replacing only the system leaves roles, authority, and responsibility boundaries intact. Eliminating or merging work requires cross-department negotiation and reassigned responsibility
5	Starting is designed; stopping is not	Against proposal, budget, and approval as an entry process, no exit process of equal weight exists
6	Problems get framed as technical ones	Convoluted rules and vague authority arrive as requirements for a data platform or a workflow engine
7	Disposal costs too	Retirement brings data migration, user notification, untangling dependent systems, and archiving

There is causality in that order. A budgeted item is defined as an artefact, a contract rewards its delivery, and the organisation swaps the system while leaving the work alone. Once the investment starts, the decision to stop has little purchase; the remaining complexity is absorbed by technology, and the result becomes the next legacy. The real goals sit elsewhere: shorter handling times, fewer incidents, less burden on customers.

1.1 Budget approval fixes the solution first

The OECD’s Digital Government Outlook 2026 assesses the machinery at the start of digital investment as mature — needs identification, business case, securing funding. What it finds weak is the machinery for changing budget or direction mid-course and for stopping when results fall short.

When funding is built around upfront approval and annual cycles, an investment that underperforms is hard to halt or redirect. Securing approval requires making the solution concrete in advance, and development is fixed as the means at that moment.

1.2 The artefact becomes the goal

The UK government’s project delivery standard structures benefits management to begin from why change is needed, what the objectives are, and what success would look like.

Introducing a system is an artefact; shorter handling times and fewer errors are the outcome beyond it. Lose that distinction and achievement gets judged by whether the introduction happened.

1.3 Contracts pay for building

This is a question of procurement structure rather than of external vendors. The UK government’s sourcing guidance states that fixed-price arrangements assume a fixed scope, and advises against applying them to work whose scope varies.

Order 100 person-months, 20 screens, and a specified feature set, then discover that changing the business process makes 10 of those screens unnecessary, and no route exists to treat that as a result. Contract around outcomes and the room to change the solution stays open.

1.4 Existing work resists change

Swapping the system alone leaves roles, authority, rules, and responsibility boundaries untouched. Eliminating or merging the work itself brings cross-department negotiation and reassigned responsibility. Information systems research examines resistance to new system adoption through status quo bias for this reason.

The inefficiency of existing work is already sunk into daily cost, while changing it incurs fresh learning, migration, and coordination. That asymmetry produces the inversion where the technology changes substantially and the work stays exactly as it was.

1.5 Starting is designed; stopping is not

Research in Management Science examines why low-value products are so hard to kill, showing how money already spent ends up justifying further investment. Its point that the decision to stop needs its own evaluation and reward applies directly to organisational design.

Combined with the institutional side in 1.1, entry has proposal, budget, and approval, while the process for reassessing and terminating carries nothing like the same weight.

1.6 Problems get framed as technical ones

An ACM article discusses the hazard of technological solutionism, the tendency to treat even social and institutional problems as things technology can solve. Building a data integration platform because departments mean different things by the same field, an AI search because the rules are convoluted, or flexible permission management because authority is vague — each adds a processing layer while leaving the original problem in place.

The range in which this occurs is wider than the engineers. An executive decides on adoption, a vendor explains the problem through a product, a procurement function budgets it as a system project, and a developer receives it as an implementation problem. A technically interesting problem and the problem the business needs solved are not necessarily the same.

1.7 Disposal costs too

Building something and deleting it later if unnecessary is not always available. GOV.UK treats retiring a service as its own phase, asking teams to consider user needs as they did during construction and to work out how those needs will be met once the service is gone. The UK government’s legacy IT guidance notes that maintaining ageing assets becomes a security and cost burden.

The decision to commit to development therefore includes the future cost of removal, not only the initial build.

Measurement pushes the same way. If a development organisation is judged solely on features shipped, tickets closed, scale delivered, products introduced, and tasks automated, it will keep building things nobody needs. The alternatives are countable: processes eliminated, input fields and approval stages removed, reports consolidated, reductions in enquiries, handling time, and wait time, problems solved without building, running cost that never materialised, and existing systems retired.

Features never built leave nothing on screen, yet they are measurable as a design result. Remove one feature and its design, implementation, testing, and monitoring go with it, along with access control, support handling, incident response, data migration, security fixes, and future modification. The gain from not building is not limited to saved initial cost; it lies in never taking on the responsibility that would have continued indefinitely.

2. Define the conditions for proceeding before fixing requirements

Conventional requirements work reaches a milestone once the necessary features are defined exhaustively and stakeholders agree. IPA’s DX SQUARE likewise describes deriving system requirements from business requirements and turning them into requirements through stakeholder agreement.

What follows is the gate placed before that. What it judges is not whether a requirements document is finished, but whether enough reason has accumulated to proceed with development. The conditions amount to the destination of everything from Part 1 onward, in four groups.

2.1 Have you understood the problem

The problem to solve and the intended outcome are defined
Users and the main parties affected by the problem are identified
The current flow of work, information, and services is understood

As section 1 of Part 1 showed, requests arrive as solutions. Turning them back into problems and settling whose problem is being solved happens here. Stakeholders include not only users but beneficiaries, those accountable for controls, and decision-makers. Understanding the current state means the actual practice covered in Part 2 — what people really do, not what the manual says.

2.2 Have you reduced the work

Each step can be explained by the value it provides or the necessity of keeping it
Unnecessary steps, duplication, re-entry, and approvals are identified, with a decision on eliminating, consolidating, or simplifying them
Rather than porting the existing process, the process as it should be has been considered

The ECRS of Part 1 maps onto these three. Applying eliminate, combine, rearrange, and simplify in order produces 5 and 6. Point 4 is the inverse of 3: steps whose value cannot be explained remain candidates for elimination. Skip this and you get what the five patterns in Part 1 describe — the means changes and the structure of the work survives.

2.3 Have you compared against not building

Solutions other than system development have been considered
The value of proceeding has been assessed, including the option of not developing

Check whether rule changes, organisational changes, contract changes, and use of existing services were compared on the same footing as building. Point 8 asks whether the comparison leaves you able to choose the conclusion of building nothing. GOV.UK treats deciding not to move to the next phase as a legitimate result of research, freeing the time and money for something else.

2.4 Have you set the scope and the criteria

What counts as in scope for the problem, and what does not, is agreed
Within that, what the system covers and what it does not is clear
Current baselines, expected improvement, and success measures are defined
The conditions for proceeding, and the criteria for not proceeding, are clear

Points 9 and 10 are different things. Settling what falls outside the problem leaves open how much of the remaining problem software will handle. GOV.UK treats agreeing what is not part of the problem as part of reframing it. Point 10 corresponds to the system boundary in Part 2.

Point 11 is where the baselines taken in Part 2 pay off; without them nobody can later judge whether anything improved. Point 12 does not mean setting mechanical kill criteria in advance. It means holding, at this moment, enough information and enough of an evaluation frame to choose either continuation or termination.

Framed this way, requirements stop being the product of exhaustive feature collection. What remains as a requirement is only the part judged to need a system after understanding the problem, redesigning the work, and comparing non-system measures and the option of building nothing.

3. What committing to development takes on

Software organisations tend to reward people who can build technically difficult things: intricate permission models, flexible workflows, general-purpose rule engines, platforms handling large data volumes, sophisticated AI agents. Trace back why the complex system became necessary, though, and you often find convoluted work, vague accountability, inconsistent rules, and exceptions that were never removed. Technology can absorb that complexity, and being able to absorb it differs from being the right place to absorb it.

Build a system and the organisation maintains it for years. It protects the data, responds to incidents, trains users, keeps up with regulatory change, updates ageing technology, and eventually migrates and retires it. Committing to development is a decision to write code and, at the same time, a decision to take on that maintenance responsibility indefinitely.

Everything across this series reduces to five questions to settle before committing.

Is this work genuinely necessary
What is this check for
Why is this information being retained
Who does this approval protect
Does this need a system at all

None of them are technical questions; all of them sit on the business side, and the target of implementation stays undecided until they are answered. If the problem can be solved without building, that is the smallest, fastest, safest, and most maintainable form available. The art of not building is the most upstream design discipline there is, and it exists to leave only what is worth building.

Write code and you create the risk of defects. Write none and that risk never arises. There is no reason to take on a risk you do not have to carry.