The decomposition problem
Programme management operates through decomposition. A large initiative is broken into programmes; programmes are broken into projects; projects are broken into workstreams; workstreams are broken into deliverables with milestones and owners. This is a powerful coordination mechanism - it is what allows organisations to manage initiatives that are too large and complex for any single team to hold. But decomposition creates a characteristic form of blindness: the experience that cuts across workstreams, the user journey that does not respect programme boundaries, the emergent behaviour that only becomes visible when separately-managed components interact.
This is not a failure of programme management; it is an inherent property of decomposition as a coordination strategy. When you break a complex initiative into manageable pieces, you necessarily create seams between those pieces, and the seams are where the most consequential design problems tend to live. The patient who encounters six separately-managed services in the course of a single referral pathway does not experience them as six services; they experience one journey, and the quality of that journey is determined more by the transitions between services than by the quality of any individual service. But no single workstream owns the transitions.
Sangiorgi and Prendiville (2017) frame public services as "the realization of policies" - and the realisation often looks very different from the policy intent when experienced end-to-end. A policy that makes sense as a set of requirements, decomposed into workstreams and delivered component by component, can produce an incoherent experience for the people who encounter the whole system. This is the gap that service design is uniquely positioned to address: not by replacing programme management's decomposition logic, but by providing the cross-cutting view that decomposition structurally cannot generate from within itself.
Making the invisible visible
The second distinctive contribution of service design in programme management contexts is the ability to surface decisions that have been made without anyone recognising them as decisions. Programme management optimises what it can measure and report. But the most consequential design choices - what gets shown on a dashboard, how a referral pathway is structured, what information a clinician sees at point of decision, what data is collected and what is discarded - are often made implicitly, by engineers or analysts, as implementation details rather than design decisions.
Drummond (2021) frames this as a question of authority: who gets to make decisions, and how those decisions are made, shapes our services. In programme management cultures, decision authority is carefully allocated through governance structures - programme boards, senior responsible owners, design authorities (in the technical architecture sense). But the decisions that most affect the user experience often fall below the threshold of governance attention. They are made in sprint planning, in data model design, in the configuration of business rules, in the choice of which edge cases to handle and which to defer. These are, functionally, design decisions made by people who do not think of themselves as designers.
Service design's contribution here is not to claim ownership of these decisions but to make them visible - to surface them as choices with consequences, so that the programme's governance structures can engage with them deliberately rather than inheriting them accidentally. My notes and work on how (transparency) dashboards constitute publics demonstrates this at scale: every metric included or excluded, every threshold set, every comparison enabled or disabled is a decision that shapes who the dashboard serves and how it shapes their behaviour. Making these decisions visible is not obstructing delivery; it is preventing the programme from committing to consequences it has not examined.
Holding the temporal dimension
Programme management is structured around a delivery timeline with a defined endpoint. The programme has a start date, a set of milestones, a target completion date, and a benefits realisation period. This temporal structure is appropriate for the coordination task - it allows resources to be allocated, progress to be tracked, and accountability to be maintained. But services persist and evolve; they do not end when the programme that built them closes.
This creates a structural tension that programme management struggles to resolve from within its own logic. The programme is incentivised to deliver its scope on time and close; the service needs to adapt to changing user needs, evolving policy requirements, and the lessons that only emerge from sustained operation. The programme's success criteria - delivery to time and budget - are necessary but not sufficient for the service's success criteria, which include ongoing fitness for purpose, adaptability, and the capacity to learn from use.
Service design brings the question that programme management is structurally disinclined to ask: what happens after the programme closes? How does the thing that was built continue to serve its users? How will it adapt to needs that were not anticipated during the programme? What operational capability needs to exist to sustain and improve it? Penin (2018) identifies the space involving labour relationships, power and control, and the role of aesthetics in services as inherently complex; services are not products that can be built and shipped but ongoing relationships that require ongoing attention. Jones and Van Ael (2022) describe sociotechnical service systems in healthcare as integrating "complex work routines for high-reliability services" - routines that cannot be fully specified during a programme's delivery phase because they emerge from the interaction between the designed system and the practices of its users.
The practical expression of this temporal perspective is the insistence on questions that programme management finds uncomfortable: who will own this after go-live? What capability exists to iterate on it? How will user feedback be collected and acted upon? What happens when the policy changes? These are not obstructive questions; they are the questions that determine whether the programme's investment will produce lasting value or become legacy on arrival.
The value proposition, restated
The value of service design in programme management cultures is not "making things user-friendly" - a framing that programme managers can rightly deprioritise against delivery risk. It is something more structural: the ability to see what decomposition renders invisible, to surface decisions that governance has not engaged with, and to hold a temporal perspective that extends beyond the programme's delivery horizon. These are capabilities that programme management genuinely needs but cannot generate from within its own logic, because they require a different epistemological orientation - one that holds open questions rather than closing them, that looks across boundaries rather than within them, and that evaluates success over the lifetime of the service rather than the duration of the programme.
The challenge, which the next post on boundary objects takes up, is that possessing these capabilities is not the same as being able to deploy them. The designer who can see the cross-cutting view must still find ways to make that view legible to programme governance. The designer who can surface invisible decisions must still present those decisions in a form that programme managers recognise as actionable rather than disruptive. The value is real, but it requires translation.
References
Drummond, S. (2021) Full Stack Service. Snook.
Jones, P.H. and Van Ael, K. (2022) Design Journeys Through Complex Systems. BIS Publishers.
Penin, L. (2018) Designing the Invisible. Bloomsbury.
Sangiorgi, D. and Prendiville, A. (2017) Designing for Service. Bloomsbury.