From Tweak to Transformation: Sizing Up Business Change

We arrive at a fork in the road. Should we go left, or right?

Mostly, the answer depends on where we are going. But that is not the only concern. We need to have planned for the journey:

• Do we have enough fuel to get there?
• Will we need to stay overnight?
• And that most fundamental of all questions: will we need sandwiches?

When we are looking to improve efficiency or effectiveness in our organizations, how do we decide how deep to go? 

In my notes about Benefit Mapping (It's The Value, Stupid!) and Target Operating Models (Where Are We Going Again?) I described a couple of useful tools to use when starting a major initiative. They help to build shared clarity on the purpose of the endeavour and what the complete change for the organization might look like. This thinking is fundamental to my approach of connecting business strategy and technology roadmap to create results.

My view is that energy spent on these things up front makes decisions through the implementation stages much easier and more focussed, which ultimately translates to velocity.  When we reach those forks in the road it will be much easier to decide which way to go.

As we start to dig into these early conversations the question "How far should we go?" is likely to come up. There are likely to be more benefits the broader and more fundamental the scope of change is. But, as the scope increases, so then it becomes more difficult to manage, to deliver and for the operating organization to adopt.

We don't want to bite off more than we can chew, but we also want to shoot for the stars.

One way of thinking about this is to take our draft desired benefits and consider the amount of change required to unlock those benefits. Later, we will build a proper business case, with costs and benefits that have been scrutinized by finance analysts, but for now we are just roughing out the initial thinking.

It can be helpful to think about what we are doing across a spectrum of Value and Risk. In Risk I am including difficulty of managing, delivering and adopting the new ways of working and the capabilities to support them. So Risk includes Level of Effort on this diagram.

It is worth making a conscious decision about where we are on this curve as this will help us understand what we are really taking on, or choosing to not do.

Being intentional about that decision is the theme of this article.

Let's characterize some points on this curve and consider appropriate responses.

Technology Replacement - "Lift and Shift"

Here our program might have been triggered by something like:

• A vendor removing support for a legacy capability so we need to move to a new platform
• We are consolidating similar capabilities, perhaps to reduce TCO
• A merger so we have duplicate capabilities
• An expansion so we need to extend existing systems
• Intolerable issues in the operational environment

If it is behind-the-scenes infrastructure capability with limited end-user or customer interaction, then we could just go ahead and do the technology replacement. Here I am thinking about things like the network, server refresh, perhaps the email system, perhaps even an ERP upgrade with no business process changes.

But if we are talking about any sort of information system that implements an internal or external business process then there is more to think about. By lifting and shifting, or taking a technology-led approach, we may well be

• Missing significant business benefits available by improving processes to be more efficient, effective or customer-focussed
• Holding our business back by perpetuating suboptimal business processes into the future. We could be closing the door to organizational agility that will be critical in the future.
• Missing the impact of changes to customers and internal operations that will cause issues

A good test here is to check whether any internal or external processes are impacted and to see if there are benefits to be gained or future risk to be avoided by doing more than a pure technology replacement.

I would venture that most systems that have a process running through them would benefit from taking more of an evolutionary or transformational approach.

Evolution - Process and Technology

Our program might be triggered by something like

• Any of the technology triggers, but on examination there is a need or desire to redesign a business process
• Regulatory change
• New market
• Reorganization
• Competition
• Desire for efficiency
• Desire to be more effective

Examples might include

• Expenses solution - rapidity and convenience of submission and payment. Options for automation for faster throughput at lower cost with greater compliance.
• Incorporating new business processes from acquisitions or start-up BUs
• Process adjustments to address new annual priorities
• Company website update - opportunity to consider what it is for and what customer channels it serves... but this might start to creep into more of transformation if the aperture is opened very wide
  
  

For these sorts of efforts be prepared to map out current and future business processes, which need to involve the organizations who do the operational work. Be alert to what is changing and attitudes to that change. At the very least we will need to invest in training on the new process, but it is likely we will also need to pay attention to understanding resistance and helping the team to change.

If we are changing a customer-facing process then be very careful to assess customer perception early in the life cycle and adjust/proceed in the light of that knowledge.

Sometimes we will be making changes that won't be popular. That is ok, we just don't want to be surprised. Be forearmed and proactively set the stage for such changes.

Transformation

All the reasons already mentioned might be the trigger for a transformation program, with perhaps the market and regulatory conditions being first and foremost. Innovation comes up: an opportunity that cannot be ignored.

Examples might include:

• Moving from a product to an as-service company
• Merging multiple business units to use shared horizontal services
• Responding to regulatory changes that are significant, so focusing on customer centricity while changing
• Moving from a product to a consulting sales approach
• Launching an online portal which redefines customer engagement expectations

Key here is to be intentional about planning and resourcing the effort by understanding the difference between a transformation and evolutionary program.

A transformation program is a significant undertaking. It will place substantial demands on already-busy resources, require funding and trigger change for the organizations involved.

For a true transformation program we need to plan and resource significant items such as 

• Leadership engagement, sponsorship and  decision-making
• Clear benefits, success metrics and adoption activities to support them
• Communication plans and engagement events to ensure alignment around the vision
• A new operating model
• Potential reorganization
• Culture Change including deliberate actions to transition the organization to the new way of working 
• Program Governance and ongoing monitoring of outcomes

These items imply a level of investment, effort and risk that is higher than with evolutionary or technology replacement programs. To be successful, we need to know that going in.

One test that can tell us if we have a transformation program is to look at the change necessary to deliver the intended results.

Is is going to go beyond business process and technology and start to impact organization and culture? If we are touching these elements in a Target Operating Model we are transforming to some degree and so have to manage the change appropriately.

The difference (gap) between the current state and the target operating model can also help to characterize the size of the initiative.

A radar diagram can be a good way to elicit, discuss and communicate the total scope of change for decision-making.

Putting it together

The purpose of thinking through this curve is to understand how much we are taking on and set ourselves up appropriately, rather than being surprised later on.

Early on, at the paper stage, we can flexibly decide to scale up or down our ambitions based on the business case and, critically, what else is happening in the organization. There might be a positive business case, but we don't have the resources to execute right now, or the business is busy with another transition and can't absorb another change at the moment.

Make a Benefit Map. From it, write the draft Target Operating Model and understand the gap between current and future operations. Sketch it in on the back of an envelope if you have to, but do it to test your assumptions.

Then look at how many elements of the operating model are changing between the current state and the target.

That will tell us where on the curve we are and we can set up the rest of the work structure appropriately.

I can help to facilitate that process for your organization. It can be done in outline as part of an Identify engagement, and in more depth as part of the Define stage, so please get in touch if you would like to discuss further.

Gareth.