Paul spoke at the 2014 Central Government Business & Technology Conference in his capacity as Chief Digital Officer for the UK Ministry of Justice. You can watch Paul's speech, access his slides, and view a transcript of his comments, below.
Paul Shetler: So I’m one of the guys who was brought in by Liam and Ian - excuse me, by Liam and Mike about nine months ago from GDS. And I was dumped into the MoJ. I came in from the outside, so I’m relatively new to government. I used to say that I’m brand new to government, but I’m no longer. I’ve been there for about nine months. And in the course of that, I’ve learned a few things. My background has always been pretty much either in financial services or on the large vendor side, so I like to think of myself as a poacher turned gamekeeper. And I’ve been surprised at some of the things I’ve seen. I’d like to talk about some of that.
So coming from the outside, you know, my expectation was probably pretty much like most people’s. When people think about sort of commercially-available digital services, they think of usually things to do with e-commerce, or things like Facebook or whatever. But they’re things which are very very simple, they’re things which you tend to seek out, they’re things that don’t usually stick a lot of barriers between you and spending money, they’re things where quite frequently there’s a lot of tinsel around marketing, where you want to sort of up-sell, or cross-sell, or get somebody to do something else. And really nothing stands in the way of that. So you don’t need, for instance, to have a lawyer or a solicitor tell you, ‘What button do you click next on Amazon to buy your book, or to buy your game?,’ right? It is very cleanly designed, yeah.
And it’s a very sort of different situation to what I found in government. Because in government, typically, we don’t have customers. So all sort of the marketing stuff about customers, or audiences, and all this kind of stuff, flies out the window. Because actually, people who use our services have no choice. They have to use us. And we have no choice of who they are. We can’t be like a bank and say, ‘Oh, you’re not profitable enough, please go away’. In fact, quite often, the people who we’re going to be serving are those who in fact are not profitable enough, right? And they’re typically, in the case of Ministry of Justice, something a bit further than that. Typically, they’re people where something has gone terribly wrong in their life. People don’t usually come to the MoJ because, you know - they never come to the MoJ because something has gone terribly right. They come to the MoJ because their mother is about to become incompetent, and they have to do a lasting power of attorney, because they want to visit somebody who’s in prison, because they’re the subject or the initiator of a lawsuit, because they need legal aid, all these kinds of things which are typically not things that anybody would seek out. In fact, no one does, right? It’s something which befalls you. And, when you’re there, and you’re needing to use an MoJ service, your life has been turned upside down. You’re not in a position of, you know, happily choosing what beach you want to go to, or which airline you should be taking, or which book you might want to be buying. You’re trying to navigate yourself through what’s already a fairly complex process, at a time when you’re probably emotionally least prepared to do so. It’s the nature of the services we offer. We can’t really help that.
A great example of this is this persona, Sherry, who needs to visit a family member in prison, you know? And the way that the prison booking service used to work in the past was that you’d have about a half-hour to call a prison, at the exact same time that everybody else was calling the prison, to visit a family member, and you might have one or two people answering the phone. And those people were also doing all their other work at the same time, which basically meant you could be on the phone for that entire half-hour, on hold, and then just be told, ‘Sorry, time’s up, goodbye,’ and never make the visit. And so people would be jamming on the phone lines, and if they did get through, they’d try to book all the times of available, even whether they could make them or not, because, you know, you never know when you’re going to be able to do so. And it was an absolute nightmare, right? And that is the kind of service that we were trying to figure out how to solve. So it’s a rough situation, if you’re a user of the Ministry of Justice.
And, when I came, there was already a pretty well-established team. So I joined about January 6 of this year, and it was a very well-established team there, about 75 people. And almost all of these people had come from the outside, so there were very very few civil servants, there were very very few people who had intimate knowledge of how the systems inside the MoJ actually work. And these people primarily came from a digital background, by that I mean agency background, they had - many of them had done an awful lot of green field work. Not too many had done an awful lot of integration work, or work involving a substantial integration with existing systems or transactions. But it was a very, very talented and idealistic group of designers, researchers, developers, product managers, and so on. And they were trying to fix the situation of waiting for half an hour to visit somebody in prison.
And what I saw immediately was that they were outsiders. They had come in, and they saw how broken everything was, and they were sort of wondering, What should they do about it? And I think Liam alluded to sort of, you know, Agile/Waterfall type stuff, actually that’s exactly what I saw. I saw basically teams who were trying to do a total service transformation in the case of the four exemplars - so we’re doing four of the government’s 25 - in the case of the four we were doing, they were taking very seriously this sort of mantra of total service transformation, end-to-end, and not being able to reconcile that with the other message that was coming out of GPS, which was MVP: iterate, do something small, iterate, iterate, iterate, iterate wildly until you get to where you want to get to, right? And it was really a very very difficult situation to find them in. They were - there was a lot of emotion in the team. There was a lot of concern that we might not be able to meet our timelines. Keep in mind that the timelines we’re talking about were March of next year, March of 2015. In January of 2014, they didn’t know if they could make that, any of them. The methods - the methods that they were using were kind of all over the shop, and they had been very much sucked into the Ministry of Justice’s sort of way of doing things, because everybody they dealt with said, ‘Oh, well, this is how we do things, oh, by the way, you’ve got to connect to this system over, or you’ve got to, you know, do this requirements document that will take you so long, you’ve got to deal with this vendor over here, they’ve got to review it, that might take you so long, and you might have to then go through this particular system over here, oh, that’s another change request, and so on and so forth’. And we had to make some changes to that.
My first report to my management was that I had to rate everything red. And it wasn’t a really happy thing for me, because I thought, ‘Wow, I have a great team here, you know. We’re delivering really great stuff.’ And it turns out they were trying, but they got sucked into the idea of, like, endless scope. So what we wound up doing was deciding that we would drastically descope - sometimes people think it’s a bad word, I don’t think it is at all, I think designing what is a good minimum viable product is the best thing you can possibly do, having a shipping MVP is way better than a never-delivered total service transformation. So first thing I learned was, ‘MVP is better than total service transformation’. And the way you do that, or the way we’ve done that, is by forcing people to work within a really strict timebox. So the idea of a transformation programme which takes 18 months is not transformative. We say, basically, if you can’t deliver within 20 weeks, you’re doing something way too big. Rethink it again, and do something valuable within that 20 weeks. Don’t talk about doing stuff that’s going to take two years, or a year. And what that means is that we can start delivering really world-class services within human timescales, not these glacial civil service timescales, but human scales. That actually makes a difference to real people’s lives. And we start also building credibility with what’s called ‘the business’ inside of government - I’ve been really surprised by that phrase, ‘the business’ because, actually, I don’t think the government does ‘business,’ but anyways - there’s executive agencies, and we build credibility with them. We show that we actually do deliver. And not only that, but very very importantly, we also show iteration, because many of the people in the agencies we’ve been dealing with have been traumatised, I think, by the fact that they have had systems delivered in the past, done in a very Waterfall kind of fashion, and then one we’re delivered, so like, ‘Hey guys, it’s done, it’s finished’. ‘Oh, we didn’t mean that, oh we didn’t want this, oh we wanted the other thing on top of that.’ ‘Well, you can’t have that, because it’s finished.’ So just like Liam said earlier, you know, how we iterate, we do, we deliver first, and then we iterate and then we iterate, and then we iterate, and then we iterate, never ending until we’ve finally filled out, or saturated, the functionality which the user needs. So the strategy really is delivery. And we’ve started to see that this actually has some effects, this approach. I guess the most important one is on - actually, I’ll give you this, I’ll skip through this basically, but this is basically the GDS Alpha-Beta-Live continuum, with our 20-week timebox on top. But this is something which you’ve got to see all over the place, this is kind of how we do business.
And if you look at one of the exemplars, Civil Claims, this is why it’s important to think this way. If you look at this exemplar here, you notice that this is a huge number of different end-points, of different parties: there’s defendants, there’s claimants, there’s lawyers, there’s all different kinds of claims you can possibly be making, there’s lots of different forms for these different kinds of claims, each of which follow a different kind of workflow, and so on and so forth. So if you’re thinking, as a young product manager coming in from the outside, that you have to do a total service transformation on this, where do you start? And when do you know you’re done? Because this is a really big picture. And that’s exactly what they were looking at, and that’s what people couldn’t figure out how to do, and that’s why people were starting to freak out, and that’s why we had to rate everything red.
So then we said, ‘What you’re going to do instead, is you’re going to find a thing, and it’s going to be this thing here, because that thing does deliver concrete value. We’ve done the user research, we do understand it, there are lots of problems with this particular thing, we know we can deliver this in twenty weeks, and we’re going to deliver that, and after we’ve delivered that, we’ll [gesturing at slide] deliver that, and then we’ll deliver that, and then we’ll deliver that. That way, the business know that we are serious about iteration, that way we apply the user research to how we prioritise things, that way we deliver value to the citizens very quickly, and no longer use long timeframes. And the result of that is, we went from not having any exemplars that we even thought were going to be able to be delivered live by March, to having three of the government’s six exemplars live today, which is - we’re very proud of that actually. I mean, we have to say - I think I have the best team that I’ve ever worked with in my life, and I’m not joking about that. But we would never have been able to do that if we hadn’t been applying some very severe discipline to the work we do. So I guess that’s one thing I really want to get across, major lesson that I learned here, learned it very quickly, but I think it’s something which pretty much every time that I’ve been working with in other departments probably should be thinking seriously about.
Another one is, when we deal - when we’ve been developing digital services thus far - and by the way, I’m this Chief Digital Officer, not this Chief Technology Officer - when we deliver digital services thus far, we’ve been basically stuck in a mode - sort of an IT-ish kind of a mind, where, you know, we get these things called ‘Requirements,’ which come from executive agencies. Executive agencies are executing policy, which has already been developed by somebody else. So they’re already sort of down the sausage factory. And what we’ve been finding is that we’re on the one hand talking about user-centred design, talking about user-focussed when we deliver our services, and yet we also have all this old legislation, we have all this old policy, we have all this old procedures, old systems, old habits, old culture, whatever you want to call it - lots of accretions of these things, which are constraints, which are massive constraints, because they’re the things that tell you, ‘You can’t do this, you can’t do that, you can’t do the third thing’. And it’s all taken as a given, right? So that’s just the way it is. So then we come and say, ‘Oh yeah, but we do user-centred design, you know? We do user research. We’ve focused on what the user needs, not what the government needs.’ And I think there’s a real contradiction between these two things here, have to say it. And I think if you are working in digital, and you’re spending your time with your main interlocutor in the executive agencies, you’re missing a trick. And that is very simple: that you should be working from the very beginning with your policy colleagues, because many of the things which you think actually are problems, or can’t be solved, can be. We found that out in the case of Civil Claims, when we found it - you know, we were delivering a service which, at least on paper, I suppose, in some ways, was acceptable, was an acceptable service, but actually, when we gave it to users, we found out, you know - the videos are amazing, guys saying, you know, ‘I can’t figure this form out. What are you trying to tell me? You know, what do I need to do?’ Because you needed to have a lawyer to fill this thing out, with you, to do that. Which meant, what kind of digital service is that, you know? Again, Amazon does not require you to have a solicitor sitting by you when you want to buy a book. Why are we doing the same thing? The reason we’re doing that is because the services are so rotten, in some ways, right?
The way we got around that was, instead of getting endless back-and-forths with an executive agency on this, we talked to judges, and we talked to policy colleagues, because they’re the ones that made decisions on this kind of stuff. And we said, ‘Gee, guys, does this really make sense? Isn’t there some other way that we could be presenting this stuff to the users, such that we can redesign what we deliver. And we did, and now we have something which we’re very very proud, which we think is really great. We’ve discovered this pretty much across the board, that whenever we are in this kind of a problem, that our initial response, which had been to talk directly with ‘the business,’ has almost always been wrong, and that we need to be talking with policy colleagues right from the very beginning.
I think there’s a larger lesson too, which is that if you look at what policy people do, and if you look at what service designers do, they’re very very very similar kind of work. And one of the things which we’re trying to do now is to dissolve some of the boundaries between those two, and we’re setting up the policy lab inside of MoJ, inside of digital, so we can do that, so that the next generation of digital services will be miles ahead of where they are now.
So this is our program. We have a lot of stuff. So we have four exemplars, and we’ve also got like sixteen other projects we’re working on, almost all of which are the same size and scale of an exemplar, so we’re doing an awful lot of work here. And the team right now is about 135 people, so I think we’re the largest digital department outside of GDS in government. And it spans the breadth of pretty much everything that the MoJ does, it spans all of our executive agencies, it spans many of our ALBs, it goes into HQ, we’re starting to deliver services that are HQ kind of services which could be spread across other government departments, so, you know, Liam has already mentioned earlier, you know, sharing stuff, not only public stuff, but also stuff that’s internal. And one of the things which, of course, when you look at this list, you realise there’s an awful lot of points of integration with existing legacy, and with existing technology. So another lesson, and this is I think, another one which we learned, although we learned this one pretty quickly, is that there is so much to do, you know, we need to have a division of labour between digital, between technology, and between the line of business, if you want to call it that, the executive agency, the business. And the way we’ve done it within MoJ is pretty much following the standard quadrant, which Liam has put out there. But we’ve actually implemented it, which I guess makes it a bit - a good thing. And so, from our perspective, digital is all about public-facing services, and also the internal-facing services. If a user uses it, then it’s designed and developed with the same care and ethos as something which you would design for the public. It doesn’t matter if it’s a public user, or an inside user. We don’t say that inside users don’t count, because inside users are doing their work to serve the public. If they’re not, they shouldn’t be there.
And infrastructure, all that stuff actually has to run on, is the work of my colleague, Ian Sayers, the CTO. We work very very closely with each other. And between the two of us, we also work very closely with the lines of business. Now, in the case of the MoJ, we’re going to wind up pushing digital inside different agencies, so [gesturing at slide] these things become more and more digital here. Digital starts moving into the business app space.
And then the last big lesson - nearing the end - and this is one which I think is incredibly important - is that you’re absolutely nowhere if you don’t have your own in-house capability. I’ve seen a lot of other government departments try to figure out how to do the digital stuff, how to roll out their services, or they’ve even been able to develop the digital services, but not much on how to maintain them. You have to have your own in-house capability, and that cannot be just portfolio team, or just a strategy team, or just something like that. You have to have the ability to deliver. You have to have your own development team, you have to have your own designers, your own researchers, your own product managers. You absolutely must. If when - if the MoJ had not had that when I came in, there would have been nothing. They would not have been able to deliver, not have been able to deliver. It just would not have worked. And I think that that, you know, that has been absolutely essential to our being successful. At this point, we’re looking to see how we can potentially - maybe even potentially help other government departments, help them build up their own delivery capabilities. But you must have that, you absolutely must have that. And part of what we had to do to get there was build our own recruitment team, because MoJ themselves, their own HR function, they really weren’t able to handle that. They didn’t know how to deal with this kind of stuff. We had to bring in other people ourselves. But now, we’re at the point where we’re saying, ‘Well, great, yeah, there’s a central team, but guess what? Inside each executive agency, we’re going to start embedding people directly inside there as well,’ so digital will become everywhere in the MoJ. It’s no longer the province of a team that is sitting in a tower.
And last thing - so I had four things I learned, and there are still four things which continue to bedevil me. And I’m just going to throw these out there. Because one obviously is properly defining the MVPs, because it’s really easy to say, ‘Yeah, just choose an MVP,’ but actually, it’s not that easy, because the decision you make there is going to affect the evolution of the service going forward. So you really need to be very careful about that, and you need - I think you need to spend a lot of time on that. If there’s one thing you spend time on, you probably should be spending time on that. Another huge issue for us is legacy systems and contracts. You know, what we’re trying to figure out now is, ‘How do we either unpick the contracts, or how do we obviate them, by just replacing the systems?’ But that’s a very radical move, and it’s a very expensive move, and it’s a move that takes a lot of time. But it’s a real problem.
Civil service timelines are glacial; we all know that. So you have to plough through that. And service redesign - one thing which we noticed when I came in, or one thing which was sort of bedeviling out time for a while was the idea that what we were doing was just a digital service, and that assisted digital was something completely different to that. And I think that was a real misunderstanding on the part of the team. The service redesign is not just a digital service, it’s the whole process, digital being one of the channels of that. I think any team needs to think about that as well.
Anyways, that’s it from me - the things I learned.