The Trouble With Transformation

In my last blog post, I noted that many organizations are choosing to invest in their system solution portfolios. I outlined some rules to help guide you to a “modern” solution that has a very strong upside into the future. Often these projects are part of a broader program aimed to help transform the business with streamlined and efficient operations, lower costs and better customer service.

Now, you might be inclined to think of transformation as something only relevant to the large enterprise. Not so. It is relevant to any situation. Small and medium enterprises are just as likely to strive for transformation as their larger brethren though they might not realize it. Every project that involves a new toolset or a new process is potentially transformational. So, it is worth it to understand what is on the table before these things get off the ground.

When I hear the word “transformation”, I immediately conjure an image of a caterpillar turning into a butterfly. But transformation isn’t as easy as it sounds, and it’s very possible that when your chrysalis cracks open you might be surprised to find a caterpillar crawl out instead of a newly minted butterfly. So what’s the trouble with transformation?

Transformation Contexts

Before we get to the heart of this, it is important to understand the contexts for transformation. I categorize transformation efforts based on their drivers as either “Progressive Transformation” or “Restorative Transformation.” In the case of Progressive Transformation, organizations are looking to bolster key fundaments that allow for increased maturity and create new headroom for growth. This adjustment may include such things as moving from highly manual environments to those based on automation. Here the business actively values adopting efficient ways of working. It may also include moving from environments where control and insight are lacking. Here the organization will bring in new solutions to increase control, and financial and operational insight. With that, the business adopts toolset, workflows, audit approaches and robust internal and external reporting. In the Progressive scenario, the idea of explicit process engineering and enabling toolset are fairly new.

Restorative Transformation occurs when an organization already values the key fundaments of maturity and growth, have taken care to define their processes and are utilizing some types of tools to support them. In the Restorative case, however, the process and toolset are no longer suitable, and a degree of process re-engineering and new toolset selection is required. Here the organization must restore order and recapture their values and outcomes that have been compromised over time. It is often easy to identify these situations as the term “legacy” is often tossed around – legacy organization, legacy process, and legacy system. Sometimes this situation arises out of acquisitions, spin-offs or consolidations. Usually, however, it arises out of – well, let’s not mince words – neglect. Now, that does sound unflattering. I am hopeful that any neglect is not willful but rather is the result of drift with no inbuilt means to correct. A successful Restorative Transformation will both restore order and provide an inbuilt means to correct and adapt.

Certainly, elements of both Progressive and Restorative transformation can be involved in a given environment. Usually, it’s one or the other scenario that dominates though. In both cases, transformation is born of a practical need to address challenges for growth in the business. Irrespective of the context, they both require special support in order to be truly successful.

Transformation Success Factors

Right, so let’s get on with the main topic at hand. What factors are critical to having a successful transformation initiative? How can I make sure my transformation program yields a beautiful butterfly? Done properly, transformation should be the gift that keeps on giving.

The heart of a successful transformation initiative involves three component areas – three “A’s”: Analysis, Adoption, and Active engagement. These areas also track lifecycle stages of the initiative as it progresses sequentially. They are also akin to the delivery model of Plan, Build, Run – only with a twist. Let’s look at the special aspects of each.

Transformation Analysis

In order to define the target state for your transformation, you will need proper resources to analyze the current state, extract/identify requirements and define the future state. While you can attempt to do this solely with “outside” business analysts from a corporate pool or provided by vendors, you should be prepared to develop a composite team. The composite team will include “inside” resources as close to the current process as possible in addition to the “outside” resource. Using a mix of inside/outside resources will ensure that nothing falls through the cracks and will position you to take both top-down and bottom-up approaches to understanding the “real” requirements.

The “inside” resources must directly sit in with the transformation team and must not involve themselves in a drive-by or arms-length manner. This is where ownership and effective delivery of transformation starts. Leveraging inside resources will ensure you have a strong team ready to carry forward your project lifecycle and will avoid problems that occur when the current operations team is viewed simply as stakeholders. They must be involved as architects (loosely defined) of their future and accept that responsibility wholly from vision through to the day-to-day.

Utilize common techniques such as the “repetitive Whys” to help you uncover requirements. The “outside” resources can be valuable in this regard and provide an element of objective detachment that inside resources may lack. Together, the composite team will create the plan for the transformed operation both in terms of the toolsets and the human and system workflows.

Ideally the “inside” resources helping with analysis will also be the change agents required for effective Adoption.

Transformation Adoption

First, let’s clear something up. Adopting a technical solution alone is not going to deliver transformation. There was a time when such a notion would seem obvious. We lost that appreciation though; probably around the time the keyboard replaced the pen. The rise of technical solutions has seen an atrophy of understanding for business solutions and their processes and has resulted in a lack of ownership for the true underlying process. Often the “system” was viewed as the process. There was no differentiation. But…those same environments are the ones labeled “legacy.” Both the systems and the people were rigid. In today’s world, this rigidity causes the need for transformation. So this needs to be understood in order to avoid a major pitfall when moving forward.

Adoption by people is key. Your people need to understand. Your people need to command their tools and the work environment. Transformation is primarily about people. Systems are secondary and support the people. People are the source of value identification, the ones that can chase it and ultimately the ones that deliver value. They are also the ones that must answer to the results.

So, your people need permission to chase opportunities and values. Then they need venues and means to effect beneficial change either at a macro or micro level. The procedure of “betterment” needs to be baked into your process. This aspect is the difference between the rigid environment and one that achieves the promise of transformation. Your transformation needs to perpetuate adaptations and transformations.

The toolset can be that means and selecting the right toolset is extremely important. A transformative toolset must be something that can be fully administered by the business team – in terms of administering roles and access, configuring and organizing the tool as well as defining business logic and flow. The tool must be something that the business team commands and not something that drops in their laps.

I’m not going to get into technical adoption and will simply say that any transformation project that requires extensive effort to come into the technical environment should be a major red flag. That type of inertia foreshadows difficulties when things need to change both in the technical environment and the business environment. Those changes are inevitable, so keep an eye on that.

When you combine the proper installment of responsibility and ownership by the business team coupled with the utilization of an empowering tool, you have yourself a significant change management project. Education in the tool and in the broader responsibility to operate today and tomorrow – in the face of change – is fully demanded. Of course, that education starts in the earlier phase of Analysis and will carry through to Active engagement.

Transformation Active Engagement

The crux of this has already mentioned. When you carry your transformation project into the day-to-day, your team must be empowered for continual improvement. The interesting thing about this is that whether you are ready for this will likely be telegraphed early on in your project. You can expect things to go wrong. How does the team respond to the changing demands in the course of the project? How does the tool respond? If you see your team take the inevitable bumps in stride, you can take some comfort that you are on the right track. If you see them struggle, what does that tell you about how they will deal with the inevitable change the future is sure to hold. Have you really enabled your team? Or have you simply changed the box in which they have to live?

Make sure your day-to-day process draws toward continual improvement, agility, and exception management via active engagement driven your business team and their toolset.

Transformation Secret Sauce

Note that the phases above value business ownership as a key success factor. It is extremely important to the transformation effort. Consider the typical Plan, Build, Run model. Each phase is often delivered by completely separate teams (architecture, development, operations respectively and is IT focused). Between each phase, an explicit transition is needed to engage the next team. What I am suggesting is that any project that hopes to transform the operation must involve business operations and strengthen their ownership in all phases. It must include the right people with the right involvement – meaning those charged with critical analysis and continual process improvement for the operation. Yes, there must be THOSE people. If you don’t have those roles, either implicit or explicit, they must be present and cannot be represented by proxy.

Remember above when I mentioned “neglect” and “drift” concerning Restorative Transformation? If you have truly transformed the operation, challenging your team to undertake constant improvement and empowering them with the right toolset should nullify those concerns. It is business ownership that will make the difference. It should be reinforced at every phase and be the predominant feature of both the project and the future state.

In the end your team must be fully engaged, fully empowered and fully enabled to operate the business – and not just at a single point in time. When the project or program concludes, all that remains is your people and their toolset. Your transformation project should deliver capable people enabled by capable toolset that strives to future-proof your operation.

Summary

So, transformation is not a singular activity carried forward by a project or a program and delivered by major tectonic shifts. True transformation is about enabling your people and process to be adaptive. It is something that constantly happens at a micro-level and is maintained by your empowered teams long after your program has concluded. Fully realized transformation involves team enablement and constant adaptation going forward. Both your people and toolset must be adaptive. Having fallen short of this dream, your transformation project will yield someone else’s Restorative Transformation project down the road. Your caterpillar will yield another caterpillar never to take flight.

All of this brings to mind the saying by Mahatma Gandhi, “Be the change that you wish to see in the world.” I hope I am not fouling his words completely if I append to that and imagine it in a business context (Apologies, MG. Probably crossed a line). “Be the changeling that you wish to see in a changing world.” Enabling continual change and micro-transformations is what grand transformation should be – delivering a constant stream of butterflies day after day.

Jeremy Shanahan is ReconArt’s Vice President of Business Solutions and is overly prone to the use of metaphors (wielded like a knife – OK, maybe one of those little knives for spreading soft cheese). He is responsible for product strategy and coordinating product delivery for the global ReconArt organization. Jeremy has over 25 years of experience in enterprise architecture, software design and implementation of global, financial-focused software technology solutions.