5 key elements of a Digital Transformation

Having been involved in a number of “Digital Transformations” I’ve observed some useful patterns of both failure and success that you might want to consider.

I hesitate to use the term “Digital Transformation” because isn’t very well defined. It has also been somewhat abused, much like “Agile Transformation” that came before it. Nevertheless, there are many organisations who are attempting to change not just how they work (i.e. an Agile Transformation), but also what they do and how they do it. Like it or not, the way organisations serve new and existing customers is changing. For want of a better term, this is what I understand a Digital Transformation to be.

The need to change often comes because of some perceived threat and/or opportunity. Over the last decade I have been closely involved in lots of different organisations who have been attempting to change because of these pressures.  Along the way, I’ve seen some patterns of what works and what is often missing or slows the whole thing down, so I thought it worth sharing some of that here.

1. Focus on customer, not technology

Customers really don’t care if the technology behind the scenes is .Net or Java or some other flavour of technology. They also don’t care if it requires “re-platforming” or customisation of some Commercial Off The Shelf system. Honestly, customers just don’t care – and why should they? Any Digital Transformation that is primarily about the technology will almost certainly fail. Focus on the customer, not the tech.

Also, be careful not to be a slaves to your existing customer base either. New, more simple (and cheaper) approaches –maybe even with less functionality than you currently have– can mean you tap into a much larger market than your current “fully featured” product serves. In particular, be extremely wary of any organisation that defines their “MVP” as “everything the current product does”. Not only is this a massive abuse of the term MVP, it’s also a great way of making the batch size so big that the organisation runs out of money and/or patience before killing the whole thing.

To combat this, become an expert about the Job To Be Done and let that guide your decision-making – not the technology. MVP’s are about learning quickly, not limiting scope in order to ship an “inferior” product. The paradox here is to be both humble enough to let the market decide, while also becoming a expert in the problems that customers have today and that they hire your product for. You have to be open to exploring new business models that technology and new ways of working can enable. If there was a higher-order-bit for product development, I think this would be it.

2. Teams and Products (not projects)

At a lower, implementation level, the way you approach change needs to fundamentally change. This doesn’t have to be an overnight change – start where you are. But if you aren’t prepared to sacrifice some of the sacred cows of the way you work today then your Digital Transformation will likely fail.

The best way I can put my finger on this is that the current vehicle for delivering change in organisations is ill-suited to products and services that are delivered using the zeros and ones of software (and therefore “digital” in nature). The alternative is not big batch, project-focused change, but more about teams and products, focused on stability of those teams, flow and faster end-to-end learning about what works and what doesn’t. I could wax lyrical about this, but really, you should just go a read Don Reinertsen’s Blue Book. Some find it a hard slog to read, but take it in bite-sized chunks. The first chapter alone should give you a bunch of ideas about what you might start experimenting with.

3. Discovery, not requirements

Now we are drilling into the early stages of “the way things work”. If you don’t start changing the language here you’re probably not going to get very far with your Digital Transformation. The last mile of delivering change has already seen a massive change, with the adoption of Continuous Integration and Continuous Delivery breaking down the batch size from the whole project to even lower than individual lines of code. (If you don’t know what CI and CD means, then you may want to start there – this isn’t even controversial these days.

The revolution that is yet to happen is at the beginning of the process. If your technology teams still refer to “the business” as some separate part of the org, then your Digital Transformation will quickly find a local maximum and stall. If you have “the business” (even in the form of Product Owners) giving orders that technology teams “deliver” you’re also going to struggle. Break those silos down, work end-to-end and stop treating the work as a set of “requirements”. Digitally enabled products and services require the team to work together to discover what works and what doesn’t.

4. Speed and agility, not predictability

Not much to say on this that hasn’t already been said by others much more qualified and experienced than me. What I have noticed though is that larger organisations seem to be optimising for predictability. When I’m speaking with C-Level execs about the changes they want to see I like to ask them a simple question, which has proven to be a pretty good leading indicator for whether their Digital Transformation will fail or not:

Which would you like to optimise for a) Predictability, b) Throughput or c) Speed?

If they answer a) Predictability, then I’d recommend you make your excuses and leave them to it. It’s unlikely to succeed. Before you go though, you may want to share why.

Unfortunately, in the product development context, if you optimise for predictability you tend to get neither predictability, throughput OR speed. If instead you choose to optimise for throughput, then speed tends to suffer, which means the rate of learning is too slow – but at least the predictability will improve, assuming they also adopt some simple forecasting techniques. If you optimise for end-to-end speed, however, you will typically find that not only does cycle time reduce, but throughput often also increases and predictability is paradoxically much improved. You can read a good case study of this here

What this means is that you have to change the way your PMO functions, what it measures and how it reports. Project plans and dates need to become forecasts, not commitments, and costs will be managed in a far more visible and accurate way – but not on the basis of a spurious aggregation of estimates done at the lowest level after a hierarchical decomposition of the work. (More on how the PMO should work here).

I fear I’m starting to elaborate too much, so let’s move on…

5. Support from top to bottom

The most important thing for senior leaders is not so much to “lead” (and definitely not to “manage” in an old school Project Management). Far more important is for you to simply protect the space. You will need to make sure that teams are given a chance to learn and grow together, for the product itself to emerge over many many iterations and to maintain as close a direct link with real customers as you possibly can.

Critically, not everyone will get it at first, and until they do, you will need to protect the culture that you are trying to grow. The changes in mindset required will take time. You can’t just send everyone away on a sheep-dip training course and hope that everyone is aligned. Some people will have made their mark and become very good at playing the old games required to succeed on a personal level. You will need to let go of some people who can’t accept the new approach, and hire new people who are at least open to learning and willing to grow with the organisation as it changes.

I’m sure others with experience of doing this have different patterns that they have observed. We may also focus on different areas, but the above would be my top five today. What have I missed?