Implementing Multi-Modal Change Delivery

Digital transformation is upon us, whatever that means. Most of us will have a view of what this means for our business, and we may even have a clear digital strategy. But how many of us are confident in how we are going to deliver this digital transformation?

The context

We know we need to be more agile. Many of us may even be clear on the specific reasons why this is important for our business*. But it’s easy to get lost in all the hype. Amongst all the noise there are some hard truths that we all need to understand.

The company that is more agile will be able to respond faster to opportunities and threats in the marketplace and therefore beat the competition.

If you don’t become more agile, your customers will move onto someone who is. The road to agility can be initiated by shorter change lead times and more frequent “commit points”, but there’s no easy short cut on this journey.

In the charge towards greater agility, you still have to deal with highly sensitive customer data and provide those mission-critical services, which will put you on the 10 o’clock news if they go wrong. In these sort of situations, stability and predictability remain much more important than speed or agility.

When you think about the needs and characteristics of different initiatives, it becomes clear that a one-size-fits-all approach to change delivery is not fit for purpose. It never has been, and it’s never been more important to understand and address this.

It’s time get on the front foot by setting out an operating model that allows for multiple ways of working to co-exist. An operating model that provides a much more efficient, “multi-modal” approach to delivering change.

What is multi-modal delivery?

Let’s start with an assumption. You wouldn’t use a train to go down to the local shops, and you wouldn’t cycle from London to Manchester for a meeting – right? You’d use the best vehicle for the particular situation. This is analogous to multi-modal:

“The ability to deliver change via a discrete set of different delivery vehicles, with the choice of vehicle dependent on the characteristics of the type of change being delivered”

A delivery vehicle may have sequential or iterative regular releases, standalone waterfall programmes, or something else. It’s also worth considering IT Service Requests in the mix here too.

The goal of multi-modal is to deliver high volumes of concurrent change in the fastest, most efficient way possible, by using the right vehicle for the job.


We shared an article recently that sets out what you can do if you want to be more Agile.

Horses for courses

It’s quite common to hear of businesses rolling out Agile across the enterprise.

In the most successful examples, the key achievement is the implementation (or re-implementation) of those delivery disciplines that are actually common to all methods:

  • clear accountabilities,
  • a common vocabulary,
  • unified sense of purpose across the business and change teams.

But not everything is suited to Agile. The same is true with Waterfall and any other specific method. The question to ask yourself is – is a one-size-fits-all model actually right for you? In most cases, it’s not.

In reality, multi-modal is often happening under our noses – unofficially. For example, the digital marketing team aren’t likely to be following a sequential approach to make content changes on your website.

At the same time, it would take a big leap of faith in most companies to deliver a new billing or payment system using Agile, where getting it right first time is pretty critical.

What’s needed is a defined set of delivery vehicles, and a clear set of criteria for when to use each one. The key point is – some things are better shaped and designed up-front, some things can be added to, whilst other things are better if they are iterated over time.

multi-model-diagramThere’s also a place to be found for innovation and user-owned change. Other characteristics to consider when choosing between delivery vehicles may include:

  • Target time to market
  • Cost of delayed start
  • Clarity of intended outcome
  • Enhancement vs “new build”
  • Complexity
  • Level of integration
  • Level of data risk
  • Level of security risk
  • Level of impact on operational functions
  • Familiarity with the technology.
Making it work

It’s relatively easy to come up with a set of criteria for choosing which methodology to use, but how do you make it happen?

First, there’s a need for a triage process during the mobilisation phase of any piece of work. This doesn’t have to be a lengthy, onerous or even centralised exercise.

It does need a clear and conscious decision at the point of commitment, that the characteristics of the change are understood and the right vehicle chosen. This will be much easier if you’re running a continuous demand process.

Next, your business needs to be equipped to deliver in different ways. This article isn’t going to go into the detail of method, but there are three key things to be on top of:

  1. Set out the operating model to give unambiguous accountabilities
  2. Don’t get distracted by method, focus on smoothing the points of intersection (where multiple changes have to come together – eg, release slots, user roll-out)
  3. Drive a consistent mentality, regardless of method – discipline, trust, pragmatism are good places to start

A side note, whilst your existing change delivery function will likely handle the bulk of change via sequential, incremental and iterative approaches, it’s also important to set out criteria for where stuff doesn’t go via the Change function.

For instance, end user computing and innovation labs are usually also valid delivery vehicles for certain change types.

Optimise your delivery vehicles

Once you’ve got the ability to deliver change via the most appropriate vehicle, then it’s all about continuous improvement.

Challenge teams to reduce cycle times for complex change. Lean is an over-used phrase, but it’s common sense to apply when you’re looking to optimise what you do.

If you’re looking to reduce your time to market, work out where the elapsed time savings can be found, and remove the blockers.

Challenge why different changes need to be bundled together. Historically, this has often been to drive economies of scale in areas such as testing, and to batch together changes to process. This is a dependency that automation can often remove. IT environments are often another bottleneck, one that Cloud or Software as a service products can help alleviate.

Continuously seek to move more change types out of sequential and into incremental or iterative, in a managed fashion.

Foundational change such as new systems or a new organisation often need an initial sequential approach, but can then be changed incrementally in the future.

Encourage business users to build a backlog. Small change can often be delivered extremely quickly, if it’s not stuck in the same change queue as large, complex change.

Continuously manage demand vs. supply

Managing the pipeline of change is a mix of art and science. The goal is to be able to frequently and iteratively plan, refine and build confidence in delivery plans, and to prioritise effectively and transparently with your business teams.

Prioritisation should balance demand with available supply of resources (people, systems, release slots, end-user capacity to absorb the change). This is a topic in its own right. The key point to make here, is that having several vehicles makes it easier. There is then more opportunity to delegate the prioritisation to the people who actually understand the change and its relative importance.

In summary

All businesses have the opportunity to gain real competitive advantage from new technologies and ways of working. Making this work in practice can be hard, especially as it can involve wholesale changes to your existing operating model. It is worthwhile. The businesses that succeed are those that take a holistic, structured approach, and see through the changes required.

If the above points resonate with you, why not get in touch?

POSTED BY: David Knappett - Consulting Director


View the author's team profile page

Get in touch