The best definition I’ve seen is in the recent (and recommended) “Digital Transformation at Scale” book, which says:

A successful digital transformation makes it possible not only to deliver products and services that are simpler, cheaper and better, but for the organisation as a whole to operate effectively in the online era.”

I like this definition because it makes two clear distinctions:

1. It doesn’t say that the services or products are entirely digital; merely that a digital transformation will affect them. It is possible that an end-to-end service will include both digital and non-digital steps. [1]
2. An organisation cannot “operate effectively in the online era” if only 2% of the organisation changes. In this definition, a digital transformation isn’t a bolt-on activity that happens in one corner or in one silo; it has to impact the whole organisation.

What do you need for a successful digital transformation?

Different organisations present different challenges, but I believe you need a focus on four areas no matter where you’re working. These are:

1. user needs;
2. iteration;
3. standards;
4. culture.

I’m going to cover each of these briefly below.

1. User needs

Far too many transformation programmes either forget to start here or get blown off course. The user need that your service meets (or will meet) is the north star of your transformation. In the words of 18f; “change is more important than the tech” and focusing on user needs ensures that you don’t forget this.

The distinction between a user need and a user want is critical. Anchoring your transformation to a user want is equivalent to taking a compass bearing on a sheep on a cloudy day: it’ll keep moving around causing you to get lost, fed-up, disorientated and quite possibly stuck somewhere that you can’t easily get out of [2].

Whether your users are internal or external, anchoring your changes to their needs is also, in my experience, the single biggest driver of change. Place a service team in a room and get them to watch real users wrestling with your service. I guarantee that this will generate more energy to change things than a month of motivational speeches from senior stakeholders.

This is even the case in teams suspicious of input from outsiders. The single biggest impact I’ve  had on a transactional government service came about as a result of a user research session I set up despite some cynicism. The session generated  insight that was good enough to persuade the team to set up and maintain a programme of user research long after I’d left.

In the wise words of Simon Wilson, “If you are not doing for and with the people who will use your thing(s) it’s not digital transformation“.

2. Iteration

You try something new, you start small, you scale up. You put a working prototype in the hands of real users” – Scott Brison, Canada’s Minister of Digital Government

Every problem that I’ve seen with a beta or live government service can be traced back to an issue from the discovery or alpha stage. The ability to experiment, prototype, get things wrong and change them quickly is crucial to the success of any service with digital elements at any stage, but the repercussions of not doing this at the early stages are particularly nasty.

Transformation programmes often forget this in their rush to create a masterplan that can deliver results. And creating that masterplan can suck up all of the energy for transformation before it starts. I’ve sometimes felt that the longer the workshops set up to discuss the transformation, the less likely the transformation effort has of succeeding. There’s a useful metaphor in “Digital Transformation at Scale“:

One of the biggest mistakes we have seen new digital institutions make is waiting until they can see the very bottom of the pool before diving in from the highest board. Taking a shallow dive into murkier waters is the wiser way to go. Digital teams should feel comfortable (or at least, get used to feeling uncomfortable) with working things out as they go along”.

I’m fond of saying that agile approaches should apply to the iteration of both products and the processes you use to create the products [3]. I think it’s the same with the larger canvas of transformation programmes.

You’re not going to come up with a perfect plan, the chance that someone else’s perfect plan will fit your organisation is small, and the chance that you’ll be successful at your first attempt of designing your organisational approach to something that is, by definition, at least partially unknown: that’s, well, unlikely.

Instead, aim for a transformation effort that also iterates alongside the services and products it delivers to users. You will need an agreed approach to this iteration and a way of ensuring that everyone involved understands the results. If you don’t do this, you run the risk of the organisation circling rather than iterating and attempting to succeed by repeatedly trying the same approach. This is an approach that always reminds me of the clip below.

3. Standards

A service standard is a list of things that a team designing and running a digital service needs to be and needs to do.” – Digital Transformation at Scale

Because transformation is disruptional, it can be difficult to show what you’ve delivered using existing metrics and reporting mechanisms. Somehow, you need to measure progress and provide assurance. More importantly, you need to show how you’re measuring progress and providing assurance whilst modelling transparency and showing that you’re not marking your own homework.

The way to do this is to publish a standard that is used to assess progress, or commit yourself to using one already in existence.

The authors of “Digital Transformation at Scale” admit that no-one asked them to create a standard and that they could just have made decisions on what went onto GOV.UK: “Codifying a service standard was as much to protect the GDS from itself as it was to help the rest of the organisation”. A standard will keep you on track as well as give you a yardstick to measure against.

4. Culture

Reasons why digital projects fail:
1) lack of leadership
2) organisational inertia
Never underestimate the amount of damage an organisation will do to itself to stop things from changing.

— Dafydd Vaughan (@dafyddbach) September 26, 2018

Turns out Machiavelli knew a thing or two about digital transformation…#nux pic.twitter.com/xSJq0fNnOU

— Sophie Dennis (@sophiedennis) September 24, 2018

Institutions will try to preserve the solution to which they are the solution” – Kevin Kelly

Whatever your transformation is and however it runs, the only element that can completely prevent it from succeeding is the people involved. Culture is the most important and least discussed element of transformation.

If you want to make transformation happen and make it stick, you need to be radical in changing how your organisation works, but incremental in changing what it delivers – Mike Bracken

Practically, leadership needs to provide psychological safety in order for people to be willing to fail and try again, to listen to users and not take bad feedback as personal criticism and to adopt new ways of understanding success and failure. It’s not enough to coach people in new ways of working, or to tell them or train them: leadership has to model it, and show that it’s valid.

Leadership is important but successful transformation isn’t imposed from the top. Different organisations will start in different places, but transformation needs engagement to happen among and not to an organisation. As Catherine Howe and David Carboni say; “successful change is negotiated and not imposed” and “collaboration is more powerful than control“.

The best way to ensure that the wider organisation can see this and become involved is transparent communication. Comms in a transformation scenario should never be a bolt-on activity, where a specialist observes and writes it up; it’s an activity that the whole team engages in. Good, transparent communication that talks equally about the highs and the lows is the best measure of team health in transformation programmes.[4]

Transforming Services (Digitally)?

A lot of people have suggested that “digital transformation” as a term is now tired and meaningless, a victim of a thousand wrongful interpretations and ripe for replacement. I’m not sure about that. For a start, I hated its predecessor, “change management”, a whole lot more (being a “change manager” made me sound like a sheepdog rounding up the masses against their better will, as though people couldn’t manage change themselves without someone to do it to them). Beyond that, I think that at least some of what I’ve described above is useful and possibly unavoidable.

What matters most is teams focused on users delivering iteratively in small, incremental improvements, failing fast, constantly planning for the future and learning about how to improve how the team works together” – Digital Transformation at Scale

My issue with “digital transformation” is that “transformation” suggests that there is a bounded programme of activities. True transformation isn’t restricted to one part of an organisation, or a timescale, or a plan. It’s organic and ongoing and surprising. I’d like to recognise this grammatically by changing “transformation” to “transforming”. [5]

The change that seems likely in time is that we move from “digital transformation” to “service transformation” to reflect that we transform entire services, including digital and non-digital parts. I agree with that, but the potential for waterfall approaches creeping in at the back door and insisting that we understand and plan the entire service before we start worries me. We should transform whole services but we’ve got to start somewhere. The digital part seems like a good place to start to me. Transforming Services (Digitally): I’ll sign up to that.

[1] See Tom Loosemore’s post on “Assisted Digital” for one recent reflection on approaches to service design.

[2] Gratuitous inclusion of my favourite film clip involving sheep follows, complete with original Aphex Twin soundtrack.

[3] That is why the planning session and the retrospective are equally important and I get annoyed with you if you suggest postponing one and not the other.

[4] After I’d written this draft, I read the Tim Harford article in the FT that says almost everything you could want to say in this section better than I can (also, it includes tanks):

"the reality of disruption is less elegant"

"Dominant organisations are prone to stumble when the new technology requires a new organisational structure." https://t.co/yM7avta8LN

— Matt Knight (@mattinwales) September 10, 2018

[5] As people who worked with me when I was a Transformation Manager will tell you, I always preferred the idea of “Transforming Manager”.