Purpose of DSP functionality
The problem it responds to
Infrastructure decision-making is fragmented. Different questions are answered by different teams, using different evidence, at different times, and the connections between those answers are rarely made explicit.
The DSP is designed to consolidate that fragmentation into a systematic, data and evidence informed process. The gain is not simply tidiness. A single process makes it possible to evaluate options and trade-offs transparently, which is to say that the reasoning behind a choice can be inspected by someone who was not in the room.
What it provides
The DSP provides a set of decision-making building blocks. These do two jobs at once.
| The building blocks help users... | ...by |
|---|---|
| Identify what should inform a decision | Naming the factors, information and constraints that belong in it |
| See how the decision is actually made | Illustrating the associated information flows, data flows, and processing steps |
The second is the less obvious of the two and matters more than it first appears. A decision whose data flow is written down can be audited, repeated, and handed to someone else. One that lives in an individual's judgement cannot.
When it matters most
The DSP is useful for routine decisions, but it earns its keep on hard ones. The handbook singles out infrastructure decisions with three characteristics:
Multiple stakeholders
More than one organisation or team holds a legitimate interest, and they do not necessarily want the same outcome.
Conflicting criteria
The things being optimised pull against each other. Lowest carbon, lowest cost and highest resilience are rarely the same option.
Uncertainty
The future conditions the decision has to survive are not known, only projected.
Where all three are present, informal decision-making tends to resolve the tension by hiding it. A structured process forces the trade-off into the open instead.
What it is designed to fit
The DSP is not a parallel process that sits beside existing practice. It is designed to support:
- a typical design sequence, and
- an Outline Business Case for UK public-sector infrastructure investment
That second point anchors it to how UK public infrastructure funding is actually approved, which is what makes its outputs usable rather than merely interesting. How this maps onto specific organisations is covered in Organisational processes.
Why it is a dynamic process
The DSP is described as dynamic: it can be iteratively updated rather than run once and closed. Three kinds of change trigger an update.
| Change | Example |
|---|---|
| Increasing data and information maturity | A condition survey replaces an assumed deterioration rate |
| Changing stakeholder priorities | A new carbon target shifts the weight given to emissions |
| Evolving regional and external conditions | Revised climate projections, or a change in planned development |
The practical consequence
Because any of these can change, a DSP output carries an implicit date. It represents the best decision given what was known at the time. Revisiting it when one of the three shifts is normal use of the process, not a sign that the first pass was wrong.