Alberta Service Design & Delivery Principles (Working Draft)
By: Alberta Digital Innovation Office
Tags: Outcomes, Government, Innovation, Service Design, Digital Transformation

Our team has been busy for the last couple months, but we’ve finally got our draft principles ready to share with the digital and civic innovation communities. We’d love your feedback (either here on Medium, or get in touch by email — DIO at gov.ab.ca).

Alberta Digital Transformation Principles

Start with user needs*

*not government needs

i.e. Put users at the centre of service delivery; not business, function, government, system, or technology considerations.

2. Deliver* in 24 weeks or less, then deliver again.

*something of value into the hands of users.

i.e. Shift from the inertia of government to the pace of a startup.

3. Fund teams* not projects.

* internal delivery teams

i.e. Shift from a practice of outsourced implementation to delivery through empowered, multidisciplinary, insourced teams.

4. Design and deliver end-to-end* services

* support the user’s entire journey from start to finish

5. Transform top-to-bottom

*create the organization that can deliver new innovations

6. Default to small pieces of technology, loosely joined*

*not big IT

i.e. Drive the adoption of modern technology practice through an ecosystem of products and platforms that serve as an enabler rather than a constraint for continuous deployment to meet identified user needs.

7. Work in the open.

i.e. Open up the Government of Alberta to the wider service sector by sharing opportunities and action, standards, code, successes, and failures.

Some Thoughts on the Principles from our Chief Officer, Dominique Bohn.

Jess McMullin, DIO’s Strategy & Capability Lead, sat down to chat about the principles with Dominique Bohn. What follows is a lightly edited transcript of the conversation.

Some Thoughts on the Principles from our Chief Officer, Dominique Bohn.

Jess McMullin, DIO’s Strategy & Capability Lead, sat down to chat about the principles with Dominique Bohn. What follows is a lightly edited transcript of the conversation.

Jess: I’m here with Dominique Bohn, Chief Officer of the Alberta Digital Innovation Office, and we’re going to talk about the brand new draft of the DIO principles to help us do better work in government, to meet the needs of Albertans, and to cut costs and complexity from services that we deliver every day.

Dom, I’m interested in hearing your take on these principles. We’ve got seven of them. We’re just going to run through them right now. The very first one is start with user needs. What should people keep in mind about starting with user needs if they’re going to tackle services in government?

Dominique: I think it’s the thing that all people need to actually start with. I was just reflecting on Amazon’s leadership principles, and their number one principle for leaders is ‘be customer obsessed’. I think that that is the same approach that we need to take, for the same reasons they do; you actually end up building better things and you could do it efficiently and effectively and be creating desirable things for people.

I think for us now, our evidence and empathy approach is that if you can really prove that something is needed by the people who have to use it, that should be what grounds you. Also, I think it’s a public service principle that we should care about the people who we serve, and starting with user needs is how we do that. It’s both efficient and effective, and it’s also just the humane way to work, I think, as public servants.

JM: Thank you. Bridging into the next principle, deliver in 24 weeks or less, and then deliver again. What does that mean?

DB: That one’s quite specific, but I think we need that in a principle, especially for government, because there’s really a problem. I think we find every day that there’s a real tendency to drag our feet on things and to be very, very cautious, but I think maybe cautious about the wrong sorts of things. Delivering something, whether it’s perfect or not, is still making things better. No matter what, it’s a learning opportunity.

If you’ve started with user needs, and you know you have a real problem that needs to be fixed for a real person, then putting something in their hands as soon as we possibly can is going to get us to something better sooner. This is really about shaking up that government inertia problem. Jess, you have always said, perfect is the enemy of done, and we really need to live that every day.

JM: So, there’s a second part of the principle. We break that inertia by delivering in 24 weeks (or less) and then we deliver again.

DB: Exactly. I think that what we’re looking for is truly a culture of continuous improvement in government services. The world changes all the time, not just technology and applications, but policy and the needs of citizens evolve. We have to respond to that. It’s a continuous iteration. What we’re really trying to get away from is those big bang projects where we literally wait for years and years and years to make anything better. This is why so many government services, both digital and terrestrial, seem so antiquated — because we continually delay getting something out there. Again, we’re trying to upend that and deliver in small pieces and make that the way we work every day that we come to work.

JM: Fantastic. That leads us into our third principle, which is fund teams, not projects.

DB: This is really the mechanism of how you do that. I think we’ve learned, in our first year and a bit here, how important that is. I’m glad that this has actually surfaced itself in one of our principles. It’s not necessarily one that we see everywhere, but I think it’s been one of our big learnings that we have to get out of this project mindset, this “do the thing and then set it and forget it” has really been an expensive and ineffective way of working for us as government. This way we get people in who understand the program. This is the idea, too, that we have teams who work closely alongside the service or program that we’re delivering. This is technical people and design people, small teams. We know there’s this magic unit of delivery, five or six people who can work on a problem continuously over time. We have found just exponentially better outputs of that, and also just happier people.

I had someone who’s recently started with us here say, “I just get goosebumps working with this team and talking about these kinds of things.” Our Christmas cards alone were a testament to how much fun people have working that way. It’s really the ability to put something in citizens’ hands that I think gets people super excited. It’s the magic unit of people that actually gets the stuff done.

JM: We’re going to talk about what those magical teams work on with our next principle: design and deliver end to end services.

DB: Everything that we’ve started with, we’ve said, what is the baseline, what are we actually trying to improve here? If we improve just one small thing, if we have a form that people can fill out faster or if we have one piece of a service that might work better, it’s not actually solving what matters to people. People don’t come to government to fill out a form. They come to get a childcare subsidy, or whatever other outcome is valuable to them.

We have to be looking at that whole thing. What does it take to actually complete that transaction for them? That’s what we mean by that. Sometimes that’s a really hard question, because often that means you’re working with people in different groups of government, in different areas, and a part of our job is bringing those people together. It’s also managing the relationships as much as anything, but we have to start with that big picture, even when we have a specific intervention.

The thing is, it’s a clear path. It’s actually quite measurable. You can say, what is the journey this person was able to complete? Were they able to get the subsidy they needed, or potentially did they not get it? We have to measure that and not just measure, e.g. we answered the phone in 32 minutes. The kind of measures that we use in government tend to be very granular, quite specific, but not super meaningful. Instead, we need to ask what is the real thing that people need to do with government and how well can we deliver that? That’s our measure. We look at the cost of delivering that service overall, the technology, the people, and organization, and then how satisfying and how complete that experience is for our citizens.

JM: I think that actually leads us to the next principle, as a corollary, and you just started to get into it with all the things that go into that end to end journey, and the principle is, transform top to bottom.

DB: That can mean a couple of things. I think it can mean transform the service top to bottom. When we go in, you and I especially Jess, we actually start asking questions about the organization itself like, what is your actual organizational structure and design? Who reports to who? How do things work? How does the front line service work? How does the call center work?

People, I think, are often surprised because you’re here to make an app. You’re here to do a technology piece, and we are, but that’s only the tip of the iceberg. Services are systems, with lots of connected layers. Digital innovation has impacts across the whole service, so we need ask all those questions and find out how different things need to configure themselves to make that work better, from frontline delivery, to policy, to technology, and to the organization and budget.

I think top to bottom for us actually also means where we work as a team, because we are really looking to change thinking and change practice from frontline service delivery people to even elected officials, at least up to senior leadership in government. We’re trying to have that influence all across, which is challenging, but I think it’s worth doing. It’s a big part of what we’re really trying to do, to engage at all those different levels so that transformation is really embedded in how people work, whether they’re frontline staff, middle management, technical people, or executives, breaking that down so that we are working across hierarchical silos.

JM: So top to bottom with the layers of delivery and service systems, but also the layers within government.

DB: Exactly.

JM: Alright, let’s look at our sixth principle: Default to small pieces of technology loosely joined.

DB: It sounds quite specific, but again, this I think really comes out of our experience in the last year and a half. I think what we have to acknowledge, and maybe the other shoe drops slowly, is that government cannot afford to buy giant proprietary platforms anymore. We need to start building smaller pieces that work together and are more flexible. Traditionally, we’ve incurred huge licensing costs. We’re making huge operating costs for big systems that take a lot of configuration, and actually end up never really quite being fit to purpose. This is an agile principle really, that you put off your big technology decisions as long as you can, you make just the ones you need to make, and that’s a real mind shift. There’s a certain comfort in saying “we bought the whole thing, it’ll do everything”, but we’ve just found it never has. I don’t know a good story about when that’s worked.

We’re looking at this as a good response to budget constraints. We also think a good response to being able to be more flexible and adapt to both, as I say, those policy and service needs. It’s breaking things down again. It ties into the other principles of delivering quickly in a pace. This is really about a flexible component-based, interoperable, rich technology system. We want developers and designers to have good tools to work with so that they can always be taking advantage of the best new things, so that we’re not committed to the 10 year ago thing, which is largely how a lot of our technology runs now. That’s kind of the facts.

What we’re doing now is trying to back ourselves out of big legacy systems, big legacy technology so that we can work towards this. That is a huge, almost an underwater invisible cost that we have in government, just maintaining the stuff that’s already there that is actually not producing a lot of value for citizens. This is the mechanism of moving us off of those big underwater costs that we hardly even take account of anymore.

JM: Thank you. What really stands out in your description is how these smaller, more configurable pieces not only cost less, they also fit the work better instead of the one-size-fits-all approach of big systems. That’s going to mean better staff experience and better citizen experience.

JM: Last principle, work in the open.

DB: This means a lot of things. For me, I think this means that our teams are showing their work to everybody who may have an interest in it, early and often. It was interesting, at a meeting yesterday, we were talking about after we’ve gone into production with this piece of software that we’re talking about, of course, we’re going to continue doing that because we have a continuous improvement cycle where we’re continually showing what we’re doing. It’s just a good habit to get into and the way we do our projects sets us up to do that. This is the idea that every couple of weeks you have an open demo of what you’ve actually built and everybody is invited in the program or service area. You have people there from frontline staff to deputy ministers. It also means going out to citizens and continually testing concepts with citizens for how the service should work.

Early front end research, usability testing, and continuous engagement with stakeholders and citizens is really what’s going to get us to both a better customer experience for citizens, but also again an efficient one because we’re not going and building things that people aren’t going to use.

Working in the open is also publishing code on GitHub. This is that kind of open, as well.

Something that I think that we need to improve on more, is actually just talking about our struggles in the different publications, different channels that we can use (both in and outside government). Here’s what we’re really doing. Here’s what’s really hard. Here’s what we need help with. Does anyone else have this problem? There is really, I think, a community approach that we can be even more broad on. The open is an open kitchen production environment, as well as, open to citizens, as well.

JM: Thank you. There’s our seven principles:

1. Start with user needs;

2. Deliver in 24 weeks or less, than deliver again;

3. Fund teams, not projects;

4. Design and deliver end to end services;

5. Transform top to bottom;

6. Default to small pieces of technology loosely joined; and

7. Work in the open.

Dom, thank you so much for expanding on those.

Dominique: I’d work there, yeah.

Jess: Yes! Excellent. Thank you.

Dominique: Thank you!