Category: digital

DDAT or D:DDAT?

Photo by Amélie Mourichon on Unsplash

Just a quick post on a rather semantical topic!

The phrase DDAT – standing for digital, design and technology – has become a commonly adopted bit of industry jargon in government circles, to describe the work that people do in this thing we call digital.

However, I find it just doesn’t quite work for me, and I think it is because of the use of the word digital within it. I think in the definition, digital is meant to cover things like user centredness, service design, digital culture and so on – but this isn’t terribly clear.

So, I have found myself on occasion instead referring to digital: design, data and technology. I’ve never abbreviated it, but I suppose that if I did it would be D:DDAT.

For me, D:DDAT gets across the idea that ‘digital’ encompasses the use of design, data and technology rather than being separate from the latter two.

This hardly matters in the grand scheme of things, but I thought it worth sharing! 🤷‍♂️

Just what is a digital operating model?

This was originally published as the lead article in my weekly email newsletter. If you’d like to get more of this sort of thing on a regular basis, sign up!

jeshoots-com-632498-unsplash

I’m sure folk get bored of people like me banging on about digital transformation being more than web forms, or fancy integrations with back office systems. “It’s about fundamentally redesigning your operating mode for the internet age!” I bellow. “What on earth does that actually mean?” thinks everyone to themselves.

Coming up with a digital age operating model for a service means redesigning it in the knowledge that the majority of your service users, and colleagues that deliver the service, have access to internet enabled devices. It means mapping your value chain, identifying all the components that make up a service, and removing any elements that could feasibly be replaced by networked computing capabilities.

That probably makes no sense. Think of it this way: a lot of the value add for services as they are currently delivered involves some kind of intermediary performing a role – linking people up, checking things, making decisions about things. In many (not all, of course!) cases, these days activities such as these can be done by software, connected to the internet, that users and service providers can both access, whether through the phone in their pocket or the corporate laptop on their desk (or lap).

Here’s an example. It’s a somewhat trite one, and over simplified, but has the benefit of being comprehensible. To book a cab, traditionally, one phoned the cab company (where you got the number from is another story, but not an irrelevant one), where someone took details of you and your journey, and they then got in touch with the cab drivers to find who was free and nearby, and then they made their way towards you while you hang around waiting, and hoping. Oh, and you needed to go to the cashpoint so you could pay – and might not know how much til you reach your destination.

Now, in recent times, cab companies have done stuff to reduce some of the friction in this process by enabling online bookings, booking via an app, SMS notifications of likely arrival times, and so on. All these are examples of digital efficiency, not transformation. The service remains essentially the same, and the intermediaries retain their role.

Uber, however, disrupted this by starting from scratch, assuming that everyone (passengers and drivers) have phones with internet connections, apps and GPS. Users can now log the journey they want to make on their phone, and see themselves the drivers available to them, and choose the one they want based on a number of criteria (feedback ratings for the driver, the type of car they drive, how nearby they are etc). Users also know the prices, their payments are handled online with no cash changing hands, and they can track their driver’s progress as they make their way to them. Afterwards they can rate their driver and also receive feedback on how they conduct themselves.

In this way, Uber has removed a whole section of the value chain (the cab dispatcher role) in such a way that makes the whole process both more efficient and delivers a far better user experience, because it takes as a core assumption the fact that the internet and smartphones exist.

So to apply this to a public service, first map your value chain. Identify those areas where you are just providing an intermediary role, which could be replaced by an internet enabled service, that adds little value and just slows things down. Design those roles out of the process, then assemble the tech needed to deliver the new services.

Too often transformation processes skip the value chain mapping element. This leads to fundamental misunderstandings about what benefits services actually deliver to users, and thus miss huge opportunities to improve user experiences and reducing the cost of service delivery. As I have said before, there’s no shortcut around truly understanding the service you are meant to be delivering.

Remember – you can get things like this every Monday by email if you sign up to Digital Digest.

Photo by JESHOOTS.COM on Unsplash

Buying new software won’t save you money

This was originally published as the lead article in my weekly email newsletter. If you’d like to get more of this sort of thing on a regular basis, sign up!

Most of the stories about what organisations are doing on digital transformation tend to get published in the form of case studies, and most of those case studies are written and published by vendors of either technology products or services.

That’s fine, but I do tend to get slightly grumpy with them as they focus so much on the purchase of the technology and what it might deliver in terms of better and cheaper services. “Council X to save £300m by investing in the Norpita customer experience platform” – that sort of thing.

Partly the issue is the jumping ahead nature – none of those savings have been realised yet, no software implemented, no services redesigned. All that’s happened is that a purchase order has been approved.

But mostly, it’s because it leaves the impression that the technology is the panacea, that buying the tools delivers the outcomes. Also that this is a quick process, which it isn’t.

First, implementing new systems is hard and takes much longer than anybody cares to admit. Second, the real benefits can only come when radically redesigning the way a service runs, and that takes even longer – particularly as you’ll likely need several stabs at it. Thirdly, those much trumpeted savings? Don’t forget where they are coming from, which is mostly what the organisation spends on people. That means restructures, which will mean more time, and more pain.

This isn’t a reason not to do this stuff – of course not! But sometimes it’s easy to get stuck into the mindset that if we just buy this thing, everything will be ok. You might need to buy that thing to ensure everything’s ok, but you’ll also have a do a load of other stuff, which the case studies never seem to mention.

Remember – you can get things like this every Monday by email if you sign up to Digital Digest.

Photo by Taduuda on Unsplash

Do you need to buy a CRM?

I’ve been prompted by some discussions on LinkedIn to write briefly here about CRM – or customer relationship management to give it its unabbreviated title. The idea behind CRM is that an organisation can record every interaction it has with its customers, so that anyone picking up a future call can be instantly caught up with what is going on, and analysis of the data can yield clues as to where services are breaking down and need improving (“3,000 calls this morning about missed bins? Maybe we have a problem…” – ok, not that, but you get the idea).

This sounds like an eminently sensible thing to do, only in most cases it turns out that it isn’t in practice. Firstly, over the years, getting CRM systems used beyond the contact centre (whether directly or through integration with back office software) has proved very difficult, so this complete record rarely is actually complete, thus defeating the purpose. Secondly, the supposed goal of a single record for every customer is invariably brought down by data uncleanliness, the habit of creating additional records for the same customer, and a general sprawl of records where customers don’t fit into neat holes (eg issues around services delivered to households, and those to individuals that often result in a mess of customer data).

So CRM for CRM’s sake seems like a non-starter. But in the last few years I have been involved in projects that have involved implementing CRM and CRM-like systems. How can this be justified?

For me it comes down to a fairly simple process. First identify the outcome you are trying to achieve, whether as part of an individual service delivered to customers (or residents, or users, or citizens: pick your favourite) or a corporate wide thing. Then assess what capabilities are needed to make that happen (booking, reporting, case management, assessment, payments, document management etc) and then work out which of those capabilities you already possess in a reusable way, and which you need to buy. Now, if those you need to buy can be delivered in the way you need by implementing a system that calls itself a CRM, then fine, buy and implement the CRM system. But there is no capability called ‘CRM’ and no service outcome called ‘CRM implemented’.

Hence, no CRM for CRM’s sake, but by all means buy a CRM if it delivers the capabilities you need to transform your services.

Photo by Štefan Štefančík on Unsplash,

There are no digital silver bullets

In a fairly complex world, everyone yearns for a simple solution. The one thing they should do to make things better. The single solution to all their problems. Digital transformation is no different, and many of the marketers working in this space know it – that’s why they usually claim that their ‘platforms’ will deliver everything an organisation needs to change itself for the digital age.

Sometime people read a single solution into things when it isn’t there. A good example would be my post the other day talking about the uses of low code platforms. Several people got in touch questioning my assertion that it was the answer to all of local government’s problems. I replied pointing out that it wasn’t my assertion, and low code won’t fix everything. It might help for quite a few things though.

Overall, I am always very nervous of transformation programmes that have a single view of the operating model of an organisation, particularly when we are talking local government, which delivers such a bewildering array of services that it would surely be impossible to have just one way of changing and organising them all. Are there really that many similarities between running a theatre and processing benefits? Or picking up waste and community development?

Instead, part of laying the foundations of an approach to digital transformation should be developing an openness to trying new tools, techniques and technology, and an awareness of all the possibilities that are out there.

On the tools and techniques side, this means having a really good knowledge of ways of doing human centred design, innovation and delivery. Check out IDEO’s resources on this, along with the 100% Open toolkit, and of course the GDS service manual.

For technology, really consider the capabilities needed to deliver the outcome your users and your organisation want to achieve. See if you can match those to what you already have, but don’t shoe-horn them in. Think about the maturity of the capability you need: if it is really cutting edge, you may need to build it yourself (whether in-house or outsourced); for everything else there ought to be something on the market to suit. Whatever you do, don’t get bogged down trying to build silver bullets – a universal case management system for everything, or some kind of middleware utopia that makes everything talk to everything else. You’ll end up tying yourself into knots and running a huge IT programme, which is nobody’s idea of fun.

As I said, by all means re-use capabilities wherever you can. It might be that you do end up using one case management system for everything, because it works. Great! But find your way there by iteratively re-designing your way through services, matching capabilities to outcomes, and not through the implementation of a grand technology project.

So is there an operating model that can be applied to everything an organisation does? Probably not.

Is there a change process that can be applied to every service you deliver? Probably not.

Is there a technology platform that will enable you to replace every other system currently in use? Probably not.

Should you try things out, find some alignment between the outcome you want to achieve and the stuff you use to get there? Probably, yes.

Photo by Jens Lelie on Unsplash

How low (code) can you go?

There’s an increasing amount of talk in digital circles about low code. These are systems for building systems: ways of using simple drag and drop interfaces to build out workflows and databases to deliver business processes. Some low code platforms of note include Matssoft, Mendix and Outsystems amongst many. There are also a number of more traditional forms and workflow packages that market themselves as low code – whether they are or not I’m never entirely sure. Perhaps it doesn’t matter.

At Adur & Worthing, Paul introduced Matssoft. The team there has built a range of apps, including ones handling HR processes, waste services, asset management, FOI and complaints handling, and a range of housing services. There’s details on Paul’s blog, and it is a great example of how a corporate commitment to a new way of building software to deliver services can see real improvements and innovation.

One of the marketing messages many low code vendors like to trot out is that around the idea of being able to do away with developers. Having managed a rollout of low code and attempted various projects myself, I am not convinced of that. I’m reasonably tech savvy, and yet have never personally been able to build a functioning bit of software with a low  code platform. My brain just isn’t wired in the right way. Largely this is because, at a fundamental level, most low code is a front end to a database, and designing databases well is a skill, if not an art.

So I don’t think low code is a way for organisations to dispense with developers. Instead, it can change what developers do, and speed up the process of getting ideas made into working software. They are especially useful, I think, at the beginning of a transformation programme, perhaps when one is looking for some pilot projects to prototype approaches and methods. Buying handful of licences for a low code platform and churning out a few apps saves a lot of bother compared to procuring some heavy IT designed for some future model that may or may not ever happen.

Low code, in my view, is best suited as a way of quickly building out bespoke workflows that don’t fit easily into an existing line of business system or platform.

For example, most organisations are chock full of spreadsheets and databases (whether made in Access, or a Visual Basic/SQL server concoction) doing small but vital pieces of work. These are often stored in network drives and digital or IT teams may not even be aware of their existence. They also don’t have the advantage of being cloud native apps, with reduced capability when it comes to mobility, usability on a range of devices and can have a high maintenance overhead.

So overall I am a supporter of low code and encourage organisations to explore how it can help consolidate that morass of unknown Excel and Access based workflows into a more modern, usable and less risky platform. But don’t expect necessarily to be replacing big line of business systems overnight, nor saving money by reducing your developer headcount.

Photo by Helloquence on Unsplash

Language as an impediment to progress

Stefan pointed to an interesting blog post this morning on Twitter, that states that the word ‘digital’ is becoming increasingly less useful over time:

I haven’t yet come up with a better word to replace “digital”. I’ve tried a few, but they have their own problems. There’s simply too much meaning packed in for it to be captured in a single word.

This is true of the word digital, but also many other words. Transformation is another good example. And let’s not get started on ‘customer’.

The working definition of ‘digital’ that I carry around in my head is digital = change + the internet. It works for me, in my context, but of course others don’t always see things the same way.

I’ve tried other ways of breaking it down with people to understand their expectations. One was a three way split:

  1. Digital access – taking a paper or telephone based process and whacking it online with an e-form (quick to do, few benefits except a bit of convenience for web savvy users)
  2. Digital efficiency – taking that process and digitising it end to end, involving the replacement or integration with back office systems, removing unnecessary admin touch points an so on (takes longer, more difficult, but yields better results)
  3. Digital transformation – taking an entire service and rethinking it from the ground up, knowing what we know about networks and connectivity (really hard, but could ensure the relevance of that service for the next 20 years).

This too is flawed, and by it’s nature most people would always opt for the middle one.

Of course, the current fad for digital transformation is just that – what we are talking about is technology enabled change, and the approach to doing that well really hasn’t changed much in a couple of decades. Understand your service in terms of where you add value and design an operating model to suit, re-engineer your processes to work well from a customer or user’s point of view, and then choose the best technology to run that process on.

The detail may change, and the tools and techniques might differ, but it’s basically the same thing, whatever we are calling it this week. Sometimes though you have to use the buzzwords to get people to listen to you – and perhaps that isn’t such a hardship, really.

How much does your technology define what you do?

A fairly quick thought this, but one than keeps occurring to me. It feels like a self evident truth that the technology an organisation uses should follow that organisation’s purpose, and not the other way around, but I wonder how often that is actually the case?

I’d argue that for many organisations, with legacy infrastructure and applications that have been in use for many years, technology is defining the way they run.

This is because the technology locks in ways of working, the design of a service, perhaps even the entire operating model of the organisation.

I’ve been involved in many projects in the past where radical redesign of services was scuppered because the technology wasn’t flexible enough to deliver the new vision.

So while it is vital to rethink how services are delivered and how the organisation works, sometimes you need to fix the technology first to enable that change to happen.

What I’m talking about when I’m talking about government as a platform

platorm

So, a little while ago I posted about government as a platform, and mentioned three main components that matter, particularly to us at Adur and Worthing with our approach.

However, I’ve been involved in various conversations where I’ve been confused about how other people define platform thinking, which I think goes to the root of the lot of the issues around the wider digital agenda – issues brought to prominence recently in the debate following several key folk from GDS deciding to leave recently.

For me, I defer to Mark Thompson‘s thinking on a lot of this stuff, which Sean Tubbs neatly summarised with the benefit of some of his practical experience.

This piece from Thompson is required reading on the two different approaches to platform thinking, and which he – and I, as it happens – think is the right one. He characterises GDS as a ‘web agency’ – which I think is a little harsh, but gets to the heart of the debate around whether digital is more front end design than fixing the back office line-of-business IT stack (hint: a great website is lovely, but real change can’t happen until the legacy is fixed, which itself can’t be achieved without thinking more widely about how your organisation works).

Effectively the proposition is this: that digital describes not a set of specific technologies or even approaches to technology, but rather the age in which we are currently living, and the appropriate operating models for that age. It also describes the way in which an ever increasing number of our customers want to interact with organisations.

Thus digital, and the strategy for delivering on the digital opportunity that is government as a platform, is not around technology but rather rethinking how organisations work.

Technology is a convenient way to practically start delivering on government as a platform, but it is very much the start of the process. This is slightly unfortunate as it does provide the opportunity for people to put digital, and platforms, into the box marked IT project, which is a massive mistake. Platform technology without a platform operating model  will never deliver on the opportunity.

So, the key elements for me when it comes to platform thinking are:

  • capabilities not systems – instead of thinking about solving problems with a single ‘system’ (think of that word in the widest sense, not just as in an IT system) we break down requirements into generic capabilities, which can then be put together, building block style, to create the most appropriate solution to the problem at the time
  • making use of commoditised, utility-like computing – in government, we do not need to be using bespoke technology, but instead in many instances can use what the market can provide, at a much lower cost than traditional technology – which then frees up resource for the front line (which is the key bit)
  • solutions for now that don’t limit us in future – capabilities must be designed in such a way that they are not ‘hard coded’ (tech metaphor, sorry) for the way they run now, but so they can be flexible to meet future needs which may be very different
  • create and consume – the platform must be put together in such a way that both we and other organisations can make use of its capabilities, as both creators (building our own apps) and consumers (making use of what others have done)
  • disintermediation – or getting rid of the middle men. Catherine Howe spoke a lot about this a few years ago – showing her talent for prescience yet again. We’re only now really starting to see the effects of this with the likes of Uber and Airbnb cutting out bureaucracy and using the internet to directly connect people with needs with those who can meet those needs. These are true digital business models, not just slapping nicely designed front end lipstick onto legacy pigs.

This is what has been so frustrating about some recent discussions – rather than focusing on the big picture of rethinking operating models, folk go straight into IT mode and start discussing which booking system is best, or who has the payment engine everyone should be using. The concept of capabilities is grasped, but only at the level of technology, not any further.

So, at Adur and Worthing, we are at the very beginning of delivery of platform thinking and operating models. We starting, as is customary, within the domain of technology – but we are not limiting ourselves to that, and are constantly challenging our thinking to ensure we don’t continue to work in non-digital age ways outside of tech.

With technology, we build or buy capabilities that can then be used and re-used many times to deliver appropriate solutions to needs, both by us and by others, and we are also able to consume on the platform too – so if someone else has something neat we’d like to use, we can slot it into our systems. This way of working can happen with other assets, as well as tech, though – people, knowledge, skills, buildings, open spaces, vehicles – anything.

The key is to construct our organisation in such a way that all our assets are effectively capabilities that can be used in different ways by different people – and indeed so that we can bring in assets from elsewhere on the ‘platform’. Often this this supported by digital technology, but that isn’t the starting point, nor the outcome.

For example, I’ve recently been thinking about how ‘people as a platform’ might work in the local area. How can we make the most of the people who work at the Council – and their expertise and skills – as well as those who don’t work here but nonetheless might help us make things happen?

The capability here might be an effective time banking system, enabling people and organisations to trade knowledge, skills, time spent etc without the need for money to change hands  – borrowing in expertise as needed, paid for via hours donated to the wider system previously, without the need for costly administration to link people up, make the transactions and so forth.

(On a side note, how exciting would it be for such a time-trading system to work via some kind of blockchain technology, as Lloyd talks about in this post?)

Hopefully this example is useful – a non technology asset being shared across a system, (re-)usable in a number of different contexts, supported by a digital platform, built upon off-the shelf utility technology, which cuts out the need for central bureaucracy. That’s where we need to be with government as a platform.

So, to recap: digital is not about technology, and government as a platform is not about IT. It is instead a way of rethinking the operating model of an organisation to meet the current and future needs of its customers, in the digital age. The technology is an important enabler, but it is the means rather than the end.

It is not about fixing on a single solution for everything, but creating an ecosystem of innovation, where different solutions can compete to deliver the right capability needed by the people using the platform.

It is not about making everyone use computers to do everything, but instead is about making use of modern, internet enabled tech to run a sufficiently minimal back office that enables us to maintain, and potentially grow, front line delivery of what customers need (see Buurtzorg – and see if you can spot me and Mary McKenna in that video).

Hoping to have a chat about this at LocalGovCamp. Come along – it’ll be a blast.