The One Team Government unconference was awesome. I’ll write another post about the event overall. For the time being, here’s a quick write-up of my session, in which I revisited the Gaps Model of Service Quality and how we might use it to embed #oneteam working in our organisations.

I might have done a better job of pitching my excitement about Parasuraman, Zeithaml and Berry’s seminal work from 1985, because when it came to the session, only two people turned up. But they were absolutely the best two people: thanks, Nayeema and Liam, for taking the time to talk this over with me.

I started by sticky noting the key features of the model, last cited on this blog in the post “Most of government is mostly service design most of the time. Discuss.” The authors propose that if we want to know why organisations so frequently fall short of meeting their customers’ service expectations, we should look to 5 gaps in the typical operating model where information and understanding get lost or misinterpreted. Becoming #oneteam means closing those gaps.

Nayeema, Liam and I talked though the gaps, and the tactics we might use to overcome them. As we talked, I tried to map the notes to the relevant parts of the gaps model.


These are some of the things we talked about…

Gap 1, between user expectations and organisational understanding

  • The importance of understanding the end-to-end service, which may be larger and more complex that the bit that our organisation or team delivers
  • We noted examples of departments and agencies making big service maps, for example the Ministry of Justice’s digital justice landscape
  • The rising tide of user expectations, shaped by other digital services, making user needs a moving target that demands constant re-discovery

Gap 2, between understanding users and specifications that will meet their needs

  • We talked about the value of prototypes as specification – why describe the thing when you can show it?
  • But also the danger of confusion between a “vision prototype” and a functional one – when we show an alpha, we need to be clear what we mean it to prove
  • Risk of the team’s commitment to meeting user expectations being eroded in the face of organisational reality. We need regular top-up doses of primary research to keep us connected to users

Gap 3, between what we specify and the service we deliver

  • Are a user story and an epic enough? Probably not! The team needs to communicate and use multiple methods to make sure the intent becomes reality
  • Delivery is more than just the digital thing. We need to include everyone who contributes to the user’s experience early and often, not expect operations to come in at the last minute and fill in the gaps without context
  • Is it time to kill the concept of “business as usual”?

Gap 4, between what we communicate to users, and what we deliver to them

  • Rather than saving up for a big bang reveal to users, agile teams should be telling their story a little and often
  • We need to consider when to start communicating and to whom
  • As well as end users we should consider the expectations of other actors. Frontline workers’ past experiences may make them suspicious of change, and their cynicism will be communicated to users

Gap 5, between expectations and perceptions

  • This gap is different because it’s the cumulative result of the other gaps, rather than something we can influence directly
  • If we work on a service that people use repeatedly, we have more chance to influence their perceptions through experience of the service itself
  • Services with less frequent or one-off still come with expectation – but they’re more likely to be shaped by other services than our own

I asked whether this 32-year-old model was still useful to us in 2017. The consensus: yes, but we’d need to adapt it. We would…

  • Draw the gaps model to emphasise the feedback loop to understanding
  • Look for ways to cycle faster through changing understanding, specification and delivery to meet user’s rising expectations
  • Match the pace of introducing new ideas to delivering them
  • Minimise the hand-offs by asking one team to go on the whole journey together

More follows.

Original source – Matt Edgar writes here

Comments closed