How to transform

The failure rates in transformation are so well known, they are not worth repeating. We have a very simple explanation for it. As you move to a more agile way of working, you need to use agile techniques to get there.

However, most transformations are designed, planned and executed using the very techniques companies are anxiously trying to get away from.

This transformation paradox must account for a good deal of failure. It might not sound obvious why but in our practice we see a number of reasons:

The impact of false assumptions

Most executive teams and their advisors can’t really predict what changes they need to make. Transformation programs are often based on very big assumptions that will create their own unintended consequences.

The types of assumptions might be:

  • We would be better working with smaller companies
  • Or a recurring revenue stream would be better for our business
  • Or a single view of the customer will support much better marketing capabilities.

Why would these assumptions potentially turn out to be a source of failure?

  • Large enterprises take years to learn how to work with smaller companies and are frustrated in the process by small firm behaviour and by complex procurement procedures
  • Recurring revenue streams often require you to have a community building capability and that, in turn, requires a content creation capability (reviews, user self-service, profiles etc). Very few companies plan to switch their relationship with customers by investing in community.
  • Single view of the customer programs normally involve a huge investment in data normalisation and push value out by years, so yes, good idea but costly and time-consuming.

Added into this is the fact that IT infrastructure and services will in most cases be a tangle of legacy and modern web front end technology. They won’t be fit for purpose and a large part of a transformation budget can be swallowed up by unanticipated workflow problems.

Additional problems occur because of 12 monthly budget cycles (everybody bidding to keep their part of a program going regardless of its value), the introduction of contractor teams on much higher pay compared to job insecurity for employees, the implementation imperative creating a micromanagement4 environment to ensure deadlines are met4, even when the deliverable has low value and so on.

Scale down to skill up

The only sensible way to transform is to shake off these assumptions and learn what your company actually needs, through experience.

In the Flow approach, we scale big programs back through our lighthouse projects and we use those to create a learning environment.

The transformation sprint is a technique for time-boxing different aspect of a transformation (design, planning, execution points). It introduces the values of agility: quick delivery, early and frequent realisation of value, embedding new ways to work, all in the context of a project that has a strong structural impact (see here).

The downside is that executives need to acknowledge the big program problem and agree to taking smaller steps.

That flies in the face of their “perks of seniority”, i.e. green-lighting big projects with budgets that reflect their status. The counter to this is that4 most executives who participate in transformations will fail. However well this is disguised, the failure is real and a career threat. Far better to act incrementally.

All of this is not to deny that some transformations work well. Generally, the successful ones have a strong IT dependence and dynamic IT management skills.

We have also seen good change programs where they have excellent role models in world-beaters like Amazon (and a strong sense of urgency). By and large, though, change is best addressed as a learning program and therefore best-paced by how well and how fast you learn.