Heather is a single mother of two. Her abusive partner has just left. Her toddler needs care, and her five-year-old has just been diagnosed with a learning disability. She works a minimum-wage retail job and is behind on her bills. She needs financial help now, and a way to manage everything else coming at her.
Under the operating model her provincial government actually used, her next few weeks would have gone like this. First, she would find the income-support program and apply. Then she would find the childcare-subsidy program and apply again, telling her story a second time. Eventually she would be referred to a disability-services program for her five-year-old and tell it a third time. Each program had its own entry point, its own eligibility rules, its own assessment, and its own picture of Heather. In practice, that picture covered only the part of her life the program was funded to deal with. No one was responsible for asking whether Heather's family, as a whole, was going to be all right.
That is what a program-centred operating model does to people. This case looks at what it took to redesign that model around Heather, and what the redesign teaches about operating models more generally. It is based on a real provincial human-services transformation, with the details generalised.
The Context
The ministry's strategic goals were neither new nor in dispute. Citizens should be safe, healthy, secure, included, and moving toward self-sufficiency. Services should be easy to reach, connected to each other, and delivered at the right time through the right channel. The system should tackle root causes, not just symptoms. These goals had been written down, formally endorsed, and repeated for years.
The operating model told a different story. Like most of government, it was organised around programs. Income support was a program with its own budget, division, and reporting line. So was child intervention. So was disability services. In operating-model terms, each was a vertical, with its own intake process, eligibility rules, case workers, systems, and definition of who the client was. The org chart gave a clear picture of the programs. It gave no useful picture of Heather at all, because Heather isn't a program. She is a person with several needs at once, and nowhere in the model were all of those needs held together.
Program-centred versus citizen-centred
A program-centred operating model is organised around what government funds: separate programs, each with its own delivery machinery. It is efficient to budget for and easy to map. It breaks down when a citizen has more than one need. She has to find her own way through the org chart, telling her story again at every entry point, and no one is accountable for the overall result.
A citizen-centred operating model is organised around what the citizen experiences. Services meet her where she is, share what she has already told them, and work together toward an outcome for her rather than for any one program. The programs underneath stay the same. What changes is the operating model that sits on top of them.
The usual response to "our service is too program-centred" is the one governments reach for most often: a reorganisation. Merge the divisions, redraw the reporting lines, announce a new integrated department, and declare that the citizen is now at the centre. That would have changed the boxes on the org chart and nothing about Heather's experience. She would still have faced three separate entry points, because those entry points are services, and a reorganisation doesn't redesign a service. It just renames the division that runs it.
The Redesign: A Service Model, Not a New Org Chart
The transformation took a different approach. Rather than rearranging the programs, it designed a layer of shared services that sat in front of them, and built the operating model around those services instead of around the org chart.
It started where any genuine operating-model redesign has to start: with design parameters. These are explicit statements, drawn from the strategy, of what the model must make possible. Three of them shaped Heather's case: help citizens move toward self-sufficiency, make services easier to access, and offer efficient self-service channels to citizens who are able to use them. These weren't slogans. They were the tests every design decision that follows had to pass, and they explain why the model ended up looking the way it did.
Working from those parameters, the design identified the services the citizen would actually experience, and the capabilities each one would put into practice:
- Common service access: a single entry point across every channel, where a citizen's needs are identified once and her registration is captured once. This puts into practice the ministry's needs-identification and registration capabilities, which until then had been duplicated inside every program.
- Integrated eligibility, assessment, and outcome planning: services that work out what the citizen qualifies for across all programs, assess what she needs, and produce a single plan, instead of running the same machinery three times in three programs.
- Specialised services for genuinely complex needs that a general entry point can't handle, such as a child-intervention assessment or a disability determination. These connect back through a service coordination service that holds the whole case together.
Crucially, each service was offered through three channels, and the choice of channel was where the efficiency parameter turned into something concrete.
The three channels: Click, Call, Come-in
Every service was available online as self-service (Click), through a contact centre (Call), and at in-person offices (Come-in). Naming the channels explicitly mattered because of cost. The same transaction cost the ministry roughly thirty dollars in person, about twenty-five by phone, and less than a dollar online. The design parameter "use efficient channels where citizens have the capacity" therefore meant steering routine needs toward Click and keeping Come-in for the people and situations that truly require it. Heather's income-support application can be done online. Her child's disability assessment cannot. The model has to accommodate both.
None of this depended on redrawing the org chart first. The programs carried on running underneath. What changed was the operating model on top of them: a set of services built around the citizen, through which any program's capabilities could be reached.
Heather, Traced Through the New Model
Follow the same person through the redesigned operating model, and the difference makes the whole argument.
Heather reaches the common service access service, through whichever channel she prefers, and tells her story once. Needs identification recognises that hers isn't a single-program case: she has an income need, a childcare need, and an emerging disability need for her five-year-old. Registration records her details once, and those details go with her from then on.
From there, the services link together into a value chain. Integrated eligibility works out, in a single pass rather than three, what she qualifies for across income support and the childcare subsidy. The subsidy service then delivers its output, an authorised payment to her childcare provider, to a service level she can rely on: a decision that is timely, accurate, and there when she needs it. That output feeds an outcome the income program on its own could never have seen. Because her child is in care, Heather can keep her retail job.
For her five-year-old, a specialised child-development assessment produces a different output: a determination of eligibility and needs. That determination becomes the input for enrolment in disability services further down the line. This is what a value chain means here: the output of one service feeds the work of the next, and all of it is coordinated toward a single outcome for the family. A service coordinator holds the plan together across every step, so Heather no longer has to be the one connecting the pieces. The operating model does that instead.
Measuring at two points
A service model gives you two places to measure, and the redesign was set up to track both. The first is the output, measured by efficiency (the actual cost per channel) and quality (a timely, accurate decision reached through one entry point instead of three). The second is the outcome, measured by effectiveness: whether Heather's family is actually more stable, with steadier income, children who are supported, and less reliance on assistance over time. Output measures answer the question "are we doing things well?" Outcome measures answer "are we getting the benefits we intended?" A program-centred model could report on the first question for each program separately. Only a citizen-centred model could ask the second question about Heather.
What Made It a Redesign, Not a Reorganisation
Three things set this apart from the reorganisation it could easily have become, and they are the lessons that carry over to other settings.
The governance questions were explicitly on the table. The transformation framed the shift it needed around two questions that readers of the Design4 framework will recognise: are we doing the right things (relevance), and are we doing things right (efficiency)? These are two of the Four Ares, and they were shaping a real government operating-model design a decade before this case was written up. Moving from program outcomes to citizen outcomes answered the relevance question. Moving to efficient, joined-up operations answered the efficiency question. The operating model sat exactly where those two questions meet: in the machinery of Develop and Deliver.
The deliverable was a blueprint and a roadmap, not a new structure. The target operating model was captured in a small set of connected models: who the ministry serves and interacts with, which services it would deliver and how they link together, the capabilities underneath those services, and who is accountable for each. Together these formed a blueprint of the capabilities required and a roadmap for building them over several years. This is conceptual design work, which is why the business architect needed to be involved when the design parameters were being set, rather than receiving them afterwards. The parameters were the link between the strategy and the operating machinery, and getting them right was itself a design task.
Leaders were told plainly that this was a culture change, not a restructuring. The ministry's senior leaders said so directly. They knew the temptation would be to treat the effort as a reorganisation, redraw the divisions, and move on, and they identified that as the failure to avoid. The structure did change eventually, but only after the services had been redesigned, not before.
A candid caveat, because the transformation wasn't perfect. It was a large, consultant-led effort, and it shared the usual tendency of such efforts to produce a heavy set of models and documents. What's worth keeping is the underlying logic: capabilities put into practice as citizen-facing services, measured at both output and outcome. The volume of documentation is not the point. A service model proves its value by being run and measured, not by being filed away.
The Outcome
The redesign didn't fold Heather's needs into one giant program, and it didn't abolish the existing programs. Instead, it placed a service layer in front of them: a single entry point, a story told only once, eligibility and planning handled across programs rather than inside each one, and a coordinator overseeing the whole case. The programs kept their expertise and their budgets. What changed was the operating model connecting them to Heather. Before, she faced a set of silos she had to navigate on her own. After, she was served by a chain of connected services that did the navigating for her.
For the ministry, the benefit was structural rather than immediate. The old model multiplied fragmentation: each new program added another entry point, another intake process, and another partial view of the citizen. The new model multiplied coordination: each new service drew on shared needs identification, shared registration, and a shared plan. As a result, every new initiative made the next one cheaper to deliver, and made the citizen's experience more connected rather than less.
For Heather, the benefit was simpler. She received the childcare subsidy in time to keep her job. Her five-year-old was referred to the right assessment without her having to find out the program existed. And for the first time, someone was accountable for whether her family as a whole was going to be all right, not just for whether one program's box had been ticked.
This is what a service-oriented operating model looks like in practice, in a sector where what's at stake is a person rather than a market. The programs are the capabilities: what the ministry is able to do. The services are how those capabilities reach a citizen. The org chart, the very thing a reorganisation would have rearranged, turned out to be the least important layer, because Heather never experienced the org chart. She experienced the services. Redesign the services and you change her life. Redraw the boxes and she is still on hold, three offices in, explaining her situation for the fourth time.
The full argument, along with four more worked examples from the public and private sectors, is in the operating model pillar. The one-page instrument used to map a model like this is the free Service Operating Model Canvas.