Skip to content

March 2, 2021

Transformation Implementation: Seven Domains of Transformation

By IT Revolution

This is part of our Seven Domains of Transformation series, which has been adapted from the Project to Product Transformation white paper by Ross Clanton, Amy Walters, Jason Zubrick, Pat Birkeland, Mik Kersten, Alan Nance, and Anders Wallgren. You can download and read the white paper in its entirety here.

Why Is Transformation Implementation Important?

Large-scale transformations in enterprises often fail because it can be difficult to successfully change the structure, ways of working, and culture across thousands of people. There are so many factors that can work against your transformation agenda, ranging from poor linkage between strategy and execution to resistance to change within the leadership team or from the teams themselves.

Most importantly for success, people need to understand why the enterprise is transforming. They need to understand what problems will be solved (e.g., speed to market, customer obsession, digital disruption, IT spend, etc.).

Enterprises often take multiple years to work through a full-scale transformation from project to product. Having a clear vision as well as a sound strategy and approach for your transformation implementation is critical to increasing the likelihood of success.

What Is Transformation Implementation?

Your transformation implementation strategy helps you to establish the goals, approach, and rollout for your transformation.

The transformation can be approached in many ways: in phases, by lines of business, by certain portfolios that meet specific criteria, by experimentation followed by growth, or by a “big bang” approach.

In the next sections, we will dive in further to understand how enterprises are aligning technology and business strategy as part of their transformation implementation. There are many different pathways an organization can take to achieve a full-scale project to product transformation. We intend to provide a set of patterns that leaders driving transformation can utilize.

Our proposed strategy template suggests how to handle communication to executives, middle management, and to the broader organization, as well as how to handle sponsorship, change management, and governance for these changes. And equally as important, we define what measures should be used for success and how those measurements get established across the organization.

We will also explore the size, scope, and complexity of different enterprise transformations and how the implementation strategy may have been positioned differently based on different scenarios. While these transformation tactics can prove useful in many types of companies, this paper is primarily focused on the experiences of large enterprises that are part of the Fortune 500.

How Are Enterprises Achieving Success?

The fourteen enterprises we assessed varied in size, from a few thousand to well over twenty thousand people. The assessments include entire technology organizations as well as the people responsible for product ownership.

Typically positioned within the business side of organizations, product ownership, in rare cases, was also found in the technology organization. Product owners were primarily impacted in that their planning/prioritization approach, team structures, workflow, and sometimes even their individual roles changed. Changes to those respective areas will be discussed in more depth in subsequent posts.

To read more articles like this, sign up for the IT Revolution Newsletter here.

We found three areas where enterprises have found success in this domain:

  1. Start Small, Then Spread
  2. Communication is Key
  3. Track and Measure Success

1) Start Small, Then Spread

A general theme across enterprises is that transformations typically start small in order to demonstrate results and build momentum, often before they even formally align an executive sponsor. A common practice is to find a few teams who want to change and help them.

At this incubation stage of the transformation, a small group of progressive thought leaders will start framing a strategy and approach together. Then, by helping the small group of early-adopter teams shift to a product-based operating model, these leaders are able to leverage the small success to inform and inspire a broader transformation strategy.

Ultimately, to scale the transformation, you need to secure a strong transformative executive sponsor, or even multiple sponsors, ideally in both the business and technology organizations. You’ll need to leverage these sponsors to secure strong C-level buy-in for the transformation.

After incubating the transformation in a few, small early-adopter teams, enterprises must decide how to best roll out the change across the broader organization. In most cases, enterprises chose to implement the change by line of business (LOB) or by portfolio.

The most common path we saw was to start the transformation in more digital-focused and customer-facing areas. There is often more pressure for these areas to move to a product-centric model more quickly, as companies are increasingly competing based on the speed at which they can delight their customers with new experiences and features.

While it can be a good practice to start with the more external customer-facing products, it is not wise to stop there, as Gartner’s theory of bimodal IT—the practice of managing two separate but coherent styles of work, one focused on predictability and the other on experimentation, at once—might suggest.

As these customer-facing teams start to transform, pressure is placed on the broader organization. You now have different parts of your organization using different processes for planning, prioritization, and delivery. Team structures and roles are different. Tooling will likely even be different.

This creates many inefficiencies, especially as the old model and the transformed model mash against each other when something needs to be delivered across multiple parts of the organization. Additionally, it also starts to create a culture of the “haves” and “have-nots,” which can negatively affect overall morale of the organization.

Most of the companies we interviewed continued to expand their transformation beyond these initial portfolios and eventually transformed all their technology portfolios, including infrastructure. By expanding the transformation across more of the enterprise, and eventually across the whole enterprise, the pressure created by two different models can be alleviated.

2) Communication is Key

The different enterprises we assessed had various tactics for how they approached the overall transformation communication strategy, both in how they introduced the change as well as their ongoing communication approach.

Generally, within the incubation phase, there wasn’t a heavy focus on communication, as these organizations were more focused on experimenting, learning, and attaining initial results that they could build from. However, as they looked to make bigger changes across the organization and further grow the transformation, the communication strategy and approach became extremely important.

Some of the most effective techniques are as follows:

Frame the “Why”

Beyond communicating what the operating model changes were going to be, how they were going to be implemented, and when, the enterprises focused on framing why they were changing in the first place.

They made it clear why the changes were critical to the long-term success of their company. Typically, they tied the why back to disruptive factors in their industry, as well as to the increasing demands of speed and agility from their customers and business overall.

Initiate Internal Change Management

Internal leaders were responsible for this activity, participating in the strategy and planning for the transformation.

These leaders focused on how to pull out key messaging to help frame their transformations to different stakeholder groups within the organization. They relentlessly looked for powerful sound bites that could be captured through these discussions.

Additionally, they managed an overall communication plan and ensured that there was a constant and consistent flow of information through the organization.

Focus on Transparency

For many, transparency was achieved through continual leadership town halls to share plans and messaging as they unfolded. Business and technology executives met with teams during these town halls to have informal conversations about the transformation. Some companies even mixed executives up from different parts of the organization.

The goal of these town halls was to show that the executives were all working together toward the same outcomes. These town halls were completely open to any questions the audience was concerned about, and they were surprisingly beneficial in several ways.

First, the executives showed vulnerability by fielding questions that they couldn’t necessarily answer. Their openness and vulnerability helped build trust across the organization.

Additionally, by making the company’s transformation a conversation that everyone had an opportunity to participate in, everyone had a voice. Individuals not directly involved in guiding the transformation were able to share their ideas and concerns, which helped them feel they had input into the transformation plans.

Use Success Stories

After helping early-adopter teams, their successes were leveraged by encouraging those teams to go out and share their stories. This works best when business leaders and technology leaders are both telling the story. Use these success stories to build more excitement and energy for what is to come. These stories can help engage the rest of your management team, especially if there is any competitive aspect of your culture.

Sign up for the IT Revolution Newsletter to read more articles like this one.

3) Track and Measure Success

The measures used to track and govern the transformation across the organization typically focused on a few key areas. About half of the measures focused on the process of delivering technology whereas the other half focused on the value and outcomes that were delivered.

In measuring technology delivery, most companies were anchored in either the measures defined by Dr. Nicole Forsgren, Jez Humble, and Gene Kim through the State of DevOps Report and their book Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, or the Flow Framework measures as defined by Mik Kersten in his book Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework.

A common initial key measurement organizations used was cycle time or end-to-end lead time, which an enterprise would use to standardize each product’s timeline. Even though cycle time isn’t truly an end-to-end measure, it does typically cover a product’s life cycle from the point a story is pulled out of a backlog through the product’s implementation.

Over time, organizations have shifted their product timelines further left to when the business idea is originally conceived.

Outcome measures used for the transformation tended to focus on business outcomes, such as revenue generation, customer acquisition, conversion, cost reduction, and/or customer/employee Net Promoter Scores (NPS).

Many enterprises also shifted to an objectives and key results (OKRs) method. This allowed them to set up their governance model around tracking these OKRs, which have further connections into how leaders planned, prioritized, and funded the transformation, which will be discussed in more detail in a later post.

Finally, from a transformation implementation perspective, some enterprises leveraged outside help from management consultants. Experiences with these consultants were mixed.

Often, consultants were chosen by senior executives to work with the internal leaders of the transformation to frame the strategy and drive the change-management and governance agenda across the organization.

However, the companies that seemed most successful had very active internal leaders driving the transformation across the organization. Don’t delegate the role to drive the change to outside consultants. We believe that without passionate leaders inside the organization willing to lead and champion this charge, your likelihood of success will decrease.

Constraints That Need to Be Overcome

In our interviews, clear patterns emerged regarding constraints leaders needed to overcome during the transformation. In some cases, these constraints set back or even derailed the product transformation.

We found 3 common constraints in this domain:

  1. Technology Transformation Disconnected from Business Strategy
  2. Transformation Lacking Strong C-level Sponsorship
  3. Changing Senior Leadership

1) Technology Transformation Disconnected from Business Strategy:

Many companies started their transformation models in their technology. In doing so, they were holding off on tackling the complicated problem of aligning the business executives with the new model.

This is fine early on when you are experimenting. However, when you are looking to scale your transformation and tackle bigger foundational elements in your operating model, such as prioritization processes, funding procedures, and roles, you will not be successful if the business isn’t engaged. And, you will not be able to engage your business leaders if you can’t frame your technology transformation in the context of how it helps them achieve their business strategy.

Spend time early on to understand your business strategy, what challenges they have, and how transforming your technology capability is going to accelerate your business’ overall agility.

2) Transformation Lacking Strong C-level Sponsorship:

A product transformation is properly implemented without a high level of commitment and top-down support. If you don’t have C-level leaders modeling the way a product-centric enterprise should function and they are not personally leading the charge in the transformation, the resistors within your organization will likely undermine your change, both actively and passively.

Bottom-up momentum will only go so far. If you focus on framing the technology transformation in a way that drives your business strategy and appeals to stakeholders, it will help secure this support.

3) Changing Senior Leadership:

We learned of a few cases where a new senior leader joined the company from an organization that had differing cultures and beliefs. If these new leaders were not educated or experienced in the value of Lean, Agile, DevOps, and product-oriented practices, they tended to rely on the practices and behaviors that had helped them be successful previously.

It is startling how fast these new senior executives can unwind years of transformation progress. This constraint is somewhat linked to the previous ones. If there is strong C-level sponsorship and you’ve built more support across business and technology executives, then you are less likely to hire new executives who don’t align with this direction, and even if they are hired, you will have more support to counteract any regressions they may try to make.


In our next post, we’ll explore the second domain of transformation: business and technology synchronicity. View the full series below:

In the continuing posts in this series, we will explore each of the Seven Domains of Transformation in more detail. 


In the full white paper, The Project to Product Transformation, you will find not only the guidance indicators to create, increase, and sustain velocity, but also the negative force learnings that should help you avoid pitfalls in your transformational journey.

- About The Authors
Avatar photo

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT on Social Media

No comments found

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Map Camp: Weird Mapping – How to Create a Revolution
    By David Anderson

    A version of this post was originally published at TheServerlessEdge.com. Dave Anderson, author of…

    Serverless Myths
    By David Anderson , Michael O’Reilly , Mark McCann

    The term “serverless myths” could also be “modern cloud myths.” The myths highlighted here…

    What is the Modern Cloud/Serverless?
    By David Anderson , Michael O’Reilly , Mark McCann

    What is the Modern Cloud? What is Serverless? This post, adapted from The Value…

    Using Wardley Mapping with the Value Flywheel
    By David Anderson , Michael O’Reilly , Mark McCann

    Now that we have our flywheel turning (see our posts What is the Value…